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 decent 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 into use. Today, this means updating your production environment, and/or making an updated distribution available for customers to download.

Both types of software releases 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 series, I’m going to talk about two ways these oft-siloed groups can join forces on release management, and how those ideas shaped the upcoming release of Bamboo 5. Part one will cover improving communication around release candidate builds (aka “getting into each other’s heads”). Then part two will dive into removing overhead associated with deployments (aka “getting out of each other’s way”). Let’s get started!

Understanding what has changed

No matter what your role in delivering software, you need to know 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, clean externally-facing version number has several internal versions behind it–usually called release candidates or milestone builds–one of which will eventually be released to customers.

blog_versionhighlight

During most of your iteration or release cycle, the team is focused on the overall body of changes in development. QA needs this holistic view to assess the riskiest areas and ops needs it to prepare any changes to the IT infrastructure. We have traditionally understood those changes almost by osmosis through stand-ups (including testers, ops and product managers in stand-ups helps a ton, btw) 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. The short time into which we squeeze performance tests, exploratory tests and spot-checks when a new RC hits the staging environment magnifies every little inefficiency in your process. We’ve found that the agile board doesn’t provide enough detail to easily see what changed between RC1 and RC2; commit histories don’t sufficiently tie changes to builds; email threads take too long to circulate and invariably leave some key player out of the loop; and spreadsheets… let’s face it: keeping them updated and shared is just plain maddening. Maybe you’ve felt this pain, too.

What we wanted, and what we built into Bamboo 5, is a way to see instantly what JIRA issues and commits are associated with each RC build. Allow me to geek out for a moment and tell ya how it works.

Developers are already in the habit of putting JIRA issue keys into commit messages. Check. Bamboo already picks this up and associates the resulting build with that issue. Check. And now, when you flag a build as a version (ie, a release candidate), Bamboo finds all JIRA issues associated with all builds since the last RC, then presents the roll-up on a single screen.

blog_issuesforversion-1

No more email chains, or mad dashes to each other’s cubes, or notes written on the back of your hand while cross-referencing commit timestamps with issues with builds. Information needed by every team member in every role is shared automatically. What’s more, it will still be easy for all to access after the release (hopefully just for analysis purposes… but we can’t ignore how helpful this is when troubleshooting an emergency!)

Understanding what has been tested

With the quantitative aspect under control, it’s time to get a handle on the qualitative picture. This is another place where looking at defects filed, blitz testing sessions run, and automated tests added gets you by before it’s time to cut that first RC build. But that’s not the interesting use case.

With each release candidate, it’s typically QA’s responsibility to assess whether this build is fit for public consumption. Again, time is of the essence. We found that devs and testers alike spent too much time manually finding the commits since the last RC was cut and manually connecting them with test runs in order to determine risk and quality. Call us lazy, but we wanted a computer to do that for us.

blog_versiondetails

Fortunately, versions in Bamboo provide the perfect vehicle. The detail view of each version 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. Not only is this a huge time-saver for QA in and of itself, but it makes quality information easily visible for ops and product managers as well. This means fewer emails, IMs and drive-bys asking testers for an update. Because a quality summary is automatically shared with everyone, QA is freed up to dig a little deeper, or make the approved/rejected decision faster. Maybe both.

Speaking of approvals and rejections…

Ultimately your team has to reach a go/no-go call on each release candidate version. Here’s where collaboration becomes absolutely critical. We’ve all done go/no-go meetings, and we all know what a pain they are to prepare for and sit through. Someone is running around to each dev and tester, adjusting a spreadsheet; the team member working remotely is writing an email with their thoughts; notes on outstanding issues and their priority are put on a whiteboard during the meeting. Information is left in too many different places and far too many staff-hours are spent on the whole affair.

We loath this as much as you do. So we added two features to Bamboo versions that make the go/no-go consensus easier to reach. 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 you were working on.

Team members can also comment on versions, just like they comment on JIRA issues or Confluence pages. Ops notes how the deploy to staging went and what to watch for on the production deploy. QA confirms what was manually spot-checked or shares concerns about pieces that need more testing. Devs add context around why a change was made. Questions are asked, answers are provided–adding up to a single source for the team’s collective knowledge about a version, recorded for all to see.

blog_versioncomments

Improved communication around releases is only one of the big changes you’ll see in Bamboo 5. Stay tuned for part 2 of this series, where I reach back to my political science education and talk about removing the bottlenecks involved in getting release candidate builds promoted from one environment to the next. (Awwwwww, yeah.) You’re gonna love this part.

 

ps: Antsy for a closer look at the goodies you just read about? Grab a full-feature beta build of Bamboo 5 and start playing with it today! UPDATE: Bamboo 5 has landed! Take the tour here.

 

About Sarah Goff-Dupont

I've been working in and around software teams since before blogging was a "thing". When not writing about all things agile, automated, and/or Atlassian, I can be found reading contemporary fiction, smashing it out & keeping it real at CrossFit, or rolling around on the floor with my kids. Find me on Twitter! @DevToolSuperFan

View all posts by Sarah Goff-Dupont »