Anatomy of a Bamboo Build
Any build-bot can run your builds and chain a few steps together. But what if you want to run some steps in parallel, and other steps one at a time? Or aggregate test results from multiple jobs? Or pass build artifacts around? Nobody has excess time on their hands, so Bamboo assumes that you want to do all of those things, and is designed to make them easy to configure and manage.
The basic unit in Bamboo is called a Plan.
- Plans are comprised of one or more Stages, which run in sequence
- Stages are comprised of one or more Jobs, which run in parallel
- Jobs are comprised of one of more Tasks, which run in sequence
Seems like a lot of moving pieces, but don't worry: you'll catch on. (And hey - if build engineering were easy, we wouldn't need smarty-pants specialists like you, would we?)
Tasks
Tasks are the basic building blocks of build automation with Bamboo. Tasks can
- check out source code (from multiple repos, if that's your thing)
- run scripts and in-line commands
- invoke your build engine, such as MSBuild, Ant, Maven... you get the idea
- analyize your code and generate reports
- deploy your code using a home-grown script or a variety of open source and 3rd-party tools
Bamboo ships with dozens of all-purpose tasks, and dozens more are available free on the Atlassian Marketplace.
Tasks run in sequence inside their Job. By grouping mutliple tasks into a single Job, you ensure that Bamboo will execute them in the order you specify. Conversely, tasks that are idependent of each other can be put into separate Jobs so they are run in parallel (thus speeding up your build time).
And speaking of Jobs...
Jobs
Jobs contain a list of Tasks which are executed on build agents. These agents may be on the same machine as the Bamboo server (Local Agents), on a different machine on your network (Remote Agents), or on the Amazon Elastic Compute cloud (Elastic Agents).
Jobs within a given Stage will run in parallel as long as there are agents available to execute them. Otherwise, Jobs run one at a time in no particular order. What's more, Bamboo won't start executing Jobs in the next Stage until all Jobs in the current Stage have completed successfully. That little detail has big implications for Continuous Delivery. It means you can have 10 parallelized testing Jobs in one Stage, and know that if any of them finds a bug, the deploy Job in your downstream Stage won't run. Preventing accidental deploys of broken builds is that easy with Bamboo!
And speaking of Stages...
Stages
Stages allow you to control the flow of Job execution. They provide a way to encapsulate independent Jobs that can run in parallel, and by the same token, a way to ensure that Jobs with dependencies run alone and in the order you specify.
Stages are great because they make it easier to break down your build automation into multiple steps such as compilation, testing, and deployment. For example, Jobs can be used to split up a suite of tests into smaller batches, where each Job executes a separate batch in parallel. When executing integration tests, this can easily save hours. The Jobs in the next stage will not begin to execute until all the jobs in the previous stage successfully complete. This can be used to ensure that expensive integration tests only run after fast-running unit tests pass, for example.
Any Stage can be designated as "manual" (which really just means "push-button"). This means you can configure a single build pipeline that goes all the way from code repo to production, without actually deploying to production with every build. Simply set that Stage as manual. Bamboo will build all of the preceeding Stages with every commit, then halt the build at the manual Stage and send out the appropriate notifications. When you are ready to send a build to production, go to the target build in Bamboo, and click the "play" button to proceed with the remainder of your Plan.
And speaking of Plans...
Plan
A Plan defines everything about your build process. It is a container for all the Stages, their Jobs and Tasks --and much more.
When creating a Plan, you'll give it a unique key, indicate which repository (or repositories) to pull code from, and choose its trigger --build with each commit, at scheduled intervals, etc. There are also a handful of administrative options that can be set to global default values and tweaked at the Plan level. These include permissions, notifications, log & artifact purging, hung build criteria, and variables.
Newer versions of Bamboo (v4 and up) include a feature called Plan Branches. Instead of creating cloned Plans for each of your active branches, you can tell Bamboo the branch's location and Bamboo takes care of the rest. Any config changes made to the original Plan will automatically propogate out to the Plan branches (sayonara, administrative overhead!). For teams using Git and Mercurial, Bamboo will listen for new branches in your repo and create the Plan branches without you having to lift a finger. This automated branch detection has been so popular with DVCS teams that it will soon be available for SVN users, too!
