Bamboo 5 Bridges the Dev-Ops Divide!

The arm-chair historian in me loves digging into the great rivalries the world has known over the years. Hatfields vs. McCoys. Elizabeth I vs. Mary Queen of Scots. Coke vs. Pepsi. Maybe what makes these epic struggles so fascinating is the fact that we software makers live in a world of (admittedly more banal) tug-of-wars every day–which is exactly what inspired our bold new vision for Bamboo 5.

Today we are delighted to introduce deployment projects: harnessing the power of continuous delivery like never before and bridging the gaps that divide one team from another.

Creating and shipping software is fraught with tension. Developers are eager for their work to hit the market, while operations staff want to ensure platform stability. Product managers and marketers love feature-packed releases, while testers champion quality over quantity. And everyone wants a 360-degree understanding of how the project is progressing without their work constantly being interrupted by status meetings.

These are opposing cultural forces that tools won’t magically eliminate. (Nor should they–a bit of organizational tension is healthy!) But tools can take the edge off. Let’s take a look at how deployment projects in Bamboo 5 put some of software development’s fiercest rivalries to rest and help level up your cross-team kung fu.

Build Meets Deploy

Traditional tools do one or the other well. In deployment tools, little attention is paid to where the deployable artifacts came from or their level of quality. In continuous integration tools, releasing is sort of an afterthought unless you’re continuously deploying the latest build as soon as it passes tests. And let’s face it: that just isn’t a good fit for most projects. So teams have been building and testing continuously, then relying on emails, spreadsheets and duct tape to connect builds to their release process.

Enough of that. With Bamboo 5, you continue building and running in-process tests just as you do now. When a build is deployed to a human-accessible environment, flag it as a release so you can track its progress through each of your environments. Releases act as a container for the artifacts themselves, plus a wealth of related information: commits, JIRA issues, which builds produced and tested the artifacts, which environments the release has been deploy to and by whom.

This build/deploy fusion is utterly unique to Bamboo, and benefits everyone on the product team. Sys-admins and build engineers can automate their deployment work the way developers and QA have long been able to automate their testing process. Not only that, but they can instantly see how the artifacts have been tested when assessing risk around a release. Testers, developers and product managers get a window into the Ops world with the ability to see where a version is running right now, and whether it’s been approved for promotion.

Bamboo’s deployment projects are a powerful way to aggregate your team’s collective knowledge about a release build into a single source of truth, while retaining the ability to make human decisions about what gets deployed and when.

Visibility Meets Overhead

It would be impossible to execute against a roadmap, mitigate risk, or troubleshoot emergencies without understanding the changes from release to release. But the never-ending task of updating spreadsheets or scouring archived emails is a real pain in the SaaS.

Bamboo 5 goes far beyond just linking JIRA issues to builds. By connecting Bamboo to JIRA, you get a roll-up of all the issues, and their associated commits, implemented between any two releases you deploy. It’s a crystal ball for Ops, making child’s play out of anticipating what they’ll need to deploy and support in production.

And coming soon, the updated JIRA-Bamboo plugin will surface deployment status inside the issue itself. No longer will testers waste time figuring out whether a story is ready to be verified and where. (If you’ve ever been a tester, you know how totally boss this is.) Support staff can confidently tell customers where a fix for the defect they reported is in the pipeline. Project managers can see instantly whether a feature made the latest release candidate.

Dev Meets Ops

This is the biggie. The elephant in the room and the 500lb gorilla, wrapped into one. Devs and sys-admins get a bad rap (sometimes deservingly) for having an antagonistic relationship. Given the way the two groups have been siloed by well-intentioned management over the years, it’s no surprise that we’re having to re-learn how to step outside our fiefdoms and work together.

Inspired by the DevOps movement, we added features to Bamboo 5 that help devs and sys-admins collaborate. In addition to cross-pollinating dev- and ops-centric information by way of deployment projects and releases, it’s now easier for the team to communicate about release readiness. First, being able to comment on bundles means the team can share thoughts on what was found during testing or what infrastructure changes might be needed to release it. Unlike email, comments are fully democratic–everyone can participate, regardless of whether they were included on a send list–and create an open record to refer back to later. Second, each bundle can be flagged as Approved or Broken. An approval communicates the sign-off from QA, while a broken flag alerts Ops that a release may be delayed and spurs devs into action.

Speed Meets Control

It’s pretty rare to get one without sacrificing the other. Driving a Ferrari or flying an F-1 fighter jet are decent examples. And thanks to per-environment permissions, so is deploying with Bamboo. Granular permissions for users and groups control who can configure a deployment job, who can execute it, and even who can view the deployment information for each environment.

Obviously, this is a big administrative win for large organizations with dozens of projects to manage and hundreds of work groups. The day-to-day impact for individual team members is just as big. Sys-admins are often mistaken for control-freaks who deny others access to servers just for the fun of it. And developers get a bad rap for being cowboy coders who assume that, because it worked on their machine, of course it will work in production. These are just stereotypes of course, but Bamboo 5’s per-environment deploy permissions help you balance the competing priorities that gave rise to them.

Devs and QA can self-service deploys to their own environments while production and other sensitive environments stay locked down. Dev-speed bottlenecks are removed, Ops has fewer deploy requests to service, and stability-minded security wonks can sleep well at night. It may not bring everyone around the campfire to sing Kumbaya, but it’s a start.

Bamboo 5 is the first tool of its kind to give deployments the first-class treatment. We’re making a true continuous delivery tool, with loads more goodies to come throughout the 5.x series of releases. Upgrade your instance or start a free full-feature trial and see what a difference Bamboo makes.

A huge thanks to our beta program participants! Your feedback and suggestions were tremendously helpful in putting the polish on this release!

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

Comments (10)

We’ve been using the EAP of Bamboo 5 for quite a while now and Bamboo’s new deployment feature is very clean, but how would one use the deployment when using git flow / feature branches, or is that not possible at all?

We’d prefer not having to store the tasks required for deployment in the deployment project for develop/master and again for the branches in the old-fashioned way…

By Markus on July 15, 2013

We hear ya! You’ll be happy to know that extending branch support into the deployments realm (similar to our Plan Branches feature on the build side) is on our short-term roadmap. I can’t promise when it’ll be available, but the dev team starts work on it this sprint.

Does bamboo 5 support a workflow for deployments similar to what there is in jira? Is there a way to restrict certain deployment transitions from one environment to another ?

By Raymond Keating on July 17, 2013

Right now, the best way to restrict transitions from one environment to another is with deploy permissions. That is, allow only certain users to make deployments to, say, Staging (and make sure those users understand the circumstances in which it’s considered “ok” to do so).

However! We do have deployment rules on the short-term roadmap, which will be a more direct answer to your use case. For example, deploys to Staging cannot be triggered (by anyone) unless QA has approved the release, or unless all related CI builds are passing, or some similar criteria.

Cheers!

By Sarah Goff-Dupont on July 18, 2013

Since the new Bamboo is now available on OnDemand as well, we’re investigating new options. Once thing, which would be a great change for us:

In the job overview listing, green icons = ok state, red icons = build problems. So good so far. Blue icons are for jobs currently processing as well as (!) looking for new code (triggers). We’d be happy if blue could be just for processing, as something really happens, and the triggers (checking for new code) NOT. The icons are similar, and you’d have to look very close to see the difference, which is not easily possible from the distance.