Switching to PivotalTracker

For our SCRUM development we have used a variety of tools to plan and track our work.

Mingle
We used Mingle for a long time but found that because it is so customizable it makes it very easy to overcomplicate your project and process.  We also spent a large amount of time configuring, setting up and tweaking mingle to create the ideal project template.  Mingle is also very slow and seems to require a server with a huge amount of resources to run smoothly.

Scrum Ninja
Scrum Ninja has a lot of nice features and seems to be going in the right direction but it was very glitchy and we even lost some data at one point.  We were able to get most of it back through their support but it was definitely a hassle.  Searching didn't work very well and although the card wall view is a nice idea it can be hard to read.  The export format is relatively useless leaving out important data like dates.  It wasn't even worth trying to parse the exported text with a script to extract what we wanted.

Pivotal Tracker
Pivotal has done a very nice job with their Tracker product.  We first tried at the same time as ScrumNinja and first impressions left us feeling it was more restricted or had fewer features in some areas.  We gave it another go and now realize it has a much simpler interface that we've found frees us up to just work on the project rather than spending time setting it up in the tool.  It has several integrations with other projects and an open API for custom integrations.  We've also made suggestions and bug reports and had very quick responses and fixes.  It also uses csv as an export format.  All in all we're very happy with Tracker so far.  Plus, it's free.

Setting up TortoiseGit to work with SSH on a different port (not port 22)

So recently we've had some headaches giving users on Windows machines access to our git repository (me being one of them but not the first). In searching for a solution to this problem I found several people with the same issue but having to use various workarounds or actually change their ssh port back to 22. All of the workarounds were out of the question for me but I knew there had to be a way to do it. Basically I just followed some of the better posts about using Git on Windows out there with a couple minor changes.

Here are links to a few of the posts I looked at while trying to figure this out:

http://www.lostechies.com/blogs/jason_meridth/archive/2009/06/01/git-for-windows-developers-git-series-part-1.aspx

http://nathanj.github.com/gitguide/tour.html

http://kylecordes.com/2008/04/30/git-windows-go/

The important pieces to make sure you get it working are these:

1. Be sure you choose the OpenSSH option when installing msysgit
2. Be sure you choose the OpenSSH option when installing TortoiseGit
3. create a .ssh/config file and enter something like the following

Host name_of_host_where_your_git_repo_is

User git

Hostname name_of_host_where_your_git_repo_is

Port port_number

PreferredAuthentications publickey

IdentityFile "/path/to/your/openssh/private/key"

And you should be good to go. I actually set up msysgit and my ssh config file first, then I made sure that I could connect and then I installed TortoiseGit.

Tips:

1. If you created your private key using puttygen then you'll need to export it (using puttygen) as an OpenSSH key.
2. While testing your connection you can use ssh -v git@github.com (or @ your own host even) to see what ssh is doing and to make sure it is finding your key correctly.
3. If your openssh key is located at C:\users\myuser\keys\key.ssh then the path to your IdentityFile should be like this: /c/users/myuser/keys/key.ssh

Team City's FxCop Runner

Team City has a number of built in runners to use on your project that provide some pretty nice reports right within Team City. Some of those we're using are the Duplicates Finder (.Net) and the FxCop runner. The Duplicates was pretty easy to set up but I had a little more difficulty with FxCop. Nothing serious but I thought I'd reproduce what we did here.

First, of course, we had to make sure that FxCop was installed on our Build Agents. Then I added the following to the buildAgent.properties file

system.FxCopRoot=c\:\\Program Files (x86)\\Microsoft FxCop 1.36

Make sure to escape the colon and backslashes.

Then I had to create an artifact from my compile build configuration that was the bin folder containing the assemblies I wanted FxCop to look at.

Then I had to create an artifact dependency on that artifact in the FxCop build configuration; otherwise there were not any assemblies available for FxCop to operate on.

That did the trick for me.

The next step is to create a Dashboard type page that will have a script that will grab all the different metrics created from FxCop, Duplicate Detection, NCover, our burndown chart, etc. and display them in easy to view way (graphs and what not). We'd have all developers set this to be their home page (or ideally have it displayed on a wall somewhere) so all this can be viewed at a glance and you can get a quick overview of the project. I think this will be really valuable as a tool while trying to take TDD to the next step.