New Branching Standards for Configuration Management


In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.

Joe Farah explores a potential standard for next generation branching. It not only has advanced capabilities and processes, but can also significantly reduce CM complexity and increase CM automation.

When it comes to CM plans, each project has to clearly identify its own strategies for branching, and subsequently for labeling and merging.  There are many different practices for branching, and many different philosophies.  Each CM group will vigorously defend its practices and document them in a "branching strategy" document for use by the development team.

In this article we explore a potential standard for next generation branching, one which requires advanced capabilities and processes, but one which can significantly reduce CM complexity and increase CM automation. As well as using it myself, and with a number of clients, I've seen many other companies migrate in the direction of stream-based branching, in part or in whole, with a goal toward clearer, less complex, more automated CM.

Why Branch?
Branching should always arise from one common theme:  the need to support the existing codeline.  From the ground level, this is not always an easy call.  For example, if a build is sent to the verification team, and I'm starting on a new feature, do I have to create a branch so that I can continue to support the code that went ot the verification team?  What if I'm changing an API?  Do I need to create a new branch so that it doesn't affect other existing code?  You may have very definite answers to these questions, but the simple answer to both of them is: It depends.  It depends on whether or not you have to support the previous code line.  Wait a minute. Didn't I circularize my argument?

Let's take an example and say that I change an API.  If it's not yet being used by anyone, there’s not a problem.  If it is being used, but the changes are all upward-compatible and not requiring other code to change, again, there’s not a problem.  If the changes do require other code to change, but I package the changes to all the other code as part of the same change package, again no problem.  If I'm just making a small innocent change which is totally upward compatible, requiring no other code changes, but the release baseline is totally frozen in preparation for launch day, then, no way!  We don't want any changes that could possibly affect the release schedule - and simple software changes that go wrong have a certain track record.  So, it depends.

Branching is always a gut-wrenching issue.  If I branch, I have a new branch to support, to label and, possibly, to merge.  If problems come up that need to be addressed while the branch is in effect, I have another place where it has to be fixed.  How do I decide when the branch will merge back?  What happens if I determine a new branch has to be created off the old branch for another reason?  How will I eventually reconcile them?  What about a branch off the new branch?  Now let's look at the new release development? Is the same thing happening there?  I'm responsible for 100 files, how do I keep my sanity through all of this? Or what if I change jobs?  How does the next person deal with it all?  This is why we have branching strategies.


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.