Saturday, July 1, 2017

Scaling Atlassian Bamboo Builds & Branches

Designing a build strategy that is both practical and simple when dealing with hundreds of components is not a trivial task. Maintaining your sanity when talking few hundreds builds and many branches can be quite challenging. This is one simple design allowing compilation, testing, high parallelism of jobs and extremely simple to build.


The concept relies on N + 1 builds, N components each of them capable of running compilation and unit testing independently and producing artifacts. The artifacts should be exposed to Bamboo using standard "Shared artifact" functionality.

I feel comfortable using develop as a default branch in Bamboo, this is allowing me to play nice with feature branches, created out of develop branch.

The extra build will be responsible for aggregation, it will download the artifacts from the N builds and produce a "release". Bamboo is respecting the branch names when downloading the artifacts between build plans:

Aggregator master = sum(component 1 ...N master )
Aggregator develop = sum(component 1 ...N develop )
Aggregator featureX = sum(component 1 ...N develop ) - component 3 develop + component 3 featureX**

** For the example diagram above

The aggregation build has all artifacts at its disposal, doing your performance, integration or governance tests at this stage becomes trivial and a green build here can mean much more then only "I managed to find installers for the 5 applications downloaded"

A "feature" release can prove quite useful, especially when we talk about complex features. Of course features should be small, easy to test but sometimes complexity cannot be avoided and it is much nicer to run integration tests or even deploy it fully to some environment.

The setup works very nice also with automatic branch creation and cleanup of Bamboo, no need to create builds or branches on demand, let the system take care of itself.

Using the setup above you can produce easily releases, tie them to deployment projects and deploy to environments specific branches.

This setup works nicely with independent building blocks that can be mixed and matched to create a customer centric solution or tailored products targeting a specific need ! If you are having a platform to maintain you can tie your aggregation master to your production and have the freedom of testing develop & branches in other environments.