Sunday, December 18, 2011

Feature Branches: Making it Easy

In my previous post I wrote about the benefits of using feature branches for quality assurance. As with all tools features branches don’t come with benefits only. There are unwanted side effects. Fortunately there are ways to minimize or eliminate them.

One such area is creation of the branches. There are various factors to look at. For one your version control system (VCS) should make it easy to create branches. For some systems this is a no-brainer and for other VCS’s some more work may be required. Most of the teams I work with use Subversion or GIT, and branching is not an issue.

When creating a feature branch, the VCS is only one of the tools that is affected. You also need to consider the client side of the equation. For example, how easy is it to switch between branches? How often do you need to switch between branches? What does the support in the VCS client look like? Do you need integration of your VCS client into the integrated development environment (IDE) your team is using? By choosing an appropriate VCS introducing feature branches becomes much easier.

Apart from the VCS other systems your development team is using may be affected as well when branches are created, whether they are feature branches or others. For example you may be using a continuous integration (CI) system such as TeamCity, Jenkins or CruiseControl.NET. Once the new branch has been created you want to make sure it is picked up by the CI system as well and automatically built. Therefore each time you create a branch you typically want to set up a new branch as well.

You may have other systems that may need to reflect that a new branch has been created. For example a bug tracking system may offer the branch name as the affected version when entering a bug. Or you may use a tool to plan and track progress for a particular feature. Again this would then be set up accordingly when a new branch is created.

As these activities will have to be done each time a feature branch is created, it is an obvious candidate for automation in particular if your team works on dozens or hundreds of features each year. With appropriate APIs of affected systems automation is not an overly complex task. Instead it is just a matter of putting the time in.

In closing I’d like to give you a specific example from one of the teams I am working with. Creating feature branches is completely automated in this case and the time required is only as long as it takes to type in the name of the features branch. The remainder is automated. This includes the creation of the feature branch in the VCS, setting up the new build configuration in the CI, creating the feature as a project in the project tracking system, adding a configuration to the test bed controller and setting up automated merging. Taken together it typically takes about 10 seconds and is saving hundreds of hours of development time per year.

In one of the next posts I’ll describe techniques that help making the merge of feature branches into the main development branch easier.

Monday, December 05, 2011

Feature Branches and Quality Assurance

An almost “classic” way of managing branches is to have a main branch into which all development work is committed. When a release is prepared a release branch is created. Quality assurance (QA), including testing and bug fixing, is done on that release branch. Any code changes are usually propagated to the main branch.

When introducing feature branches the question is whether you would still do all the quality assurance work on that release branch. You can, but in my experience there are better options available to you.

With the “classic” setup you also often see teams putting a lot of quality assurance work into the release branch. This tends to increase significantly the time from when you create the branch to when you release the software. This can lead to spikes in the QA workload. For example if you have planned 4 weeks for release management (QA plus other items required for release) and you are on a quarterly release cycle, every 3rd month typically has a higher workload for the team taking care of the release.

Therefore it might make sense to look for better ways to level the release management work. Feature branches give you additional options.

Since content wise a feature branch is your main development branch plus only one feature, some quality assurance efforts can take place in the feature branch and focus on that particular feature without having to worry about changes that may be in progress in other branches. Also, all QA efforts can start as soon as the first story has been completed on the feature branch. In this case “QA efforts” doesn’t mean that quality is tested into the product. Instead it means that certain tests, e.g. platform, installation and upgrade tests can be run very early in the project. Equally you can start with usability and performance testing very early, too. Quality assurance may also include feedback sessions with customers. By using prototype version from the feature branch, those sessions gain focus as well.

The general idea is to move in as many work items as possible from the release management process and to move as many items from the release branch to the feature branches. With this approach the time between creating a release branch and shipping the software can be shortened extremely, more in the range of hours or days. Since more options exists for quality assurance work, this also reduces or avoids altogether spikes in the QA workload of the development team.

There is one other item that requires consideration. Even despite all efforts in the feature branch you cannot guarantee that the system is not broken when the branch is merged back into the main development branch. You will want to have some integration tests in place to speed up that verification process.

In summary you are distributing the release management work across three places. Firstly you put as many of these items into the feature branches as you can. Second, you need integration testing for when the feature branches are merged. And you keep only the unavoidable release management task in the release branch that you cannot reasonably do in the release management branch.

In a future post I will discuss another technique for what you can do to reduce the effort and risk for merging a feature branch back into the main development branch.

Hostgator promo code