Decoupling CI from CD: Using Bamboo Deployment Projects for Immutable Releases

The 'Build Once, Deploy Many' Dilemma

A common failure in CI/CD pipelines is the tendency to rebuild code for every environment. When you trigger a separate build for Staging and then again for Production, you aren't actually deploying the code you tested in Staging; you are deploying a new binary that happens to be from the same commit. This introduces risk through compiler variations, dependency updates, or transient build environment changes.

The solution is to decouple the Build Plan (Continuous Integration) from the Deployment Project (Continuous Delivery). In Atlassian Bamboo, this separation ensures that a single, immutable artifact is promoted through a series of environments without being modified or rebuilt.

The Architecture of Deployment Projects

In Bamboo, a Build Plan is responsible for the "how" of creation—compiling code, running unit tests, and producing an artifact (such as a .jar, .war, or Docker image). Once that artifact is stored, the Deployment Project takes over to handle the "where" and "when" of delivery.

Environments as Logical Containers

A Deployment Project is organized into Environments (e.g., Dev, QA, Staging, Production). Each environment acts as a container for specific release steps. This allows you to define environment-specific variables—such as database connection strings or API keys—without baking those values into the artifact itself.

The Release Mechanism

When a build completes, Bamboo creates a Release. This is a versioned snapshot of the artifact. Instead of pointing a deployment to a branch or a commit hash, you point it to a specific Release number. This ensures that the exact same binary that passed QA is the one that reaches Production.

Worked Example: Promoting a Versioned Artifact

Consider a scenario where you need to move a Java application from a Staging environment to Production only after a manual sign-off.

1. Link the Build Plan

Create a Deployment Project and link it to your existing Build Plan. Bamboo will now track the artifacts produced by that plan. Ensure your Build Plan is configured to produce a versioned artifact (e.g., app-v1.2.3.jar).

2. Configure the Staging Environment

Set the Staging environment to trigger Automatically upon the successful completion of the Build Plan. Use a script task to deploy the artifact to your staging server:

# Run on Bamboo Remote Agent with SSH permissions to Staging Server
scp ${bamboo.deploy.artifact} user@staging-server:/opt/app/deploy/
ssh user@staging-server "systemctl restart app-service"

3. Configure the Production Environment

Set the Production environment trigger to Manual. This creates a "deployment gate." A release manager must manually click "Deploy" in the Bamboo UI after verifying the Staging environment.

# Run on Bamboo Remote Agent with SSH permissions to Production Server
scp ${bamboo.deploy.artifact} user@prod-server:/opt/app/deploy/
ssh user@prod-server "systemctl restart app-service"

Verification Check

To verify the integrity of the process, check the Release Number in the Deployment Project UI. If the Staging deployment used Release 42, the Production deployment must also use Release 42. If the version number changes, you have accidentally triggered a new build rather than promoting an existing artifact.

Trade-offs and Operational Limits

While decoupling provides stability, it introduces specific overheads:

• Storage Pressure: Because Bamboo stores versioned snapshots of artifacts for every release, large binaries (like heavy VM images) can quickly consume disk space on the Bamboo server or remote agents. Implement an artifact cleanup policy to prune old releases.
• Secret Leakage: Using environment variables is powerful, but if variables are not scoped correctly, there is a risk of accidentally using a Production secret in a Dev environment. Always use a naming convention (e.g., prod.db.password vs dev.db.password) and verify permissions.
• Deployment Storms: If you set every environment to "Automatic," a single commit can trigger a cascade of deployments across your entire infrastructure. This can overwhelm your servers if build stability is low.

Actionable Summary

To move toward immutable releases in Bamboo, stop using Build Plans to push code to servers. Instead, use Build Plans to create artifacts and Deployment Projects to move those artifacts across environments. Start by converting your Production environment to a Manual trigger to introduce a necessary layer of human verification before the final rollout.