This case study is the sixth of an 8-part blog series about why so many developers adopt continuous integration, and originally published on the Atlassian blogs. It naturally has a bit of a Bamboo slant to it (if you look close enough, you can even see the odd panda), but the issues discussed apply to any team trying to adopt modern development practices, no matter what CI tool is used.

Automating the staging and production deployments

Testing intermediate builds is one thing, moving to General Availability and production deployments are a whole other subject. Steve and Simon, the developers in story 5, also had this issue to grapple with as prior to using Bamboo this was an entirely manual process. When they moved to using Bamboo for Continuous Integration they also upgraded their issue tracker to JIRA which made for a very pleasant surprise.

The pain of manual builds

Originally, this was a manual process, requiring a developer to run the mvn release:prepare and mvn release:perform commands from the command line. Maven would prompt for the next version number, which had to be entered by hand. If an error or mistake occured, or the process was interrupted half-way through, things had to be tidied up by hand. Many times, an incorrect version number was deployed, and the Subversion tags had to be removed by hand afterwards. In addition, an obscure Subversion bug meant that occasionally the release:prepare phase would fail for no reason. Although the work-around was relatively simple (just run an svn update and re-run the release:prepare command), this increased the complexity of the process and added one more thing that could go wrong. It also duplicated maintenance work between the version numbers in JIRA (where issues were managed) and in the Maven project itself.

Preparing Maven, JIRA and Bamboo

In Steve and Simon's project, Steve now uses JIRA and Bamboo to help automate the build promotion process. The version numbers of each release are maintained in JIRA. There is generally a maintenance release once a week, on Friday night, and a major new release every two months or so. Version numbers use the default three-digit Maven convention (e.g. 2.0.44). Each version released to staging is given a unique version number. Automated deployments to the integration server use snapshot versions (e.g. 2.0.45-SNAPSHOT).
Since their project uses Maven, he uses the Maven Release Plugin to help manage the build promotions. This powerful plugin checks that all the latest changes had been committed to Subversion, creates a new tag in the Subversion repository with a label matching the next release number, and updates the Maven project version number. In a second phase, the tagged code is checked out, built, tested and deployed to the Nexus repository, ready to be used during the staging deployment.

Using Bamboo and the JiraVersion plugin, Steve was able to entirely automate this phase. The Maven Release plugin can be run in batch mode, without any human interaction. By default, it will simply increment the current version number. However, you can also provide the next build number as a parameter. This makes it easy to integrate the JiraVersion plugin, which will pass the selected version number as a parameter to your build script. In Bamboo, Steve set up a build plan configured with the JiraVersions plugin. This plan proposes a list of available JIRA versions for deployment. Steve simply chooses the version that he wants to deploy to kick off the build promotion.

Practice makes perfect

With a little work, Steve was able to automate the process and create a series of Bamboo build plans that authorized users can now use to deploy to the right environment with the click of a button. In Bamboo, there are now two special "release" build plans, one for staging and one for production. The staging and production build plans are run on remote agents, directly on the staging and production servers. Each build plan can only be executed by people authorized to deploy to staging and production respectively. These build plans propose a list of available JIRA versions for deployment, and the user simply needs to choose the right version number to kick off a full-blown deployment.

To get around the Subversion bug mentioned above, Steve wrote a Groovy script that automates the whole process, including the work-around if the Subversion issue occurs.

Now, whenever a release is ready to go onto staging or production, the build promotion process is as simple as clicking on the corresponding link in the list of available version numbers.

"Probably the best training course I've been on."..."Not just how to write Java code but the 'business end' - how to build, test, deploy, manage and monitor"..."One of the best and most useful courses I have attended. And they didn't even try to sell me anything!" - Coming soon to London! Get up to scratch with the latest in Java tools and best practices! Sign up on the 2009 season of the Java Power Tools Bootcamps.