Bamboo Best Practice - Using stages
Overview
The basic process for continuous delivery is Build > Test > Publish, which can be repeated multiple times before a release candidate is identified and shipped.
This page describes two approaches to using stages in Atlassian Bamboo. Many people will find that the first approach, Continuous integration, will meet their requirements, and we recommend that as a starting point. When you have that operating, you can build on it using more advanced methodologies.
On this page:
Fail fast – detect failures as early as possible
Fail fast is used here in the context of continuous integration. It's a development paradigm that emphasizes the early detection, notification and correction of build failures. Early detection allows early correction, so reducing impact on the project. Furthermore, if we detect problems early, we won't need to execute the rest of the build process, so saving time and resources.
Example Scenario
Let's consider the following simple scenario that uses a series of tasks within a single job. We only need a single stage for this. Typically, unit tests exist in close association with the source files, and are run at, or soon after, compile time.
Task 1 – Check out: We need to check out the relevant code from the repository. Best practice with Bamboo is to set up a linked repository that can be referenced by several plans and that can be updated in just one place. See Checking out code.
Task 2 – Compile: We can configure a builder task to compile the code. If syntax errors are detected, there is no point in performing the unit tests. See Configuring a builder task.
Task 3 – Run unit tests: Unit tests rapidly identify problems with how code runs. This quickly identifies semantic errors. See Configuring a test task.
Task 4 – Create artifact: Often, you will want Bamboo to keep build artifacts, such as reports and binaries, that can be used later. See Sharing artifacts.
Artifact promotion – ship the tested binary
The promotion of build artifacts, especially binaries for use in later phases of the pipeline, is a key concept in continuous integration. Not only can this save time and resources, but crucially, it ensures that a release candidate that could potentially ship to customers contains exactly the code that was tested throughout the pipeline.
In Bamboo, artifact sharing between stages is the mechanism used to promote artifacts.
Example scenario
Let's consider the following scenario that adds further stages compared with the Fail Fast scenario above. These extra stages are used to add functional and integration testing, and to provide a manual stage to provide control over when publishing happens.
Stage 1 – Fail fast: This is just the continuous integration stage described in the earlier scenario. The generated artifacts are marked for sharing in later stages. See Sharing artifacts.
Stage 2 – Run functional and integration tests: We can split these tasks into multiple jobs so they will run in parallel, so reducing the time taken. Each job uses the same artifacts generated in Stage 1. If any job fails, then later stages will not be run.
Stage 3 – Publish: We introduce a manual stage here for this example, but this could an automated stage. A manual stage gives us a control point that pauses the pipeline, to allow us, for example, to make a business decision about whether the release candidate should be published, and when. We only run this stage when it has been approved.
