Migrating from Bamboo

Migrating continuous integration tools can be hard, so we've put together a guide to help you transition your Bamboo skills to Buildkite. This guide is applicable to both Bamboo Sever and Bamboo Cloud.

Plans to Pipelines

Most Bamboo workflows can be easily mapped to Buildkite. Projects and Plans in Bamboo are known simply as Pipelines in Buildkite. Bamboo Deployments also simply become Buildkite Pipelines.

Buildkite Pipelines consist of Steps. There are 4 different types of Pipeline Steps: command, trigger, wait and block.

The first two types, command and trigger, run in parallel. The second two types, wait and block will cause the Pipeline to pause and wait for all previous steps to complete—this way your Pipeline becomes a set of stages.

For example, a simple test and deploy Pipeline might consist of the following steps:

steps:
  # First stage
  - command: test_1.sh
  - command: test_2.sh

  - wait

  # Second stage
  - command: deploy.sh

The block step will also wait for previous steps to complete but instead of automatically continuing, it will stop the build and require a user to manually "Unblock" the Pipeline by clicking the "Continue" button in the web interface, or use the Unblock Job REST API endpoint. These are the equivalent of a Manual Stage in Bamboo.

steps:
  - command: test_1.sh
  - command: test_2.sh
  - block: 'Deploy to Production'
  - command: deploy.sh

Let’s look at an example Bamboo Plan:

Screenshot of a Bamboo Plan

We can map this to a Buildkite Pipeline using a combination of command, wait and block steps:

Screenshot of a Buildkite Pipeline

Creating and managing your Pipelines can be done in a variety of ways, the easiest being the Buildkite web interface. If you have many Pipelines to migrate or manage at once, you can use the Update Pipeline REST API.

Once you’ve become familiar with the tooling and concepts you can switch to storing your Pipelines as code. The above Bamboo Plan that we mapped to Buildkite could also be defined using the following pipeline.yml file:

steps:
  # First stage is to run the "make" command - which will compile our
  # application and store the binaries in a `build` folder. We'll upload the
  # contents of that folder as an Artifact to Buildkite.
  - command: "make"
    artifact_paths: "build/*"

  # To prevent the "make test" stage from running before "make" has finished,
  # we seperate the command with a "wait" step.
  - wait

  # Before running `make test` we need to download the artifacts created in the
  # previous step. To do this, we can we the `buildkite-agent artifact
  # download` command.
  - command: |
      mkdir build
      buildkite-agent artifact download "build/*" "build/"
      make test

  # By putting commands next to each other, we can make them run in parallel.
  - command: |
      mkdir build
      buildkite-agent artifact download "build/*" "build/"
      make lint

  - block: "Deploy to production"

  - command: "scripts/deploy.sh"

Once your Build Pipelines are setup, you can update step labels to something a bit more fun than just text 😃 (see our extensive list of supported emojis)

Screenshot of a Buildkite Build

Steps and Tasks

command steps are Buildkite's version of the Command Task in Bamboo - they can run any commands you like on your build server, whether it's rake test or make. Buildkite doesn't have the concept of Tasks in general, it's up to you to write scripts that perform the same tasks that your Bamboo Jobs have.

For example, say you had the following set of Bamboo Tasks:

Screenshot of a Bamboo Task List

This can be rewritten to be a single script and then committed to your repository. The Buildkite Agent takes care of checking out the repository for you before each step, so the script would simply be:

#!/bin/bash

# These commands are run within the context of your repository
echo "--- Running specs"
rake specs

echo "--- Running cucumber tests"
rake cucumber

Read our Writing Build Scripts guide if you'd like to learn more about how to write build scripts and some common best practices.

trigger steps can be used to trigger builds in other Pipelines. You can use these to create dependent Pipelines. See our trigger-pipeline example for more information.

Remote and Elastic Agents

The Buildkite Agent replaces your Bamboo Remote Agents. You can install the Buildkite Agent onto any server to run your builds.

In Bamboo, you can target specific agents for your jobs via their Capabilities, in Buildkite you target them using meta-data.

Similar to Elastic Bamboo, Buildkite can also manage a fleet of Agents for you on AWS using our Buildkite AWS Stack. Buildkite doesn’t limit the number agents you can run at any one time, so by using the Buildkite AWS Stack you can auto-scale your build infrastructure, going from 0 to 1000’s of agents within moments.

Authentication and Permissions

Buildkite supports single sign-on with Okta, OneLogin, Bitium, Active Directory (ADFS), Google Apps and SAML.

For larger teams, it can be useful to control what users have access to which Pipelines. We're currently rolling out Buildkite Teams as a new feature to the platform. Contact us if you'd like to be part of the beta.