Making releases a “non-event” is one of the goals many teams aspire to when they adopt agile development practices. That might mean releasing several times daily, or (more likely) at the end of each iteration. Either way, most teams eventually normalize on some flavor of continuous delivery. A common flavor is to build the code and deploy it to a test environment several times a day, then pause at that point in the pipeline. Every few days (or weeks), you look through the builds that passed all the tests, select one as your release candidate, and promote it to production. Bamboo makes use of “manual stages” to set that up.
Adaptability: the next stage in continuous delivery
For the benefit of the uninitiated, manual stages in Bamboo are phases of your continuous delivery pipeline that must be triggered by a human. Builds begin moving through the pipeline automatically and progress up to a certain point, but then pause when they hit a manual stage – a production deploy stage, for example. Maybe every successful build will eventually go out to production, and maybe not. But nothing more happens with a given build until you come along and tell Bamboo to proceed with the next stage. You’re in control.
And now with Bamboo 4.3 we have even more control. As a former auto-test engineer and many-time 2am-production-deploy Verifier In Chief, one of my favorite features in this release is the ability to override build variables when running manual stages. Yeah, it might sound kinda boring at first. But there’s a great application for continuous delivery and testing that I want to share with all my automation nerds out there.
It’s common for builds to be put through a rigorous testing cycle in the pre-production environments, then go through a smaller gauntlet of smoke tests just after the production deploy. With customizable manual stage variables, we now have a way to adjust the contents of that smoke test on the fly. For example, if your release contains a lot of changes in the user account & authentication areas of your application, you can run not just the usual set of smoke tests, but also the full suite of account & auth tests as well. As a bonus, the adjustment is a one-off and your test configs automatically revert back to normal afterward.
How does it look in practice?
I set up an example pipeline that runs from my code repo through production. In the testing stage, I break the test suite into batches based on their functional area of the application so they can run in parallel and save a bunch of time. I prefer using TestNG’s “groups” feature to handle the splitting, with groups for user account, invoicing, etc.
I also have a group of smoke tests to use for testing production deploys. For those, I have the Maven params set as variables.
During an iteration, everything runs as normal with builds happening several times a day. When we’re ready to release, we want to select a build that has already been vetted in the test environments and promote it. This is preferable to rebuilding from scratch – we want to release a known entity! Thus, whatever build we decide to promote, we will find it paused on the manual production deploy stage. From here, we open the Run menu, and select “Run Deploy to Production Customized”. Up pops a little dialogue where I get to override any variable I want. Here, I’m setting it such that my smoke test job will run also do a full run of the user account suite.
Pretty slick. Maybe next release, the standard batch of smoke tests will do. No problem: just run the deploy stage without overriding any variables. Maybe the release after that will need extra attention on the billing system. Easy-peasy. You get to make the choice every time.
Take ‘er for a spin
One thing Bamboo users love is how easy it makes the operations that you need every day. Aggregating test results, passing artifacts downstream, adding build agents… and now on-the-fly config adjustments. Check out our list of 9 more things or start a free trial and see for yourself!