Stop Rebuilding for Production: Using Bamboo Deployment Projects for Immutable Artifacts

The Risk of the "Rebuild for Prod" Cycle

A common failure point in CI/CD pipelines is rebuilding code for every environment. When a team compiles for QA, tests it, and then triggers a separate build for Production from the same branch, the binary deployed to production is not the binary that was tested. Even with pinned versions, differences in build agent environments or transient dependency updates can produce "it worked in QA" bugs that only appear in production.

The fix is artifact promotion. In Atlassian Bamboo, this means decoupling the build plan from the deployment project: build once, produce a shared artifact, and promote that exact file through each environment.

Decoupling Build Plans from Deployment Projects

In Bamboo, a build plan handles creation: compiling code, running tests, and packaging the application. Its output is a shared artifact — a versioned file (a .war, .jar, or .zip) stored by Bamboo. A deployment project is a separate entity that consumes those shared artifacts and defines a pipeline of environments, for example QA then Production. Because the deployment project pulls the artifact the build plan produced, the same bytes move through the whole pipeline.

One caveat before you standardize on this: exact UI labels, task types, and variable syntax differ between Bamboo versions, and Atlassian's packaging and support for Bamboo Server versus Data Center has been shifting. Check the documentation for your installed version before committing to the names used here.

Environment-Specific Configuration

To make one artifact work across different servers, define variables at the environment level in the deployment project. Rather than hardcoding database URLs or API endpoints into the build, each environment carries its own values, and Bamboo injects the right ones at deployment time. The artifact stays immutable; only its surroundings change.

Worked Example: Promoting a Java Web App

Consider a Maven project that needs to move from build to a Tomcat server in two environments:

1. Build plan: run mvn clean package on a build agent with Maven and a JDK installed, then define a shared artifact in the plan's artifact settings with a source pattern of target/*.war.
2. Deployment project: create one and link it to that build plan; the shared WAR becomes deployable in each environment you add.
3. QA environment: trigger automatically on successful build completion, with a script or SCP task copying the WAR to the QA Tomcat host.
4. Production environment: require a manual approval before the deployment runs, so a person signs off on QA results first.
5. Release versioning: name releases with release-${bamboo.buildNumber} so every promoted artifact maps back to the build that produced it.

Deployment Configuration Summary

Feature	QA Environment	Production Environment
Trigger	Automatic (on build success)	Manual approval
Artifact source	Build #123 (shared)	Build #123 (shared)
Variable scope	db.url=qa-db.internal	db.url=prod-db.internal

Limitations and Trade-offs

• Storage overhead: keeping shared artifacts for every build, so old releases can be redeployed, grows disk usage on the Bamboo server. Configure artifact cleanup policies to prune old versions.
• Configuration drift: an immutable artifact means any variable change needs a new deployment. Managing dozens of environments by hand in the UI gets tedious.
• Secrets: do not store credentials as plain environment variables. Use Bamboo's encrypted variables where available, or fetch secrets from a vault during the deployment task.
• The model only holds if artifacts are truly shared: if any environment quietly rebuilds from source, the promotion guarantee is gone. Audit deployments to confirm they reference the original build.

Verifying the Promotion

Open the deployment history for the deployment project. Every environment entry for a given release should reference the same build number; if Production lists a different build than QA, something is rebuilding. Run one deployment with release versioning enabled and confirm the release name, containing the build number, appears in the history, and confirm a Production deployment stays paused until an authorized user approves it.

To roll back, pick a previously successful release in the deployment history and redeploy it. Bamboo pushes the older shared artifact to the server again — no return trip to source control or a build agent required.