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

5 min 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 Margaret Thatcher, MacGyver, and her mom.


In part 1 of this mini-series, I introduced the concept of using manually triggered Stages in Bamboo to set up a Plan that evolves as more and more of your build, test, and deploy processes become automated. When putting it into practice, there are some nuances to keep in mind, and "gotchas" to avoid. In part 2, I will cover these in some depth so you can look like the continuous delivery rock star you are!

Sharing is Caring

Artifact sharing is not exclusive to Plans with manually triggered Stages. In fact, nearly all multi-Stage Plans use it to some extent. Referring back to our example Plan, the first Stage produces a build artifact (a JAR in this case) that subsequent Stages need to use in one way or another. Artifact sharing is configured at the Job level in Bamboo.

Go to the appropriate job, and define which artifacts to share. Next, link the artifacts to all downstream jobs that will consume them.

Now when the Plan executes and successfully creates artifacts, they will appear on the Build Results Summary as well as in the Job Results for that build, on the Artifacts tab. At deploy time, they can be downloaded directly from Bamboo and the deploy engineer can work their magic with them.

 

Just click on the artifact name, and it will be downloaded to your local disk. You can also fetch artifacts directly from your Bamboo server at {$BA MBOO_HOME}/artifacts/{$PLAN_KEY}/shared.

Getting the Right Tests for the Build

Because you are sharp as a tack, dear reader, you have noticed that I've been talking about "artifactS"; and yet, the screenshots above show a single artifact containing both the application and the code for automated testing. This is because in my example project the application and tests live under the same parent directory, so they get packaged together as a matter of course. Capturing the application and test code simultaneously ensures their versions are compatible. If they are out of sync, false test failures may arise later in the pipeline --especially if days (or weeks!) have passed between the initial application build and, say, running smoke tests after a deploy to production. If application and test code lives separately, simply configure a shared artifact for each and pass them to downstream jobs as appropriate.

Disappearing Act

Speaking of chronological chasms between build and deploy, it is important to ensure that your artifacts will still be there when you need them. Else, imagine the horror! (*gasp*) Be sure to verify that your Build Expiry configuration will keep artifacts alive on your Bamboo server for a period of time that is appropriate for your deploy cadence. You may wish to label artifacts deemed suitable for production deploy and tell Bamboo never to delete builds with that label.

You Can Checkout Any Time You Like (but don't do it more than once)

Finally, make sure that Jobs in your Plan don't duplicate a checkout task --good advice for any Plan. You will keep your Jobs' run time leaner and more consistent from build to build. When adding a new Job, a source code checkout Task appears by default, regardless of which Stage it belongs to. Delete it when it would be redundant, and proceed with adding more Tasks.

Ready to Give it a Whirl?

Bamboo will get you started with the basics of continuous integration, and grow with you as you move into the fancier stuff. Take the tour, start a free trial, and see for yourself.


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