Using Approval Branching for Business RequirementsFebruary 25, 2013
When the business changes rapidly, this is a problem for a development team that has in its current release trunk both approved and unapproved features. In this blog post, Jack Low presents a solution to minimise the issues created by unapproved features in the codebase at the time of a release and contrasts this approach with popular alternatives like Feature Branching and Feature Toggling.
The previous approaches were to revert commits for unapproved features to remove them from trunk orto revert trunk to the state of the last release was done and then merge approved features in the codebase one at a time. The solution is that once a feature has been completed, tested, and approved for release, it is then merged from trunk into a separate approved branch that contains the current production code plus the new features that have been approved. The advantage of this solution is that developers do not need to worry about a piece of unapproved or unfinished code sneaking into production. This solution does not make the development workflow much more cumbersome at all. Another benefit is that the UAT environment is not frozen during the time of a release. On the negative side, this approach introduces an additional execution environment for the approved branch that requires extra maintenance and testing.
His conclusion is that “Feature Branching is unfit for our purposes, and Feature Toggling is complicated and relies too much on developers doing perfect things in a perfect world. Approval Branching eliminates many of these concerns, while preserving the current workflow of the development team. Approval Branching is powerful because it acts as an extension, rather than a transformation, of an existing process.”
Read the complete blog post on http://blog.shinetech.com/2013/01/30/supporting-fast-moving-business-requirements-using-approval-branching/