If you’ve been around agile development long enough, you’ve heard time and again that doing agile ‘right’ means making releases a non-event. Sounds great, but how does one get to this magical place? Ever a fan of lists, I put together the top six ways to avoid an ulcer at release time using the combined powers of JIRA and Bamboo.
If you’re on a team that already maintains steady blood pressure and a resting heart rate of less than 60 bpm in the days leading up to a release, congratulations! Enjoy this blog as a validation of what you’re probably already doing.
Step 0: Set up a rockin’ dashboard
Regular readers and subscribers to the JIRA Insiders newsletter have already seen our guide to creating a killer dashboard. So I’ll keep this part brief. Make sure you’ve got the JIRA-Bamboo plugin installed, then add the Bamboo Plans gadget to your dashboard. This pipes real-time build results into JIRA, letting you know when it’s time to push a release candidate out to your internal environments (and when not to bother).
Step 1: Automate the pain away
Make your releases repeatable, traceable, and reliable by automating them. We humans are prone to error, especially when working at 2am, so making a computer do the dirty work is just plain safer.
If the thought of automating deploys daunts you to the point of near paralysis, you’re not alone. Fortunately, Bamboo makes it easy to take the first step. You can start by converting your deployment run book into a script that can be executed from the command line, and use a script task in Bamboo to execute it. There are also tasks available for deploying to Tomcat, JBoss, Websphere, Heroku, CloudFoundry, VMWare and more, as well as integrations that pull in your existing deploy automation from DeployIt and LiveRebel. (Check ’em out in the Atlassian Marketplace or through the add-on manager in Bamboo’s administration console.)
Regardless of what your deploy automation looks like under the hood, using Bamboo to orchestrate it brings a host of other pain-reducing advantages – especially for JIRA teams. Intrigued? Keep reading.
Step 2: Know your environments
Being able to see which release or version is running in each environment is something every team needs, and most struggle with. I’ve seen days or weeks spent writing custom hacks that expose this info on some secret page. Unfortunately, this is non-functional code that still has to be maintained and tends to break when environment configs or infrastructure change.
The good news, however, is that once you set up deployments in Bamboo, you get this for free. On the dashboard view of each deployment project you’ll see a list of all the environments you’re deploying to, and summary info for each one: what release version is running there, when it was deployed and by whom, whether the deploy was successful, and whether it has been approved for promotion to the next environment. No need to spam the Ops team asking which release candidate is running on Staging, or wait on a reply. Just get in, get the info, and get on with your day.
Step 3: Track issue & commit diffs between release candidates
Let’s see… spreadsheets, email threads, post-its, the back of your hand… If these are the tools you’re using to record the changes from RC to RC, then you’re making it too hard on yourself. It’s too easy for information to get lost or missed, and too hard to ensure all the right people have access to it. Even if you use a shared wiki page, entering the data is still a manual process (begging pardon from our pals on the Confluence team).
Teams using JIRA + Bamboo can breathe a big ol’ sigh of relief. Your developers are probably already in the habit of mentioning JIRA issue keys in their commit messages. “Checking in a fix for DEV-123. I am the greatest developer ever!” …or something like that. Bamboo picks up that up and links the issue to all builds resulting from that commit. Then the next time you create a release candidate, Bamboo looks back to find all the commits and associated issues since the last RC, and provides you a handy, easy-to-read list. You can diff the commits and issues between any two RCs, making release notes a snap and day-to-day changes easy to grok.
Step 4: Track the quality of each release candidate
Test automation means automated test reporting, which is a HUGE win for wrangling releases. With Bamboo, you win even bigger because you see the results summary for all automated tests against run against the artifacts you’re releasing. We know lots of teams, including our own, run multiple CI builds against each set of artifacts. So we pull the results together in one place when it comes time to deploy. If there are failing tests for a release build, you can raise a JIRA issue for them from inside Bamboo, and the issue and build will be linked automatically.
There’s also a handy Approved/Broken flag you can use to quickly communicate the results of manual exploratory testing, and a place to enter comments (more on that in Step 6).
Step 5: Follow each issue’s path through the pipeline
We’ve already talked about how easy it is to see which environment each release candidate is running in. But how about a user story? Or that critical bug fix? Fear not. Because release candidates in Bamboo track all the associated JIRA issues, you can see both the RC name and the deployment status right inside each issue. No need to manually cross-reference data across multiple tools! We unleashed this killer capability (and lots of other stuff) in Bamboo 5.1 and version 7.1 of the JIRA-Bamboo plugin just this week, and we’re keen to get your feedback on it.
Step 6: Establish a team nerve-center
It’s amazing how much your team knows about each release candidate. Exploratory test findings, risks, necessary changes to infrastructure, miscellaneous reminders… All kept in the heads of multiple people representing multiple specialties. It’s important to capture the team’s collective knowledge, and commenting on a release candidate in Bamboo lets you do exactly that. Not only does this save project leaders from running around like frenzied chickens trying to assess release readiness, it saves them from having to compile the information into an email or status report, and wrests information out from underneath send-lists. Ahh, sweet liberty.
Warning: between release comments, the Approved/Broken flag, and collated test results, those go/no-go meetings you love sooooooooo much (*ahem*) may become extinct. Dry your eyes, now. Lemme just run and grab you a Kleenex while you download 5.1… I’ll be right back.
Step “X” (extra credit!): Continuously improve
With some slick and time-saving tooling in place, you’ve got more bandwidth for improving the situation on the ground. As much as we wish JIRA and Bamboo could magically cure cultural dysfunction or decouple monolithic applications, they can’t. That’s up to you and your team. Execute this step before, during and after all the others on this list. And go easy on yourself: this stuff is hard, and it takes time. No aneurysms, please.