New Branching Standards for Configuration Management

[article]

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.

Summary:
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.

Pages

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03