Branching for Team Agility

Posted on April 14, 2017
by Doug Klugh

High performing Agile teams are always expected to deliver multiple features within an iteration.  To do this effectively, you must have a configuration management process and branching strategy that support concurrent feature development.  Being able to develop features in isolation will enhance your team’s ability to deliver value to your customers quickly while helping to improve quality control.

This is especially useful when delivering within a Kanban process.  Feature branching will enable the team to deploy the features it chooses to release at any time.  If one or more features are not quite ready for prime-time when you want to deliver a release to your customers, it will be as easy as deploying the latest build from your Continuous Integration (CI) branch; which of course, has already been fully integrated and tested.  No more waiting until all of the features earmarked for a release are fully baked.  You may not be delivering everything the customer wanted, but if you deliver the high-value features quickly and often, they will be happy more times than not.

The Value of Feature Branching

To realize the value of Agile, you must be able to deliver value frequently, with a high degree of confidence in the quality of your product.  Feature branching facilitates agility, supports quality assurance and quality control, and provides flexibility that is needed to keep your customers happy.  This is achieved by enabling each developer to work on a feature that is isolated from changes occurring elsewhere.  Team members can work on features concurrently, at their own pace, without impacting the development or delivery of other features.  And this works especially well in a CI environment.  The CI branch acts as a communication point.  Even if team members do not coordinate feature development, any conflicts between features will be discovered within a day of them forming; making it easy to resolve conflicts and mitigate associated risks. 

Feature Branching Explained

Feature branching is achieved by creating a branch off of your main development branch, or CI branch if you're doing continuous integration.  In a Distributed Version Control System such as Git, you’ll do this in your personal repository; but this is also easily achieved in a centralized Version Control System such as Perforce (P4), Subversion (SVN), or Team Foundation Server (TFS).

A feature branch is used to isolate development for one specific feature (or user story).  If your team is effective at keeping features (user stories) small, this branch will be short lived.  Once the feature is completed and merged back into the development (CI) branch, that feature branch should be deleted.

Functional testing should be completed within the feature branch, then automated integration and regression testing should be performed (automatically) upon merging the code back into the CI branch.  Quality gates should also be used to ensure the health of your builds (see Building Success with CI).

Figure 1 below depicts a Trunk used for all production builds.  While some people refer to this as the Master branch, I prefer to use the analogy of a tree, where production code resides on the trunk and all other branches split off of the trunk.  Also depicted below is a Dev branch used as the CI branch.  This example shows three features in development at different times, with Feature 2 being developed concurrently with Feature 1.  Once each feature is merged back into the Dev branch, those branches are no longer needed and should be removed from the source control repository. Figure 2 shows an effective method for managing production patches by simply creating a Patch branch off of the Trunk, applying a defect fix there, then merging back onto the Trunk.  A merge down to the Dev branch should also be performed at the same time to ensure those changes are propagated for all feature development.  Individual features may also pull those changes into their respective branches (as depicted with Feature 1) to make sure they have the latest changes and make merging back into the Dev branch a little easier.  But even if they don't pull in the changes (as depicted with Feature 3), those changes will be included when they merge back into the Dev branch. When you decide to deploy a new release, simply create a Release Candidate (RC) branch off of the Dev branch, perform all final release activities (such as updating release notes), then merge onto the Trunk and back down to the Dev branch.  Each merge should automatically perform final integration and regression testing.  Once that is done, you can easily deploy from the Trunk. Figure 4 makes note that every merge onto the Dev branch or the Trunk should automatically create a build and kick off a suite of automated integration and regression tests.  Quality gates should also be used to roll back all changes if any of the builds or tests fail for any reason.  This is a very effective way to maintain confidence in your code and quality in your product.

Conclusion

Bringing individuals together as a software development team requires a great deal of planning and coordination.  This is often hampered by having to lead team members with various skill levels, working at different speeds.  While there are times when it benefits the team to pair up team members, there are also times when you need to decouple them.  Pair programming is a great way to address quality issues, but enabling team members to work independently on separate features (without stepping on each other’s toes) is a very effective way to increase team velocity.  Utilizing a feature branching strategy helps to decouple features and provide a great deal of flexibility in delivering value to your customers.  Combined with continuous integration, this strategy will all but ensure high quality and fast time to market.