Proposal

Introduction

As the heading above states this is a proposal. This proposal will cover how a developer should submit to the build. I have not worked on an open source project before, nor do I understand how other open source project's process work. The process described here is an adaptation of the process I created for the project I work on in my day job.

Overview

It is always nice to start on the same page, so here are my assumptions about the starting point.

We would like to work in an Agile manner.

Well that's a very general statement you say?

We value decentralized management.

Does that help?

Decentralized management is a must for an open source project to be successful. The trick is in knowing what to spend time managing. To know what to manage you need to have information. Luckily Continuous Integration can easily produce voluminous amounts of information. Having loads of information is not always helpful, having the right information is. This begs the question: What information do we need to successfully manage?

1. What tasks/issues/features are to be done?
   • Jira can track all the work that is being performed if we start using it.
2. Who is doing the work?
   • Again this tracked by Jira.
3. When was the work done?
   • If the developer keeps their Jira tickets in sync with their work this can be tracked in Jira.
4. What work was done to complete the task/issue/feature?
   • This can be tracked in Jira as well. The changes to source need to be documented in the ticket.
5. What quality was the work?
   • Testing of the product in the build server can generate metrics to evaluate the quality of the work performed.

The Process

I always like to view things with a little context, so we will start before the build submission. A Developer is assigned a ticket in Jira. When they begin work on this ticket they change the status to In Progress. When they have completed the work they should update the ticket with a comment explaining the work they performed. Before they check in their source they need to update the status of the ticket from In Progress to Pending Build. Any tickets that are in a status of Pending Build when the build is run will be manipulated by the build script. The scripts can do several things to the ticket(s).

• It can add a comment to ticket listing the source modifications.
• It can add a comment that the ticket was successfully built.
• It can change the assignee and the status of the ticket as well.

Now I have omitted some of the steps in the above description of the process. The following steps will detail the process in full. I will start from the point of the developer has completed the work tasked in a ticket.

1. Add a comment to the ticket detailing the work performed.
2. Check the custom filter All Pending Build.
   1. If there are tickets in the filter someone else has claimed the build. The developer must wait until that build is available.
   2. If there are no tickets in the filter then the developer may proceed.
3. Flip the status of the ticket to Pending Build, now the build has been claimed.
4. Check in source.
5. Wait for the build result.
   1. If the build result is successful then the developer is done.
   2. If the build result is failing then developer must fix the build.

There was one new item introduced in the steps above: the custom filter All Pending Build. This filter serves two purposes; allow developers to claim the build, and allow the build script to easily grab all the tickets submitted with the build.

Conclusion

There are three benefits to integrating the build process and the ticket tracking system. The least important benefit is the ability to claim a build, granted overlapping submissions rarely occur and this will only prevent an overlap if the process is followed. The main benefit is the ability to correlate the build page with a ticket and vise versa. The last benefit is being able to manipulate a ticket from the build script.

Here is a partial screenshot of a build report from a project that correlates tickets (SCRs) with builds.

Notice that the check in comments link to the ticket numbers (1596 and 1629). This means that source control, the build page, and the ticket tracking system are all correlated. From any one of them you can track to the others.

This correlation is useful to enabling managers to quickly see what is going on in the project. It is easy to see on the build page what work was done, for what ticket, who did the work, and the quality metrics are there as well. When looking at a ticket the build script will have added a comment detailing any information from the build that we deem necessary.

The build scripts can assume responsibility of moving the ticket to a new status, say Pending Release. Now the developer does not have to be responsible for flipping the status of the ticket. A custom filter showing all the tickets Pending Release eases a manager search for the condition of a release.

To adopt this process we would need to:

1. Add the statuses Pending Build and Pending Release as well as their related custom filters.
2. Create a nAnt task needs to be written to control a ticket in Jira through SOAP.
3. Add to the current build script the necessary section to interact with Jira.
4. Update the CCNET config to merge an Xml file reporting the tickets from a build.
5. Create an Xsl for the build report page.
6. Configure the Dashboard to use the Xsl.
7. Last follow the process when submitting to the build.

Correlation.jpg (image/pjpeg)