One of the challenges that organisations transitioning from their existing bug tracking tools will face is how to temporarily integrate their current bug tracking software with Team Foundation Server while they bleed data across (bulk imports aren’t always appropriate).
For example – lets for the sake of argument say that Mozilla decided to move from their legacy (sorry, couldn’t resist) bug tracking package Bugzilla, they would need some way to associate check-ins that occured with the bugs that they were addressing.
The above screenshot is taken from the Bugzilla database for the Mozilla project and as you can see there is a pretty obvious key on the screen there – that is the bug ID “300561”. One simple technique that organisations could employ is adding a required check-in note to the source control settings.
Check-in notes are simple strings of information that you can force developers to enter when they go to perform a check-in. By default no check-in notes are required which is why a lot of people miss out on this neat little feature on the check-in dialog.
This list of fields is completely configurable and you can even make them required (they can’t be overridden like check-in policies).
Once you have defined the required check-in note, the next time you attempt to check-in some code you will be prompted to put in the details – in this case the external bug ID.
The details that you enter on this form becomes part of the permanent changeset record for the code and can be accessed by looking at items in the source file history. Since changeset information also gets recorded in build reports you can also back track from a build to work this out, and while it isn’t as direct as working with the TFS work items it does do the job.
Another option is to modify the work item definition for bugs in the process template you are using which has the added benefit of showing up in the data warehouse so you can tie it into your reports – however thats a little bit more involved and beyond the scope of this post!