This is the documentation for Bamboo 5.5. View this page for the

Unknown macro: {spacejump}

of Bamboo, or visit the latest Bamboo documentation.

What are branch deployments?

Branching is an important tool in your development process, as it offers a very powerful way to let developers work in isolation on different aspects of a software project.

Plan branches represent a build for a branch in the version control system. The plan branch inherits all of the configuration defined by the parent plan, and any new branch created is automatically built and tested using the same build configuration as the parent. When the plan branch build succeeds, it can be automatically or manually merged back into master.

Branch deployments extend plan branches by allowing users to create a deployment release from any plan branch.

Learn more about branching strategies: Bamboo Best Practice - Branching & DVCS

Why should we use branch deployments?

Bamboo deployments allow a plan branch to be deployed to a non-critical test environment before the feature code is merged back to master. This means that the feature code can be thoroughly tested and evaluated in a real server environment before the developer merges back the changes to master.

Developers should consider using branch deployments whenever they want to keep their in-progress development code separate from the master code, but want to test it within a deployable environment.

Learn more about deployment releases and how deployment releases work.

The following diagram shows a typical deployment branch example.

  1. The developer creates a new branch off of the master and a plan branch is automatically created for the new branch in Bamboo
  2. The developer commits code against the branch and the plan branch automatically builds the changes
  3. Following a successful build, they then deploy the results of builds #3 and #4 into a test environment for thorough testing
  4. When satisfied that all of the tests have been passed, the developer manually merges their feature branch back into master
  5. Now that the changes are in master – sporting the new feature – a new release can be created and deployed to the mainline environments (e.g. QA, Staging and Production).

Branch deployment use cases

Branch deployments should only ever be triggered into safe testing environments - they should never be triggered into production-like environments such as Staging, QA or Production.

Learn more about Creating and configuring a deployment project.

There are two typical strategies for managing branch deployments:

  1. Manual branch deployment
  2. Automated branch deployment

Let's examine each strategy in more detail.

Manual branch deployment

Let's assume a developer is using a plan branch to work on a new feature for a product. They reach a point in development where the new code needs testing in a server environment.

  1. The developer successfully builds and tests the code using Bamboo. Let's call this Build #1 
  2. When a successful build occurs, it's ready to deploy by creating a new release for Build #1 and deploying it to the testing environment


  3. When deployed, the developer thoroughly tests their new code. When satisfied that all of the tests have been passed, the developer can merge the changes back into master.

Learn more about Manually starting a deployment.

Automated branch deployment

Let's consider another developer who is also using a plan branch to work on a new feature for the product. They decide to automate the branch deployment so that it isn't triggered manually.

  1. The developer successfully builds the code, including the new code they have been working on. Let's call this Build #2 
  2. The developer doesn't want to deploy manually, so uses Bamboo's automated triggering to set up a strategy to deploy the plan branch into a deployment test environment. Two options are available:

    1. use Bamboo's cron based scheduling to deploy at a specified time and date:


    2. use Bamboo to trigger a deployment upon the successful completion of a build plan:


  3. The developer sets up the triggering strategy to best match working practices. Once the trigger is reached, the plan branch build is deployed to the test environment
  4. When deployed, the developer thoroughly tests their new code. When satisfied that all of the tests have been passed, the developer can merge the changes back into master.

Remember: Plan branch code should only be merged back to master AFTER testing of the branch feature code is complete AND successful.

Learn more about Triggers for deployment environments.

  • No labels