In part 1 of this mini-series, I introduced the concept of using manual 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 manual Stages (dig deep in part 1 of our blog series to learn more about artifact sharing). 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.
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.
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 “artifact-s-“; and yet, the screenshots above show a single artifact containing both the application and the automated test code. 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 live 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. This is vital for guaranteeing that the same code is used throughout the Plan’s execution. You will also keep your Jobs’ run time leaner and more consistent from build to build. Bonus! 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?
Download Bamboo for evaluation, or start a free trial of Bamboo OnDemand. Our support team, online documentation, and Atlassian Answers site are here 24/7 to help boost you over any hurdles you encounter.
