What are the benefits of Source Code Integration for a Bug Tracking system?

Question

I'm choosing a Bug/Issue Tracking system for use on our project. This question and this question are helpful in giving systems to evaluate. However, I have a question raised by looking in to the various products on offer.

Some systems promote Source Code Control System integration as a feature. This is not something I've used before and looking at the various tools' websites I can't find any detail on precisely what this integration provides. Is it any more than browsing my repository through the same web interface I use for raising bugs?

So what benefits does such integration offer? How will it save me time or make our product better?

Answer 1

The major advantage is that you can raise bugs against specific revisions of source code. This just helps identify the state of the code-base when the bug was noticed. I think a popular product in this space is Trac, which integrates with SVN.

Answer 2

I've done this with Visual Studio Team Foundation Server, which not only integrates with the source control, it also integrates with a data warehouse. This allows it to keep track, for instance, of which bugs were caused by which pieces of code, showing which pieces of code need more QA. The forthcoming features in the 2010 version are even more compelling.

Answer 3

Jira together with FishEye (a SCM browser) can, when if you commit a changeset with a log messages containing a Jira issue key, such as "PROJ-123", insert a link into the corresponding Jira issue, and Jira will display a link in PROJ-123 to the changeset mentioning that issue.

Jira can also integrate with Hudson, so that when a build incorporating a fix (i.e. changeset) is performed, the Jira issue mentioned in the log message of that commit will get a comment about the status of the build.

Since an issue tracker is used to keep track of issues with the source code, there are a boatload of features one might imagine in an integrate issue/source-control management system.

Answer 4

Well, I'd say there's one big reason here, and it's that you can work on a task/issue oriented way.

I mean:

• every code change you do (everything, from a small quick fix to a big new feature) will be an issue in Jira or Rally or Bugzilla, Trac, Mantis, the one you like.

• It means the issue/task tracking system must be easy to use, fast, simple and so on, otherwise developers will hate it

• Then associate every change to the issue, and you're done. You get full traceability (great for diff debugging, you'll miss it if you don't have it), better project tracking, better release management and so on.

You can link each changeset/commit (depending on your scm jargon) to a task, or, if your scm can do it, create a branch for each bugfix, which is even better.

Basically what you get is simple: every change will be documented, or at least linked to the right issue/task.

If you use branches, you can promote things like: always working on stable baselines, reducing mainline corruption (or making it pristine, if you prefer), deciding which tasks integrate and which ones hold until the next release, individually run tests on changes before merging, and so on.

Answer 5

I think integrating your bug tracker with your source control system is a great features. We use TeamSupport.com and have just integrated into BeanStalk (hosted SVN).

Every time we do a commit TeamSupport looks at the description to get the ticket numbers, then adds a note to the ticket with a link to the code in BeanStalk. Very cool stuff.