JIRA & Bamboo: A Winning Combination

It seems like the problem of managing software defects and tasks should be easy, especially in comparison to the software it's meant to track.  Easier said than done.  Each job I've worked has approached task and defect tracking differently:

• SRA (Government contractor) used Microsoft Project in the early 2000's.  This worked ok, but only the project manager had access to the project file, which made it tedious to create/accept/resolve issues.
• The 3D Marketing startup in 2003 used XPlanner for agile project planning.  XPlanner had a lot of the same features present in JIRA today, but it was a little rough around the edges and was not easily extensible.
• EMC Documentum used an in-house defect tracking tool built upon the Documentum platform.  This was pretty awful.  I think the tool was built just to prove that it could be done.
• MobiTV used the Mozilla Bugzilla bug tracking system when I joined in 2007.  It looked dated at the time, but it worked fairly well and was well supported Open Source software.  Around 2008 we switched to the Atlassian JIRA platform.  We've used that platform ever since, and I still think it's the best product available at any price.

I am definitely a fan of JIRA.  I've even gone so far as to install on a server at home for the purpose of tracking tasks for some of my personal projects.  JIRA is a Java web application that runs in a Java Servlet container (i.e. Tomcat) on multiple platforms (I'm using Linux).  The licensing and hosting options are very flexible, too.  JIRA is available as a managed service from Atlassian for a modest monthly fee.  It's also available as a download for self-hosted installations for as little as a $10 one-time fee.

JIRA embraces the idea of user stories and sizing from the Extreme Programming (XP) design methodology. It's easy to create stories that capture small amounts of work, and group those stories into development sprints that map to the release schedule.  User stories give the customer & developer a way to break the project down into manageable pieces, making it easier to schedule and prioritize features prior to construction.

Software invisibility prevents most customers from realistically conceptualizing the system in their minds.  Even if they could, communication errors would probably keep us from being able to build it from their instructions. ... A user story is the smallest amount of information (a step) necessary to allow the customer to define a path through the system.  -- "A Practical Guide to Extreme Programming" (Astels, Miller, Novak) 

Another pervasive problem is the compilation and packaging of software.  I've worked with several complex products, and it's best to automate as much of this process as possible.  Here are the approaches taken at each of my past jobs:

• SRA used Ant to build and package Java web applications in a WAR.  The deployment platform was SunOS server, so RPMs and Debian packages were not an option.  This worked well, but the build process was triggered manually on an individual's development machine.  This was subject to the integration hell that occurs when you're not running performing continuous integration.
• The 3D Marketing startup used Cruise Control for continuous integration (CI).  This was my first exposure to an automated build system, and it made me a true believer in the CI process.  Work out of a single codebase.  Build the final product upon every check-in.  Run unit-tests that ensure there are no regressions.  Cruise Control would package the Java Enterprise Archive (EAR) and deploy it automatically our JBoss application server, then run a suite of integration tests.
• At EMC Documentum I created a Cruise Control build machine, but there was not any serious adoption of CI.  This was a dysfunctional organization, and code integration was the least of its worries.
• At MobiTV we use Bamboo, also from Atlassian.  It's got a lot of polish and is tightly integrated with JIRA.  It's a great improvement over Cruise Control, and is available for a modest cost for self-hosted installations.

The integration between JIRA and Bamboo is hard to beat.  It only makes sense to tie the issue tracking system with the build system.  For instance, in a JIRA defect I can see links to all of the source control check-ins and builds associated with the issue.  Similarly, I can see the JIRA issues associated with each build in Bamboo.

Bamboo, and Continuous Integration in general, are critical to reducing the risk associated with a project.  I've got work to do, and building software is the least significant part of it.  An automated build system ensures that the build is always clean, else it alerts me to a problem so that it can be fixed when the cost is least (fix the bug as close to the time of introduction as possible).

Another important reason to accept the costs of continuous integration is that it dramatically reduces the risk of the project.  ... You never spend days chasing a bug that was created some time in the last few weeks.  And all that practice at integration comes in very handy when it comes to creating the final project.  The "production build" is no big deal.  Everyone on the team could do it in their sleep by the time it comes around, because they have been doing it every day for months. -- "Extreme Programming Explained" (Kent Beck)

In conclusion, JIRA and Bamboo are excellent tools that I hope to use on all of my future projects.  They've had a very positive influence on my development patterns and productivity, and are representative of the widespread industry acceptance of XP development methodologies over the last 10+ years.