Bamboo Best Practice - Sharing artifacts

Best practice approaches

Sharing build artifacts with downstream processes

目的

Identify and describe how artifact sharing within stages and plans can save time by making build artifacts available to downstream processes.

Learning Outcomes

After completing this section, you will understand:

1. What artifact sharing is
2. How artifact sharing can improve the efficiency of your development process

概要

In most cases a build process will involve generating an application artifact. This is the product of the compiled code, for example a .jar file. Artifact sharing is the practice of building this artifact once, and then passing it to subsequent downstream jobs to perform actions upon it. This is a great way of improving the efficiency and consistency of your development process, because it:

• Reduces the need for multiple checkout and compile operations
• Ensures consistency of tests against a known, single artifact
• Verifies application packaging and distribution behaviour
• Can automatically generate code coverage reports. 

It's clear that artifact sharing across Bamboo stages is a very clever way to to improve your development efficiency. Let's have a look at an example.

シナリオ例

Let's consider the following artifact sharing example:

Stage 1: Checkout & compile - We need to check out the relevant code from the repository and compile it into an artifact. Our artifact is now defined and available for use by downstream jobs. Let's give it a name and specify its location, so downstream jobs can find it, though of course only jobs in downstream stages can consume it

Stage 2: Unit tests - Let's use some Fail Fast methodology and run some unit tests on our artifact before we go any further. We already know these are numerous and fast, but we can use artifact sharing to increase speed even more. Let's make a dependency on our artifact for each of the following testing jobs: Bamboo will then pass it simultaneously across different unit tests

Stage 3: Functional tests - We know these tests take much longer, however by artifact sharing we can, again, distribute the artifact through simultaneous testing stages, saving us more time (and money) 

Stage 4: Deployment - When testing is complete, the artifact can be deployed to a QA environment by a consuming job that runs a deployment script against it

Stage 5: Environment testing - Now that the artifact is deployed, we can run integration tests against the environment we deployed into previously

Extending artifact sharing

Bamboo allows us to extend and take full advantage of artifact sharing. 

Create dependencies based upon a specific artifact: Bamboo allows us to create dependencies upon an artifact that can be passed to jobs in downstream stages. Multiple Jobs within the same Stage can have dependencies on the same artifact, and it is also possible to create multiple artifact dependencies to place the artifact in different locations when multiple artifacts are required.

Cloning artifacts using plan variables: Bamboo also allows us to use Plan Variables to define artifacts for each plan. By defining a plan variable and applying it to the location field of the artifact definition, we can clone a plan multiple times needing only to define the single variable each time. Alternatively, we can define the artifact name as a Global Variable, which avoids having to re-define the variable for each plan clone, and may still be overridden at the plan level. 

結論

Artifact sharing is a powerful technique for making single artifacts available to a multitude of downstream jobs. Artifact sharing reduces the overhead of multiple checkout and compile steps and also creates a known and consistent artifact that can be reproduced and passed to downstream jobs, plans and deployment processes.

How do I configure artifact sharing between jobs?

Artifact sharing between jobs is configured using the Artifacts tab on the plan's configuration:

Check out Sharing artifacts between jobs to learn how to configure your Bamboo server to take advantage of artifact sharing between jobs.

Sharing artifacts between plans

目的

Identify and describe how artifact sharing between plans can be achieved

Learning Outcomes

After completing this section, you will understand how to share an artifact between plans

概要

We discussed above how we can achieve significant time benefits from capturing and sharing artifacts to downstream processes rather than checking out and compiling each time the artifact is required. Generating an artifact at the top of the development pipelie, and passing it to successive downstream processes also has the benefit of ensuring the integrity of the code is maintained throughout the pipeline, because we know it is the exact same code that we tested earlier on. We also discussed how we can manage passing artifacts within a build plan, but let's suppose that we want to pass artifacts between two plans? Easy: We use the download artifact task to make the artifact available from one plan to another.

シナリオ例

Let's consider the following artifact sharing example:

Imagine that we have a build plan that creates and uses an artifact - Artifact A. Now let's suppose that we also have a child plan, and we would like to use Artifact A in this plan for some other purpose. Bamboo doesn't technically allow you to share artifacts between plans (but watch this space), so we can use a work around to get our artifact shared into the child plan: We copy it from the parent plan to a remote storage location, then use the artifact download task to obtain it for the new plan. Note: This approach differs significantly to the process for sharing artifacts between jobs. 

Parent Plan

Step 1: Checkout & compile - We need to check out the relevant code from the repository and compile it into an artifact. Our artifact is now defined and available for use by downstream jobs. Let's give it a name - Artifact A - and specify its location, so downstream jobs can find it, though of course only jobs in downstream stages can consume it

Step 2: Testing - We can use some Fail Fast methodology and run some tests on our artifact before we go any further. We can conduct short and rapid unit tests and longer functional testing on our artifact. But we already know that artifact sharing can be used to increase testing speed in both cases

Step 3: Deployment - When testing is complete, the artifact can be deployed to a QA environment by a consuming job that runs a deployment script against it, but we still need to share it with the child plan

Step 4: Copy artifact out - The final step of this plan is to use a task to copy the artifact out to a remote location such as Nexus or Artifactory, using the applicable Bamboo plugins plugins. Alternatively, simply run a script task to copy the artifact to a remote file server location on your own network

Child Plan

Step 1: Copy artifact in - The first step of the child plan is to use a task to copy the artifact in from where the parent plan left it. Depending on the method you used to copy it out, you may require a task that utilises a Bamboo plugin.

Step 2: Business as usual - Now that we have copied the artifact in, we can perform regular Bamboo operations as part of an ongoing build plan. These could be additional tests, or deployments into different environments

Extending artifact sharing

And of course, once we have our artifact neatly stored in remote storage, the artifact download task means that it can associated with any build plans that we may want to run.

結論

Artifact sharing is a powerful technique for making single artifacts available. Artifact sharing across plans allows us to make artifacts available for different build plans from one checkout and compile. We know that we will always be using a consistent artifact which reduces the time overhead of multiple checkout and compile steps.

How do I configure artifact sharing between jobs?

Artifact sharing between jobs is configured using the artifact downloader task:

Check out Sharing artifacts between build plans to learn how to configure your Bamboo server to take advantage of artifact sharing between plans.