Continuous Delivery, One Byte at a Time (Part 1)

K15t Company

Published on December 5, 2019 in

4 minutes read

This is a guest blog post by Sarah Goff-Dupont. Sarah is an agile delivery evangelist with Atlassian, 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 heroes include Margret Thatcher, MacGyver, and her mom.

Software shops everywhere are buzzing about continuous delivery. Many of you are already sold on the idea, and some of you are putting it into practice already. But others may be thinking “Continuous delivery sounds wonderful, but my hurdles are so many and so high, I wouldn’t even know how to start! I'll just go drown my dispair in another cup of coffee...”

Sound familiar? If so, read on to learn how Atassian's CI server, Bamboo, lets you gradually add more automation to your build process until you reach continuous delivery nirvana. In part one, we'll talk about the initial build Plan and how to evolve it. Part 2 will dig deeper into artifact and test configuration.

Using Manual Triggers to Build a Continuous Deploy Framework

Any Plan in Bamboo can include one or more manually triggered Stages. Each build of the Plan pauses when it encounters such a Stage, and resumes at the click of a button when your team is ready to proceed.

In the context of moving toward a continuous deploy model, manually tirggered 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?

Accountability: each progression through a manual Stage amounts to a sign-off on it’s success
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 j ust 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!

Combine Manual Steps and Automated Steps

Imagine a web application. It can be compiled, unit-tested and packaged up automatically, each time a change is made. Deployments to QA and Production are performed manually. Tests against those environments are a mixture of manual and automated. Let’s see how to create a Plan that reflects the current process, and can evolve as manual steps become automated.

Here is our imaginary project’s build process, represented as a single pipeline in Bamboo.

Notice that several Stages have been configured with manual triggers:

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. More on that in part 2!
Deploy to QA is a manually triggered Stage. The deploy engineer will use Bamboo to find the most recent successful build and it’s artifact. After manually 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 placeholder Stages - in this example Plan, all the Jobs for manual Stages run a one-line script that echoes “hello world”.
Auto Tests on QA is triggered automatically by the completion of the previous Stage. Its testing Jobs will run in parallel to save time.
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 as far down the pipeline as most builds will get, unless the team feels confident pushing each successful build live. Regardless, everyone on the project knows that builds which 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, manually 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

Evolution is the Solution!

Our imaginary scenario is a target-rich environment for automation. Perhaps the Operations team takes on a project to condense their deploy runbook into a single script. Simply update the Job in the deploy Stages to run the new script, and update the Stage to execute automatically. Some time later, 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.

By gradually progressing along the continuous deploy spectrum in this way, you march steadily toward your objective while avoiding ghastly organizational upheaval in its pursuit. It’s the same as how you eat an elephant, my friends: one "byte" at a time.

Stay Tuned

Stay tuned for part two of this series. We'll shed some light on the tips, tricks and gotcha’s to make your process sing. In the meantime, check out some of the other ways Bamboo helps you make a kick-ass continuous delivery pipeline.

Do you want to know more about Continuous Delivery and Bamboo? We know the pros and cons about it and will be happy to discuss with you.

Get in touch with us: contact@k15t.com

Share this article ✕