JetBrains TeamCity Blog

With the rise of Distributed Version Control Systems (DVCS) like Git and Mercurial, the concept of Feature Branching gained a lot of momentum. The basic idea is that whenever you start working on a feature, you take a branch of the repository and commit all changes for the feature onto that branch. Once the feature is ready changes are merged back into the repository.

Working with feature branches comes with great advantages for your team. Each developer can work on their own feature and be isolated from changes going on elsewhere in the project. They can pull in changes from the main repository at their own pace, ensuring they don’t break the flow of building their feature.

But how does this work in a Continuous Integration environment? If your CI server does not support this workflow a number of problems arise, like constant build configurations duplication, poor visibility and in the end loss of control of the process.

With TeamCity 7.1 we’ve introduced dedicated support for feature branches and the workflow around it. All you have to do is to push your branch to a Git or Mercurial repository and TeamCity would detect a new branch in it and start a build on your changes. Without having to duplicate build configurations and so on. Let’s see how we can work with it…

Enabling Feature Branches in TeamCity

Our repository may have a lot of branches and naturally not all of them are feature branches. In TeamCity we can tell the server which branches to watch for changes using branch specification. Under the VCS Root settings for our project, we have to specify a Branch Specification.

Branch specifications have a simple syntax:

+:<branch rule>
-:<branch rule>

The branch specification tells TeamCity to include (+) or exclude (-) a given branch as a feature branch. Here are some examples:

+:* treats every branch as a feature branch
+:refs/heads/feature-* treats all branches with a name starting with feature- as feature branches

Once saved, TeamCity will monitor our repository for changes on the mainline of our repository as well as on branches matching the branch specification rules.

Feature Branch Builds

Once a change is detected in a branch, TeamCity will start a build in this branch. For example, after pushing a set of changes to the feature-wp7 branch in our repository, TeamCity automatically builds this branch for us and displays this new branch and its build status on the projects overview as well as on the build configuration’s branches tab:

Notice TeamCity displays a label wp7 instead of the full feature-wp7 branch name. The reason for that is it checks the branch specification and uses only the part of the branch name marked with *. The label for our branch specification +:refs/heads/feature-* hence yields only the last part of the branch name. There are a some other options available for branch labels on a build if you would like to customize this.

Filtering Branch Builds

If you have a large team or a large number of active feature branches, you may want to filter the branches being displayed on various screens in TeamCity. For example, on the projects overview we can filter based on the branches we’re interested in:

Run custom build

Based on our branch specification, TeamCity allows us to run custom builds for a specific branch. On the Changes tab, we can select the branch to build.

Happy building!

This entry was posted on Friday, March 1st, 2013 at 1:12 am and is filed under Features, Tips&Tricks. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.