We spend a lot of time on the Bamboo team thinking about how to make really excellent continuous integration (CI) as easy and accessible as possible. Today I’m delighted to share some progress we’ve made on that front, in two ways.

Artifact sharing between plans

Yes! You asked for it (Atlassians have been asking for it, too), and now it’s here. For the benefit of Bamboo newbies (Bam-noobs?), let’s back up and look at what’s changed.

plan_nav

Bamboo has always been able to pass build artifacts to downstream steps within a single CI pipeline, which we call a plan. Let’s say that you have both hyper-fast unit tests and longer-running integration tests in your plan. You’ll probably want to set it up so that the first stage compiles, runs unit tests, and – if those steps are successful – produces a .WAR file. In other words, push the quick stuff to the top of your pipeline so if the build fails on one of those steps, you’ll know about it ASAP (and won’t waste precious server capacity on the stuff that takes longer). So the integration tests go in a second stage. But wait! They rely on that .WAR file! No sweat. Bamboo will kindly pass the .WAR downstream, all tidy and under-the-covers like. Check the docs for help setting that up.

But what if you have a test pipeline that relies on artifacts produced by multiple plans? It’s a common use case that, admittedly, we weren’t handling very well until Bamboo 5. Our own teams at Atlassian handled sharing artifacts between plans by sending a copy of the artifact to an external server (Apache Archiva, or similar) as a final step in the artifact-producing plan, then pulling it down via SCP as the first step in the plan that relied on it – or some variant thereof.

But that’s all changing with Bamboo 5. No longer do you need to send your .TARs, .JARs, and .ZIPs off to a temporary storage location. Now there’s a handy artifact download task that can pull in artifacts from any other plan at any point in your CI pipeline.

Got suites of tests that you don’t want to run with every single commit? (Performance tests and platform-specific tests come to mind.) Put those tests in a separate CI plan that runs at scheduled intervals and pulls in the latest artifacts from the parent plan. What’s more, let’s say you have a Bamboo deployment project that releases the build artifacts from “Plan A”.  Using the artifact download task to pull an artifact from, say, “Plan B” into “Plan A” allows you to send both artifacts out for release with a single deployment.

CI_downloadartifact

DPL_multipleartifacts

As promised, other best practices

While most of us here in Dev Tools land have been caught up in the excitement of Bamboo’s new deployment capabilities and their cool integrations with JIRA, documentation stalwart Nathan Pye has been nose-to-the-grind creating best practices guides for Bamboo. Yes! You asked for ‘em, now we’ve got ‘em.

Along with the guide on artifact sharing, Nathan has published best practices guides on using stages in your CI pipelines, system requirements, and applying CI to a feature branch workflow. And coming soon (like, within the next week), we’ll add a guide to using build agents, with a guide to deployment and releases coming soon after that.

What other best practice guides would you like to see? Drop a comment and let us know!

Learn more about Bamboo

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

View all posts by Sarah Goff-Dupont »