Welcome our guest blogger Sarah Goff-Dupont, Product Marketing Manager for Atlassian Bamboo. Sarah is a former test automation engineer, and a fan of anything that makes life easier for the nerds. Like Continuous Integration and automation, for example. Because manual testing gets boring. Her heros include Margret Thatcher, MacGyver, and her mom.

—

Continuous Delivery is a frequent topic here on the ZeroTurnaround blog. No surprise, right? Many of you are already sold on the idea, and lots of you are putting it into practice already. But others may be reading these posts thinking “Continuous delivery sounds wonderful, but my hurdles are so many and so high, I wouldn’t even know how to start! Lemme go kick off a rolling-restart-fueled hot-patch just to bring me out of my dispair and back into my happy place.”

Sound familiar? If so, then read on.

I’m going to assume that anyone who is so enthusiastic about the craft of software development that they read nerd-blogs like this is also a fan of continuous integration. Well, among our other kick-ass products like JIRA and Stash, Atlassian makes a lovely continuous integration server called Bamboo. We designed Bamboo based on another assumption: that if you care enough to practice CI (or are just lazy and want to make the computer perform your most boring tasks), you also want to practice Continuous Delivery. This means chaining together multiple automated processes into a nice smooth bacon-wrapped-Ferrari-inspired pipeline.

Lots of teams start their CI journey with Jenkins or Hudson, which is great because the $0 price tag removes a big barrier to entry. But when teams get serious about building out that pipeline, “the butlers” start to feel a bit constraining. Stuffy, if you will. That’s when folks turn to Bamboo.

I’d like to show you how Bamboo and LiveRebel can help teams make that giant leap from CI to CD by breaking it down into little baby-steps. First, let’s get hip to Bamboo’s structure. Take a look at the diagram here. Plans are Bamboo-speak for “pipeline” – I’ll let the diagram explain the rest. Plans might go from source code repo all the way out to production, or start by pulling down a pre-built package and testing it on just one environment. Today we’ll focus on the former, ‘cuz it’s more fun.

Plans in Bamboo include one or more Stages, any of which can be designated as “manual”, or push-button – note the little blue checkbox in the picture. Each build of the Plan pauses when it encounters a manual Stage, and resumes at the click of a button when your team is ready to proceed. In the context of moving toward a continuous delivery model, manual Stages can serve as placeholders. A roadmap, if you will. Bake them into your Plan now, then update their configurations one by one as you automate each piece of your pipeline.

Why bother setting up a Plan where some steps are performed manually?

Glad you asked.

Accountability: each progression through a manual Stage amounts to a sign-off that the step was performed successfully

Traceability: see at a glance what build number was last pushed to each environment and what code changes were included

Release Management: when Bamboo is linked to JIRA, marking a version as shipped and executing the release itself happens with just a few clicks

Communication: build result summaries let everyone see exactly where in the pipeline a build is at, decreasing email & IM traffic

Repeatability: tasks that are automated can be reliably repeated, whereas manual tasks carry the risk of human error

Adaptability: you now have a template for replacing manual steps with automation

Let’s dig deeper into that last point. It’s the best part!

Imagine a project with a build server that automatically compiles the code, runs unit tests, and packages it up. Deployments to QA and Production are performed manually (only because you just got LiveRebel and haven’t rolled it out yet). Tests against those environments are a mixture of manual and automated. Let’s see how artifact sharing and Bamboo’s unique concept of Stages can be combined in a Plan that reflects the current process, and
evolves as manual steps become automated.

Here is our imaginary project’s build process, represented as a single Plan in Bamboo. Note that three of its Stages are manual, as indicated by the little grey dots and the “play” button.

Build launches automatically with each commit. At this point, the Plan will fast-fail if, for example, there is a compilation error. Otherwise, if the Stage completes successfully, the Plan’s execution will simply pause. In order for downstream Jobs (like deploys) to utilize the packaged build, you must tell Bamboo to share the build artifact.

Deploy to QA is a manual Stage. The deploy engineer will use Bamboo to find the most recent successful build and it’s artifact. After deploying, they will come back to the Plan and press the Continue button to indicate the step is complete. Note that you need to include a “dummy” Job in your manual Stages when using them in this way; a simple command that echoes “Insert LiveRebel here!” to the logs would suffice.

Auto Tests on QA is automatically triggered by the successful completion of the previous Stage. Its two Jobs will run in parallel if two build agents are available. Otherwise, they will run sequentially.

Manual Tests on QA will pause the build again, assuming the automated tests succeeded. This is a signal for the manual testers to begin their work. Once testing is complete, the QA team comes to the Plan and signs off on the manual testing –again, using the Continue button.

Deploy to Production is where most builds of the Plan will end, until the team feels confident pushing new code out with each build. In the meantime, everyone on the project knows that this builds that reach this Stage could go live without introducing any new defects. When it is time for the production push, the deploy engineer will again pull up the appropriate build in Bamboo to find the artifact, deploy it, then sign off on that Stage by clicking Continue.

Auto Smoke-Tests on Production will then kick off automatically, completing the final step in the process.

Finally, the juicy part: updating the deploy Jobs to use the LiveRebel Deploy task, and updating the corresponding Stages to execute automatically. First, make sure the artifact produced upstream is shared with this deploy Job (for more on that, see Bamboo’s help docs, and/or this helpful blog). Then head to the configuration screen for the deploy Job and choose Tasks > Add Task > Live Rebel Deploy Task > Add. Now punch in the details: you can use this Task to upload an artifact to the LiveRebel Command Center, deploy an artifact, or un-deploy it. Each action comes with it’s own set of advanced options you can customize. You’ll also select which server(s) to target, choosing from the set of servers you defined when setting the global configs for the plugin. Once this Task is configured, delete any placeholder or other now-unnecessary Tasks.

To make the deploy happen automatically with each build, go back an un-check the “Manual” option on the appropriate Stage. Or just make Bamboo and LiveRebel do the heavy lifting, but leave the Stage set as push-button so you retain control over when it executes.

This principle of iterating on your builds can be applied anywhere in your pipeline. Perhaps the QA engineers reach their goal of automating all manual acceptance tests. Once again, the Plan can evolve: delete the manual testing Stage, and add Jobs to the auto-test Stages as needed to run your thoroughly-sweet suite of tests. Rinse & repeat until your desired level of automation is achieved.

By gradually progressing along the application deployment spectrum in this way, you march steadily toward your objective while avoiding ghastly organizational upheaval in its pursuit. It’s like eating an elephant, my friends: one bite at a time. Share your manual-to-auto transition story by posting to comments. You might just inspire someone! And if you haven’t checked out Bamboo, you can learn more here. It’s free to try for 30 days. Just sayin’…

The problem I’m seeing using bamboo as you have described is that it doesn’t implement “who can approve” the manual stage. For small shops where this is the development team itself, that’s ok, but for enterprise, where we need sign-off from QA, security, production support etc, its a must.

The deployment projects don’t seem to implement gates in the pipeline either, though you can fudge it by setting permissions per environment.

I find bamboo fantastic for the build phase / continuous integration, but I don’t see it being mature enough yet for continuous delivery… In fact I’m hard pressed to find a project that is mature in this area.