This is the documentation for Bamboo 5.6. View this page for the

Unknown macro: {spacejump}

of Bamboo, or visit the latest Bamboo documentation.

Key to getting the most out of deployment projects is understanding what releases are, and how you should be using them.

It is also important to understand the difference and relationship between 'artifacts' - the results of a build plan - and 'releases' - a snapshot of artifacts at a specific time that can be deployed somewhere.

On this page:

What are artifacts?

When the continuous integration process is triggered by a developer committing code, the first stage of the process compiles the code, runs tests and then assembles the code into binaries. These assembled binaries are known as 'artifacts'. The build process can produce build artifacts at any stage of the build that can then be shared with other builds or deployment projects.

Since Bamboo manages artifacts, any artifacts that are needed by builds or deployments are automatically transferred by Bamboo to a remote server as needed, so long as that build or deployment project declares that it needs the artifact to complete its work.

For more information, see Configuring artifact sharing between jobs. 

What are deployment releases?

Releases are used to track exactly what software was deployed to an environment. In essence, a release is a snapshot of any number of artifacts that will be used in the deployment process and their associated metadata, such as JIRA issues, code changes and any test metadata that might be relevant to what is being deployed.

A release is created from the result of a single build. When you view a release, you can see all the code changes, JIRA issues and other metadata that were used when making the artifact for that build. This information can be used for purposes such as release notes, quality control and infrastructure planning, and allows you to compare any two releases to see the changes between them.

Why use releases?

In Bamboo, releases are tracked against environments, which represent a server or group of servers that you wish to deploy your software to. Because each environment can only host a single active release at any one time, Bamboo gives a unique release name to the software being deployed. By checking the environments for our project, we can quickly identify:

  • Where releases have been deployed
  • Which release is currently deployed
  • The release deployment history
  • The release deployment status. 

Another key feature of releases is that as well as providing a deployable snapshot of your artifacts, they also collate the JIRA issues, commit record and test & build metadata for the specific series of changes associated with the release. This enables much smoother reporting and tracking as the release moves through your environments, and allows you to easily track changes between releases.

How artifacts and deployment releases work together

The relationship between artifacts and releases shows the 'hand-over point' between Bamboo builds and Bamboo deployments.

As the diagram shows, a developer who is responding to JIRA issues, commits a code change and triggers a build. This build produces a number of artifacts. In a deployment, these artifacts are assembled into a release, and the JIRA issue, commits and test/build metadata are added. This release then gets a unique identification name which serves as an identifier throughout the system. You can define the unique identifier according to your needs using the release naming system.

Once a release has been created, it is now ready to be deployed to an environment.

The next step

The next step is to examine and understand the deployment project workflow. Learn more about the deployment project workflow.

  • No labels

 

 

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.