Setting up a Bamboo server to test task branches (a.k.a. feature branches)

Setting up a Bamboo server to test task branches (a.k.a. feature branches)

Thursday, February 23, 2012 Luix Bamboo , integrations 0 Comments

Plastic SCM integrates with Atlassian's Bamboo for Continuous Integration. We implemented the Bamboo's plugin long time ago (3.0 supported it, about one year and a half if I recall correctly).

We use "branch per task" internally (more info about the task driven development here) which can blend perfectly with a slightly modified CI process (which in fact is considered by many as "the future of Continuous Integration").

As Codice's build master, I decided to adapt the Bamboo plugin for internal use, making it ready for "branch per task". My plan (combined with product strategy) is to start with Bamboo and then loop internally through Zutubi's Pulse, TeamCity from JetBrains and later Jenkins (aka Hudson).

How CI servers work

The way in which a CI server works is:

It monitors the "main" branch (or master or trunk depending on your SCM jargon)

It launches a new build each time it detects a new changeset on the "main" branch All CI systems are normally designed to monitor a single branch, so when you try to use them with "branch per task"... well, you need some changes. Long ago we wrote a blog post about how to set it up with Cruise Control but now is time to get it to the new systems :)

What a branch-ready CI needs to do

Basically it needs to switch branches before each build, to get ready to compile the latest "finished" branch. The dynamics are quite similar but the "branch switching" is required.

And that's basically what we added to the Bamboo plugin.

Detect a branch ready to be tested

Switch to the branch

Build the code

Pass all tests (in our case about 3 hours of automated testing per task: unit tests, GUI tests, command line based tests)

Mark the branch as "tested" if everything goes fine or "failed" if something fails (from build to testing)

Benefits of branch per task

Each branch in "branch per task" resolves a unique issue (task). Then what I do is integrate these branches in a separate branch and when all the tests have passed we merge up to our main branch.

This pattern is very flexible and allows us to separate the work of every task and integrate each task in several branches, deciding what to integrate and what to discard at every moment.

As an integrator I really love this advantage.

How to set up the Bamboo plugin to work in "branch per task"

The only thing you have to do is go to 'Configure plan', then click on the 'Source repository' tab and fill the selector field with something like this:

  repository "codice"
    path "/"
      smartbranch "BRANCH_NAME"

Find how it looks like here:

The BRANCH_NAME keyword will be replaced by the specific branch to test.

How Bamboo knows about the branches to be built

Now, we need to tell Bamboo which branches to test:

To do this, we create an attribute in Plastic SCM called 'status'.

Bamboo will test the branches that have the status attribute set to 'RESOLVED'. (this is basically what we've modified on the plugin)

Using scripting and the Bamboo CLI API you can check whether a build finished ok or not and changed the attribute properly.

Internally we use the following statuses:

RESOLVED: The branch is ready to be tested.

PASSED: The branch passed all the tests and it's ready to be integrated.

FAILED: The changes done in the branch broke some tests and cannot be integrated.

TESTING: The branch is being tested right now.

The build master will only integrate PASSED branches and every developer will fix their FAILED branches and set the attribute again as RESOLVED so that the system test the branch again.

This way we get all our branches tested and the release cycle is much easier and much faster; also the developers don't have to run tests (well unit tests are run very fast so there's no excuse to run them) but the important thing is that with very little effort they get results very quickly.