Posted on April 14, 2017
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.
by Doug Klugh
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 BranchingTo 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 ExplainedFeature 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. 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. 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.