Setting up a Bamboo server to test task branches (a.k.a. feature branches)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 workThe way in which a CI server works is:
What a branch-ready CI needs to doBasically 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.
Benefits of branch per taskEach 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"
The BRANCH_NAME keyword will be replaced by the specific branch to test.
How Bamboo knows about the branches to be builtNow, we need to tell Bamboo which branches to test:
Using scripting and the Bamboo CLI API you can check whether a build finished ok or not and changed the attribute properly.
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.