Humans have been making software for a surprisingly long time: from the proto-software devised to decrypt Enigma-encoded transmissions in the 1940s, to the read-only program controlling the descent of Apollo lunar modules, to the dizzying array of apps we carry in our pockets and purses today. But throughout the computer-age revolution, one thing that hasn’t changed is the need to deliver software so it can be put to use.
Today, this means updating your production environment, and/or making an updated distribution available for customers to download. Both types of release methods require a whole lot of coordination between developers, testers, and operations to get changes promoted through internal environments and eventually out to the customer.
In this article, I'll talk about ways these oft-siloed groups can join forces on release management using JIRA Software, Bitbucket, and Bamboo.
Understanding what has changed
No matter your role in delivering software, you need to understand the changes from one version to the next. And in all likelihood, you need this information at a more granular level than the version numbers marketing puts on advertisements or product managers put in JIRA. Each neat externally-facing version number has several internal versions behind it – usually called release candidates (RC) or milestone builds – one of which will eventually be released to customers.
We've traditionally understood those changes almost by osmosis: through stand-ups, and by having the team’s agile board easily visible to all. And in the days between a release to customers and the first release candidate version for the next one, this is enough to get by on.
But in the final days and hours before a release, as the intensity increases and the final polish is put on, it’s the subtle differences between those release candidate versions that matter most. You need to see what changed between RC1 and RC2 through the lens of builds, commits, and ultimately, issues.
What we built into Bamboo is a way to see what JIRA issues and commits are associated with each RC build. Here's how it works.
By now, you probably know that when you put JIRA issue keys into commit messages, Bamboo picks sees that and associates the resulting build with the issue. But when you create a release from a build in Bamboo (think of these as RCs), Bamboo finds all the issues associated with all builds since the previous release, then presents the roll-up on a single screen.
To see it, start from the Releases tab inside your deployment project and click on the release you're interested in. You'll see all sorts of details about the release on the next screen – click the Issues link near the top-left of the screen to get the roll-up.
Pro tip: This roll-up will still be easy to access after the release (hopefully just for analysis purposes, but it's also helpful when troubleshooting a production emergency!).
From that same Issues screen, you can also compare the changes between the current release and any other release in that project – not just the most recent one. For example, you might want to compare the upcoming public release to the last public-facing release. You'll see all the JIRA issues associated with all the internal release candidates. (This is a great way to start compiling release notes, btw). Similarly, you can pop over to the Commits tab and make the same comparisons.
Understanding what has been tested
With the quantitative aspect under control, it’s time to get a handle on the qualitative picture. Fortunately, releases in Bamboo are a good vehicle for this.
The detail view of each release shows a list of all the CI builds that were run against the commits in this version, and their results. Over on the right side, the build number that produced the artifacts is shown as well. When Bitbucket is integrated with Bamboo, results from these builds will be shown in your repository, too. Select your repo in Bitbucket, the specific commit and branch you want to look at and check the build result at the far right side of the screen under the "Builds" column.
There are loads of other juicy tid-bits on this page, like deployment status, shortcut links to promote the release to the next environment, and a place for anyone involved to leave comments. So make sure your developers, testers, sys admins, and product managers know how to access this screen. (Incidentally, if I wanted to look at release 1.3.0 in the E-commerce Site Deployment project, as pictured here, I'd select All Deployment Projects from the Deploy drop-down at the top of the screen, then click on E-commerce Site Deployment > Releases > 1.3.0.)
Ultimately your team has to reach a go/no-go call on each release candidate version. Here’s where collaboration and efficiency becomes absolutely critical, so it's important to understand how your tools help you out.
First, any version in Bamboo can be flagged as approved or broken. Much of the time, that’s all you need to know – and just like that, you’re back to whatever else you were working on.
Team members can also comment on builds under the build summary page and deployment releases, just like they comment on issues in JIRA Software, or pages in Confluence. A sys admin or build engineer might note how the deploy to staging went and what to watch for on the production deploy. QA might confirm what was manually spot-checked or shares concerns about pieces that need more testing. Devs might add context around why a change was made. The point is that everyone can drop that information in a central place where it's easy to find.
Though the features explained above bring ease and visibility to your continuous delivery pipeline and release process, you also have a dashboard in JIRA Software (versions 6.4 and above) that provides even more info about release readiness: the release hub, accessible from the sidebar.
The release hub integrates with the rest of your Atlassian developer tools to highlight unreviewed code, open reviews, un-merged pull requests, and failing builds. It sort of keeps the team honest as to the true status of a release. For example, if an issue is marked as complete, but the pull request was never accepted and the branch is still un-merged, that'll be flagged here.
Of course, every team has different processes and different standards. If, for example, unreviewed code isn't worrisome to your team, you can tell the release hub to ignore those. Click the manage warnings button on the right side of the screen and adjust the settings as you see fit.
In the end, understanding when you're ready to ship is a very "human" process for most teams – especially if you're just getting started with continuous delivery. We hope the tools and features I've talked about here will to save you time and increase the level of visibility you and your team have into each release so the go/no-go decision is easier to make. (And if not, tweet us up at @Atlassian and tell us how we can improve!)