Decoupling CI from CD: Using Bamboo Deployment Projects for Artifact Promotion

The "Rebuild for Production" Trap

A common failure in CI/CD pipelines is the tendency to rebuild a project for every environment. When a team triggers a separate build for Staging and then another for Production, they introduce a critical risk: the binary deployed to Production is not the exact same binary that passed QA. Even with pinned versions, differences in build agent state or transient dependency updates can lead to "it worked in Staging" bugs that only appear in Production.

The solution is to decouple the creation of the artifact (Continuous Integration) from the orchestration of its release (Continuous Delivery). In Atlassian Bamboo, this is achieved by separating Build Plans from Deployment Projects.

The Architecture of Artifact Promotion

In Bamboo, a Build Plan is responsible for the "how" of the compilation—running tests, linting, and packaging the code into a versioned artifact (such as a .jar, .war, or .zip). Once this artifact is stored in the Bamboo artifact repository, it becomes a read-only snapshot of that specific commit.

A Deployment Project then takes over as the orchestrator. Instead of running a build, it creates a Release. A Release is a pointer to a specific build version. This Release is then "promoted" through a series of Environments (e.g., Dev → QA → Production). Because the Deployment Project pulls the existing artifact from the Build Plan, you are guaranteed that the exact same bytes are moving through your pipeline.

Managing Environment-Specific State

Since the artifact is immutable, environment-specific configurations (like database connection strings or API keys) cannot be baked into the build. Bamboo handles this using scoped variables. Variables can be defined at three levels:

• Project Level: Global settings shared across all plans and environments.
• Plan Level: Settings specific to the build process.
• Environment Level: Settings unique to a specific target (e.g., db.url for Staging vs. db.url for Production).

During the deployment task, Bamboo injects these variables into the target environment, allowing the immutable artifact to adapt to its surroundings without requiring a re-compile.

Worked Example: Promoting a Java Application

Consider a scenario where a Java application is built in a Build Plan and needs to be deployed to a Staging and Production server.

1. Build Plan Configuration

Ensure the Build Plan has an Artifact defined. For example, a task that runs mvn package and defines the artifact path as target/*.war. This creates a versioned file stored on the Bamboo server.

2. Deployment Project Setup

Create a Deployment Project and link it to the Build Plan. Define two environments: Staging and Production.

3. Environment Variable Mapping

In the Staging environment settings, add:

app.env = staging
db.endpoint = staging-db.internal.net

In the Production environment settings, add:

app.env = production
db.endpoint = prod-db.internal.net

4. Execution and Verification

To deploy, run the following sequence from the Bamboo UI (requires Deployment Admin permissions):

1. Create Release: Select the successful build version from the Build Plan.
2. Deploy to Staging: Execute the Staging environment tasks. Verify the app is running by checking the app.env log output.
3. Promote to Production: Once QA signs off, trigger the Production environment using the same Release version.

Trade-offs and Limitations

While this decoupling increases reliability, it introduces specific overheads:

• Storage Pressure: Since every single build produces an artifact that could potentially be promoted, the Bamboo server's disk space can deplete quickly. You must configure Artifact Cleanup Policies to prune old versions.
• Configuration Drift: Managing variables within the Bamboo UI can lead to "drift" where the UI settings differ from what is documented in version control. For highly complex setups, consider using Bamboo variables to point to an external secret manager or a versioned config file.
• UI Complexity: As the number of environments grows, the Deployment Project visualization can become cluttered, making it harder to track which version is currently active in which environment at a glance.

Verification Checklist

To ensure your decoupling is working correctly, perform these checks:

• Confirm that no "Build" tasks (like Maven or Gradle) are running inside the Deployment Project; it should only contain "Deployment" tasks (like SCP, SSH, or AWS S3 upload).
• Verify that the Release Version number remains identical as you move from Staging to Production.
• Check the target server logs to ensure the environment-specific variables were injected correctly and not hardcoded in the artifact.