Bamboo CI/CD: Build Plans vs Deployment Projects

Stop bundling builds and deployments. Learn how to use Atlassian Bamboo's Build Plans and Deployment Projects to create immutable, versioned releases using Artifacts.

The 'Build-to-Deploy' Friction

A common mistake in CI/CD pipeline design is treating the build and the deployment as a single, linear sequence. When you bundle the compilation, testing, and environment-specific deployment into one long script, you create a rigid pipeline. If a production deployment fails due to a network glitch, you are forced to re-compile and re-test the entire codebase just to try the deployment again. This wastes compute resources and introduces the risk of deploying a different version of the code than what was originally tested.

The solution in Atlassian Bamboo is the strict separation of Build Plans and Deployment Projects, bridged by Artifacts. By treating the build as a producer of a versioned package and the deployment as a consumer of that package, you ensure that the exact same binary moves from Staging to Production without being rebuilt.

Defining the Hand-off with Artifacts

In Bamboo, a Build Plan's primary goal is to produce an Artifact—a versioned, immutable set of files (like a .jar, .war, or a zip archive) that represents a specific commit. Instead of leaving files on a remote agent's disk, you define an artifact in the plan configuration.

When you define an artifact, Bamboo captures the specified files from the agent and stores them centrally. This creates a \"single source of truth.\" If you need to roll back to a version from three days ago, you aren't re-running a build from an old commit; you are simply telling the Deployment Project to redeploy a previously stored artifact.

Orchestrating the Deployment Project

While Build Plans handle the how of creation, Deployment Projects handle the where of delivery. A Deployment Project allows you to define multiple environments (e.g., Development, QA, Staging, Production) as a series of gates.

Automated Triggers: You can configure a deployment to trigger automatically as soon as a Build Plan successfully creates a new artifact.
Manual Approvals: For production environments, you can require a manual \"click-to-deploy,\" ensuring a human verifies the QA results before the code hits live users.
Environment Variables: To avoid hardcoding database strings or API keys in your build scripts, use Deployment Variables. These allow the same artifact to behave differently in Staging than it does in Production.

Worked Example: Promoting a Java Application

Consider a scenario where you are deploying a Spring Boot application. Here is how to configure the hand-off:

1. Build Plan Configuration

In your Build Plan, add a Maven or Gradle task. In the Artifacts tab, define the following:

Artifact Name: app-binary
Location: target/*.jar

Check: After running the build, verify the \"Artifacts\" tab in the build result shows the .jar file.

2. Deployment Project Configuration

Create a new Deployment Project and link it to the Build Plan above. Create an environment named Production and add a Script Task to move the file to the server:

# Run this on the target server via a remote agent or SSH task\n# ${bamboo.deploy.version} is a built-in variable provided by Bamboo\ncp ${bamboo.build.artifact.path}/app-binary/*.jar /opt/app/current.jar\nsystemctl restart my-application

3. Verification

Push a commit to your VCS. Verify that:

The Build Plan triggers via webhook.
The artifact is stored.
The Deployment Project notifies you that a new version is available for the Production environment.

Trade-offs and Limitations

This decoupled architecture introduces a few operational overheads:

Storage Pressure: Storing every build artifact can quickly saturate disk space. You must configure Artifact Cleanup Policies to delete old versions (e.g., keep only the last 10 successful builds).
Network Latency: Large artifacts must be transferred from the Bamboo server to the remote deployment agent. If your artifacts are several gigabytes, this can create a bottleneck. In such cases, consider using the build plan to push the artifact to an external repository (like Artifactory or Nexus) and having the Deployment Project pull from there.
Polling Load: If you use polling triggers instead of webhooks for your Build Plans, your VCS server may experience high CPU load as Bamboo constantly checks for changes. Always prefer webhooks where possible.

Closing Action

To optimize your current pipeline, audit your build scripts. If you see ssh or scp commands inside a Build Plan, you are likely bypassing the Deployment Project. Move those tasks into a dedicated Deployment Project and define an explicit Artifact to ensure your releases are immutable and traceable.

Decoupling Builds from Releases: Mastering Bamboo Artifacts and Deployment Projects