Setting up a CI/CD pipeline in Bamboo with the Atlassian stack

Why manual builds break releases: when Bamboo setup is needed

Manual release builds rely on memory and informal agreements. While there is one release every two weeks, an engineer builds the branch, runs tests locally, and copies the artifact to the staging environment.

As soon as releases become more frequent or a second developer joins the team, the step “build it like last time” turns into a lottery: everyone has their own dependency versions, their own variables, and their own command order.

A non-reproducible build is the main source of silent defects.

An artifact from a developer's machine and an artifact from the production environment differ in dependency composition and build parameters, so the bug “only reproduces in prod” is not mysticism but a consequence of different input conditions.

Environment drift adds the other half: test and production configurations are edited manually and diverge within weeks.

A separate risk is releases that depend on one person. Access credentials, deployment scripts, and rollback procedures live in their head and local folder rather than in the repository.

A vacation or move to another project stops the release, and the rollback window for a failed deployment grows from minutes to hours.

Deployment automation becomes mandatory when releases happen more than once a week, there are more than two environments, or an audit requires confirmed authorship of every change.

That is when Bamboo setup is needed together with the rest of the Atlassian ecosystem: builds, checks, and deployment are described declaratively and run the same way on any environment. Let's break down how this is covered.

What a build pipeline delivers: reproducibility, speed, fewer failures

A unified build pipeline removes the main cause of discrepancies — different environments on the developer's machine, the build agent, and the server.

Dependencies are pinned by a manifest file, steps are described as code, agents start in an isolated environment and are destroyed after the run.

The same commit produces the same artifact regardless of who started the build and when — “it works locally for me” stops being an argument.

Build and release time is reduced not by optimization for its own sake but by structure: dependency caching between runs, parallel test stages, separation of fast checks and long regression runs on a schedule.

The artifact is built once and promoted across environments without rebuilding, so the path from commit to finished release is measured in tens of minutes instead of hours.

At the same time, the bottleneck is visible on the stage timeline rather than discovered after the fact in a call.

The share of release rollbacks falls because a whole class of errors goes away — forgotten migrations, configuration mismatches, steps that were done manually and “usually worked.” Downtime due to a build failure stops being a surprise: the pipeline fails on a commit with a clear reason, not in the production environment at night, and rollback to the previous artifact remains available in one step.

Bamboo together with the issue tracker and repository delivers this without scattered homegrown scripts: build rules, permissions, and run history live in one place. Next, we'll look at how the current build process is migrated and what remains of the accumulated script wrappers.

Build execution options: dedicated agents, cloud, containers

The agent operating mode determines where the build runs and how reproducible the result is. In Bamboo, this is described by job requirements and node capabilities: the scheduler assigns a build only to an agent whose set matches. This gives four schemes that teams realistically choose between.

In practice, schemes are mixed: the build runs in an isolated environment, tests are parallelized across on-demand agents, and the release is performed by a dedicated node. This covers both load peaks and access control requirements at once.

Bamboo setup stages: from repository audit to handover

The sequence of work in Bamboo is the same for any repository — the scope changes, not the order. We start with an audit: without it, automation simply transfers into the pipeline the same hidden assumptions that live in manual builds on developers' machines.

1. Audit of repositories and current build scenarios. We look at what is built manually and why, where dependencies and secrets are stored, which branches are actually active, and how long the build takes now.
2. Designing the build pipeline scheme. We break the process into steps: compilation, tests, static analysis, artifact publication, deployment to environments. We define what runs on every commit and what runs only on a version tag.
3. Configuring agents and build plans. We deploy agents for the required platforms and limit parallelism so that a heavy build does not push out other jobs. We move shared steps into templates — a new service is connected by editing variables rather than copying scripts.
4. Validation on a pilot release branch. We run the entire pipeline on one service: measure build time, success rate, and behavior when tests fail. We separately test rollback to the previous artifact.
5. Team training. We show developers where to view logs, how to add a step to a plan, and how to rerun only the failed part instead of the entire build.
6. Documentation handover. Pipeline scheme, description of variables and access, instructions for editing plans, and the procedure for a build failure.

Handover package: plan configurations, environment schemas, procedures

After Bamboo setup, the team is left not with a set of settings in chat and not with one engineer who “knows where to click,” but with a versioned set of artifacts.

Plan configuration is stored next to the code, so a change goes through review like a regular commit, and the environment is reproduced from the description rather than rebuilt manually.

• Build plan configuration — description of plans and links between them in repository files: steps, run conditions, dependencies. Values that differ between environments are moved into variables, and secrets are moved into an external vault rather than the configuration text.
• Matrix of agents and their capacities — which class of jobs runs on shared executors, which runs on dedicated ones, and how labels are assigned. This removes competition between build and deployment: a release does not wait for an agent to free up for heavy tests.
• Environment and release flow scheme — the chain from development environment to production, transition triggers, and manual confirmation points. The built artifact is promoted between environments without rebuilding, so exactly what passed checks goes to production.
• Access separation rules — roles: who can start a build, who can edit plan configuration, who confirms deployment to production. They are aligned with permissions in repositories and the issue tracker so that no bypass path around the process remains.
• Release rollback procedure — which artifact is used for rollback, who makes the decision, and how many minutes it takes for the environment to return to a working state. Rollback of data schema changes is described as a separate scenario because it is not limited to reverting to the previous build.
• Instructions for the on-call engineer — typical failures: agent unavailable, checks failed, deployment stuck waiting. For each one — the procedure, diagnostic method, and escalation point.
• Maintenance procedure — artifact and build history retention, periodic updates of base agent environments, and review of plans when the set of services changes.

Case study: moving from manual releases to a pipeline — before and after metrics

Before

Before the project, the release was built manually: an engineer brought up the environment, ran the build locally, copied artifacts to the environment, and ran migrations with a separate command.

The step order lived in one person's head — during vacation, the release simply did not go out. A release took 3–4 hours in a night window, and the cause of a failure was determined only after users had seen the error.

What changed and what we achieved

We built a pipeline in Atlassian Bamboo: build, tests, artifact publication with a versioned number, deployment across environments — as one sequence of linked jobs. The development branch is checked on every change, and only a build that has passed all checks goes to production.

Rollback was made the same kind of pipeline step: reverting to the previous artifact and rolling back the database schema with one command, without manual edits on servers.

If post-deployment checks do not pass, the pipeline stops the release itself and returns the previous state.

Release build time decreased from 3–4 hours to 20–25 minutes. The number of rollbacks fell from four per ten releases to one per twenty — most defects are caught during checks before reaching production.

Recovery time after a failure decreased from two to three hours to 10–15 minutes: rollback stopped being an emergency operation under pressure.

A separate effect is predictability: the release no longer depends on one person or a night window, and the build log keeps track of who changed what. New steps — security checks, notifications — were added without rewriting the process.

What if some builds are already configured in another tool?

Some projects are already built in another tool — this is a working situation, not a problem. Rewriting everything at once is risky: releases continue as usual, and stopping the build line immediately affects deadlines.

That is why we do not migrate everything at once, but first establish coexistence of the two circuits.

We start with an inventory: what jobs and triggers each project has, where artifacts come from, and who receives build notifications and how.

This picture shows which scenarios can be migrated one-to-one and which require rework — most often differences in environment variables and artifact publication steps.

While one project still lives in the old tool, the second is already built in Bamboo: both write artifacts to the same registry and are triggered by events in the version control system.

We do not break what works — the previous scenario remains, and the new one is placed alongside it and tested on the same branches and the same test suites.

A single release point is assembled gradually: versions, build logs, permissions, and notifications are viewed in one place, even if execution happens in two systems. The customer sees one release list and one status for each service instead of two inconsistent pictures. This also resolves the question of who made a change to the build scenario and when.

Phased pipeline migration follows risk: first non-critical services and nightly builds, then release branches, and finally what is tied to production. Each step is reversible: the previous scenario remains operational until the new one has completed several releases in a row. Bamboo setup in this mode does not require stopping current releases.

Common technical questions: agents, access, build migration

Build isolation starts with agents: each pool has its own set of capabilities — installed tools, access to internal registries, environment variables.

A plan is bound to the required pool through requirements, so someone else's build will not occupy a freed-up agent or see a neighboring team's variables.

Secrets live separately from the plan — in shared project credentials, deployment environment parameters, and an external vault. Values are injected at runtime and masked in logs, and access to them is granted by role.

How is access to environments granted?

Deployment permissions are tied to the environment and role: a developer builds the artifact, but deployment to production is performed by an approved group. Credential rotation does not require editing plans — the value in the vault changes.

What should be done with existing build plans?

We migrate them in two ways: export-import of configuration for a targeted move, or describing the plan as code — then settings live in the repository, go through review, and are reproduced on the new environment. Before migration, we verify links to repositories, triggers, and variables.

Who maintains the pipeline after handover?

We stay on for maintenance: we update agents and add-ons, monitor the job queue and build time, and investigate failures. Metrics — build duration, success rate, and time to recovery after a failure.

Let's discuss the task: we'll review your builds and come back with a plan

To make the assessment based on facts rather than assumptions, we start with a review of the current process.

We look at how build plans are structured in Bamboo, how many agents are involved, how repositories are linked to the issue tracker, and at what point code reaches the target environment.

We separately capture bottlenecks: where the build takes longer than it could, which steps are performed manually, and which releases depend on a specific engineer.

During the review, we clarify what cannot be seen from configurations:

• which branches enter the build and how, where the pipeline currently breaks and why;
• how many automation steps are missing — from checks to deployment;
• which environments exist and how they differ, where manual confirmations are needed;
• how access, roles, and secret storage are organized, who can change what;
• how artifacts are formed, versions are numbered, and rollback is performed;
• what constraints the infrastructure imposes — network, agents, limits of external systems;
• what is already configured and reused, and what will have to be built from scratch.

Based on the review, we come back with a pipeline implementation plan: stages, sequence of work, areas of responsibility, and an estimate of automation effort.

We agree on the plan before starting — you see in advance what will change at each stage and how it will affect current releases. Describe the task and send access to the configurations — we will come back with an estimate and work scheme.