Continuous Integration: how do you tie back your builds to requirements/tasks/bugs?

Question

How do you answer the following questions from managers, testers and other people in your team:

In what build is bug #829 fixed? What tasks have been completed in our current test build?

So simply put, how do you achieve traceability of your requirements, tasks and bugs right from them being reported reporting through to deployment? What processes, tools and techniques are you using to achieve this?

Knickerbocker

Answer 1

We use TRAC with SVN in our Company and perform daily rolling builds to DEV / STAGING & STABLE environments with regular scheduled deployments (once a month... ish) to a PRODUCTION Environment.

When a bug is reported, it's entered into TRAC and given a Tickets number (e.g. #1001)

When the bug is fixed, the code is checked back into SVN with the ticket number(#1001) in the SVN Checkin notes.

The developer takes a note of the SVN Changeset number (e.g. [5000]) and opens the TRAC web ui. When closing the ticket, they put the changeset number in the notes of the ticket.

This way, the SVN checkin reference the ticket... and the ticket references the SVN Checkin.

Our daily builds are then performed against an SVN Changeset (e.g. todays build is everything up to changeset [5050]) and a note is made of this in our deployment notice.

Deployed On   |  Environment            | Changeset
--------------+-------------------------+--------------------------
10-01-2008    |  DEV                    | 5100
10-01-2008    |  STAGING                | 5080
10-01-2008    |  STABLE                 | 5050
01-01-2008    |  PRODUCTION             | 5000

That way the testers when reviewing fixes for testing know by the changeset in the ticket comments if the build they're looking at includes the fix.

Lambard

Answer 2

We use TFS in conjunction with JetBrains' TeamCity for CI.

When associating check-ins with tasks, our custom check-in policy prepends the associated tasks and bugs with their ID's and titles to the check-in comments.

These comments are then used to generate the release notes, which are automatically generated for each build.

Knickerbocker

Answer 3

We are tagging the source control check-in with the defect number that has been fixed or the enhancement number that has been implemented.

By retrieving the check-in log between two builds, you can determine what has been implemented or fixed.

Ard

Answer 4

We use a managed SVN service called Beanstalk (http://www.beanstalkapp.com/) that allows you to easily tie in with a number of Bug/Feature management systems. In our case, we use Fog Creek's FogBugz for that end of things. SVN/Beanstalk permits you to make notes when you check in a build that will, in turn, affect the status of one or more FogBugz cases.

On the client end, we use Tortoise SVN and Visual SVN to manage the interaction of the local client and the Beanstalk SVN server (Tortoise provides the actual service, Visual SVN provides the integration between Tortoise SVN and MS Visual Studio).

I highly recommend both services and the Tortoise/Visual SVN client.

Tillie

Answer 5

We are using Fogbugz which has build-in subversion integration. Basically there is a plugin for Fogbugz which checks for SVN check-ins in the background. So if you supply a Fogbugz-case id at your check-in, it gets automatically linked with this check-in.

As far as I know you don't need any special application (like Beanstalk for example).

The other way round is little tricky. In our company there is a convention that for every (future or past) build there is a "release" in Fogbugz. If you fix a bug or implement a feature you assign the case to the right release.

Then it's quite easy to get a list of all implemented features of build X.

Skolnik