Migrate from Bamboo

Plans to pipelines

You can easily map most Bamboo workflows to Buildkite. Projects and Plans in Bamboo are called pipelines in Buildkite (and Pipelines in the Buildkite dashboard). Bamboo deployments also become Buildkite pipelines.

Buildkite pipelines consist of different types of steps for different tasks:

• Command step: Runs one or more shell commands on one or more agents.
• Wait step: Pauses a build until all previous jobs have completed.
• Block step: Pauses a build until unblocked.
• Input step: Collects information from a user.
• Trigger step: Creates a build on another pipeline.
• Group step: Displays a group of sub-steps as one parent step, like stages.

For example, a 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

Instead of the wait step above, you could use a block step to stop the build and require a user to manually unblock the pipeline by clicking the Continue button in the Buildkite dashboard, or use the Unblock Job REST API endpoint. This is 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:

You can map this plan to a Buildkite pipeline using a combination of command, wait, and block steps:

You could also define this Bamboo Plan using the following pipeline.yml file:

steps:
  # The first stage is to run the "make" command - which will compile
  # the application and store the binaries in a `build` folder. 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,
  # separate the command with a "wait" step.
  - wait

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

  # By putting commands next to each other, you 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 set up, you can update step labels to something more fun than plain text (see our extensive list of supported emojis). 😃

If you have many pipelines to migrate or manage at once, you can use the Update pipeline REST API.

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, you had the following set of Bamboo Tasks:

You can rewrite this as a single script and then commit it to your repository. The Buildkite agent takes care of checking out the repository for you before each step, so the script would be as follows:

#!/bin/bash

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

echo "--- Running cucumber tests"
rake cucumber

If you'd like to learn more about how to write build scripts, see Writing build scripts.

To trigger builds in other pipelines, you can use trigger steps. This way, you can create dependent pipelines. See the trigger steps docs for more information.

Remote and Elastic agents

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

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

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

Authentication and permissions

Buildkite supports SSO with a variety of different providers, as well as custom SAML setups. See the SSO support guide for detailed information.

For larger teams, it can be useful to control what users have access to which pipelines. Organization admins can enable Teams in the organization's team settings.