The recent generation of version control systems, like Git and Mercurial, have elevated merging to a new level. Systems like Subversion taught us that merging was powerful enough to make “Optimistic Locking a Good Thing”. Now, merging has become powerful enough to make “Feature Branches a Good Thing”.
A feature branch allows a developer to parallelize the mainline of development, and make a coherent set of changes, while continuously merging with the mainline of development.
On at least a daily basis, the developer can pull in changes from the mainline, to assure that the feature branch does not diverge wildly from the original branch (“origin”). Then, when the feature branch meets the definition of done, it can be merged back into the mainline as a single entity.
Advantages of feature branches
- Code, test, document, review. Each coherent set of changes should be not only coded but peer-tested, documented, and peer-reviewed before the set is commingled with the mainline. When the change set is presented on its own feature branch, we make the set much simpler for other team members to test, document, and code review.
- Stability. When code is fully vetted before being released into the mainline, we can trust that the mainline is always stable and ready to release. Otherwise, we have to trust the individual discipline of each and every developer to not introduce defects into the mainline during the heat of alpha development.
- Portion Control. Feature branches encourage developers to work on a small coherent sets of change that belong together on a branch, and that can be presented together for testing, documentation, and code review.
- Innovation. Feature branches give developers the freedom to experiment with untried approaches, and present the innovations for testing and peer review, without putting the trunk at risk.
Working against the trunk and other alternatives
There are folks who recommend that we avoid feature branches and instead work against the trunk, while
- hiding new features,
- employing a component architecture, and
- abstract modules behind a pluggable interface so that a parallel implementation that can be swapped in when complete.
Opponents of optimistic branching tend to overlook that
- DVS merges are designed to be bidirectional. As development progresses, we can merge the trunk into open feature branches to avoid divergence. If developers can be trusted to commit regularly to the trunk, likewise we can trust developers to regularly merge the trunk into the feature branch.
- Every developer’s working copy is a personal feature branch. We encounter all the same difficulties when merging multiple local copies with a shared trunk as we do when we merge feature branches into the shared trunk.
- Best practice teams implement features incrementally. On agile teams, one or two week sprints are the accepted practice. Often, features are decomposed into multiple tasks, each of which can be coded and tested in a day or two. In this case, developers should create a separate branch for each task, which is then merged back into the mainline within a day or two.
- Epic branches are eligible for continuous integration. Sometimes, the full set of features for a top-level story cannot be completed in a single sprint. In this case, a separate integration branch can be created to collect the one-point tasks, until the story meets the definition of done. In this case, the continuous integration server can merge the tip into the epic branch, and apply all the usual regression tests, along with any new tests as they are introduced into the epic. The epic developers can just stay current with the epic integration branch, which is automatically kept current with the trunk.
Having it all with feature branches
Happily, all of the excellent techniques suggested as feature branch alternatives work even better when used with feature branches. The best idea is to reap all the benefits of feature branches, while, at the same time, hide new features, employ a component architecture, and abstract features behind a pluggable interface. For example, even with feature branches in play, it is a great idea make new features “opt-in” whenever you can, so that each customer can choose when to make it available to its own organization.
At NimbleUser, feature branches have helped us increase quality and velocity while eliminating SNAFUs. Today, I doubt that any of us would want to develop a large product any other way.
For more about Enterprise Development on Force.com, visit DreamOps.org.
- Feature Branch (Martin Fowler)
- Motley says: “Branches are for trees, not source code” (James Waletzky )
- How to Setup Continuous Integration with Git, Jenkins, and Force.com (Hansen and Husted)