The basic idea of Feature Branching is that when you start work on a feature, you create a branch off of the repository and commit all the changes for the feature onto the branch and when your feature is code complete then merge the changes back.
The advantage in using feature branches is that your main line (you might call main line ‘master’, ‘trunk’ or ‘head’ depending on the version control system you use) is kept clear of uncompleted features or bug fixes, which enables you to release software at any time because you don’t have to wait for all the features and bug fixes being worked on to be completed.
Thanks to tools like Git and Mercurial, Feature Branching has passed from the realm of theoretical development practices and firmly into the world of the practical. These tools not only allow branches to be created quickly and easily, but also provide very advanced algorithms that allow merging to happen quickly and in a less error prone manner. This is less practiced in teams where older tools like Subversion are used because the branching and merging process is not as smooth.
When combined with Feature Branches, Continuous Integration has suffered two distinct problems, which I’ve outlined below:
Duplication and drift of build configuration
When a developer creates a branch, multiple build configurations on the Continuous Integration server needed to be cloned manually. Because it’s a manual step, some developers didn’t bother with it (and thus no tests were executed as they developed the feature) and eventually the build configuration started to drift away from the original configuration it was cloned from, causing administration headaches. Worse, if the developer didn’t bother to set up a build to test their branch, no code would be tested.
Uncertainty of integration state
Unless the developer was constantly merging changes from the main line into their branch and running the tests, there was always uncertainty around whether the code worked or not – at least until the branch was merged into the mainline. Often times, the code did not work as expected and the mainline was infected with non-functional code –defeating the point of Feature Branches and Continuous Integration entirely (ie, isolation and assurance that all the changes to the codebase work).
What are Plan Branches?
Plan Branches are a Bamboo Plan configuration that represent a branch in your version control system. They inherit all of the configuration defined by the parent Plan, except that instead of building against the repository’s main line, they build against a specified branch. Then, when the branch build succeeds, changes can be merged from the branch automatically to the main line.
As you can see in the screenshot below, our Angry Nerds project is building not only the master branch (main line) it is also building the new-physics, more-angry-nerd-chars and feature-highres-graphics branches. Bamboo makes it easy to see which Plans also have branches by displaying the branch symbol .
To set this up, go to the configuration screen for the Plan you wish to configure Plan Branches, and click the Branches tab. (Make sure to log in as a user with admin privileges for that Plan!)
From here we can configure Bamboo to automatically detect new branches in the repository, and create the corresponding Plan Branch. Note that automatic branch detection is currently available for Git and Mercurial repositories only but don’t feel left out if you use another version control system like Subversion or Perforce, as you can manually create a Plan Branch too.
It’s likely that you don’t want to build every branch you create. If you use a naming convention where all branches that you want tested start with, for example, “feature-*” then Bamboo can be configured to only create Plan Branches that match that prefix. (Hint: you can use a regular expression too)
Since most feature branches are short-lived (3-4 days at most), you can configure the Plan to remove the branch and it’s build results from Bamboo after a certain number of days of inactivity. This can be disabled on a per branch basis if you want to keep it around for an indefinite amount of time, after which you will have to remove it manually. Don’t worry: we won’t remove the branch from your repository – we leave that task up to you.
Disabling automatic cleanup outright for some branches is a good idea for situations where you might maintain a long lived “stable” branch of your project.
Building every branch the easy way
It’s possible to create a Plan Branch for any version control system supported by Bamboo. To create a branch, go to Plan > Configuration > Branches, and click the Create Branch button. For Git and Mercurial, a dialog will appear listing all the available Branches in the repository which do not yet have a corresponding Plan Branch in Bamboo. Pick a branch and hit Create. Users of traditional VCS repositories will be asked to simply choose a name, description and what branch they want to use (for Subversion this is the URL to the branch) before hitting Create.
You can now disable the automatic cleanup for the current Plan Branch if you wish, and in the case of DVCS repos, configure a Merge Strategy. Merge Strategies allow Bamboo to automatically merge code between branches on successful builds (more on that later). It is also possible at this point to override repository information (if you are using Plan Branches with Subversion, you can change the SVN URL from trunk to branch here) or override build variables. For example, you might have a variable that specifies whether you are going to deploy to production that you may want to change for the Plan Branch.
Triggering a build of your Plan Branch will happen just like it normally does for the parent Plan, except against the selected branch instead of the main line.
Since the build steps for parent Plan builds and Plan Branch builds work exactly the same, features like Manual Stages also work normally too. If you have notifications configured, Bamboo will notify you automatically if the build has passed or failed so you are aware of the state of your branch at all times.
Automatically Merging Branches
Since you don’t really know if everything works until you’ve merged changes to or from the main line, Bamboo provides a two models to do that automatically in DVCS repositories –we call them “Branch Updater” and “Gatekeeper”. When activated, before the build runs, Bamboo will either merge changes from trunk into the branch (Branch Updater) or checkout the main branch and merge changes in from the current branch (Gatekeeper). Bamboo then proceeds to run the build.
If the build is successful (and you’ve checked the Push on Success checkbox) the changes are automatically pushed to the branch that was checked out. If you are using the Gatekeeper model, this means changes on branch are pushed to the main line, or if using the Branch Updater mode, the feature branch is kept up to date with changes happening on main. Now that’s Continuous Integration!
So what are you waiting for?
Current customers can simply update their instance to version 4 and get building. New customers can enjoy a 30-day free trial. Start testing more, and configuring less by downloading Bamboo 4 today!