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?

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.

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.