continuous-integrationtasktraceability

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


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?


Solution

  • 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.