Migrating from Bamboo
Migrating continuous integration tools can be challenging, so we've put together a guide to help you transition your Bamboo skills to Buildkite. This guide is applicable to both Bamboo Server and Bamboo Cloud.
Most Bamboo workflows can be easily mapped to Buildkite. Projects and Plans in Bamboo are known as pipelines in Buildkite (and Pipelines in Buildkite UI). Bamboo deployments also become Buildkite pipelines.
input steps run in parallel.
block steps cause a build to pause and wait for all previous steps to complete.
group steps group together various steps, and display them as a single logical group. This way, your pipeline becomes a set of stages.
For example, a test and deploy pipeline might consist of the following steps:
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 UI, or use the Unblock Job REST API endpoint. This is the equivalent of a Manual Stage in Bamboo.
Let's look at an example Bamboo Plan:
You can map this plan to a Buildkite Pipeline using a combination of
This Bamboo Plan could also be defined using the following
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.
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:
This can be rewritten as 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 be as follows:
If you'd like to learn more about how to write build scripts, read the Writing Build Scripts guide.
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.
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 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 Buildkite AWS Stack. Buildkite doesn't limit the number of 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 1000s of agents within moments.
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 Buildkite Organization Settings.