Integrating version control and issue tracking
I was going to write a post describing various dodgy methods for tying together version control and issue tracking systems, but I’ve found a better way! Read on for the thrilling details.
In his post on bug tracking techniques, James mentions one reason to refer to issue-tracker Issues in version control commit messages:
The solution I came up with was to ask everyone to put a specially formatted string in the commit log that noted the bug number that was resolved in that commit. The version control system will keep track of the code that gets integrated between branches, and carries the commit messages with it. That means getting a reliable list of bugs fixed in any given version is as simple as enumerating the changesets integrated into that branch.
As described, this is a method for generating a list of changes in a given software release. Being able to look at a source code change and know what Issue the change was made for is another benefit. This helps with those “Why the hell did he do that?” questions that come up when looking at Other People’s Code.
After adding these strings to commit messages for a while, I realized that it’s just as useful to have a mapping the other way - from the issue tracker to the version control system. This allows viewing the changes committed to fix a given bug or implement a feature. I did this by adding a comment to an Issue, e.g.
This is really easy with Perforce since the changelist number uniquely identifies a set of changes to multiple files that were atomically committed to the repository. Doing it with CVS is trickier.
This manual method was useful but very primitive. A better method is to use the post-commit hook provided by the version control system to append a message to an Issue. In the example above, the changelist number (and perhaps the commit message) would be appended to the Issue page by a script when a commit is done. This is possible because the Issue number is (manually) included in the commit message.
The best method is to use one of the pre-existing solutions to tie the issue tracker and version control system together. Until recently, I wasn’t aware that there are a bunch of these for Perforce, as listed here. There are plugins for Jira, FogBugz and Bugzilla among others.
For the JIRA/Perforce combination I’ve used previously, a Jira plugin is available from Atlassian and it looks really cool. For each Jira Issue you can see a list of Perforce changes, including the commit message and a list of changed files. Each Perforce change entry can be hyperlinked to the change itself as displayed by p4web.
I think this would also help with James’ original problem of compiling a change list for a particular release. Jira and Perforce are integrated using the Perforce jobs feature, and as described here, jobs are preserved across integrations. So it’s possible to ask Perforce which Issues (jobs) have been fixed on any branch without having to add a specially formatted string to commit messages.
