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.

Variant management is primarily a software engineering problem, not a configuration management problem. Your team must specify design criteria which will make CM manageable.  CM should not attempt to solve software engineering problems which are rooted in the design - though it may help you to identify them and variant handling is one area where software engineering needs to be addressed by the design.

It is not difficult to avoid dozens of variants.  In fact, it's much, much easier to reduce variant programs into run-time options and configurations than not to do so.  Introduce a simple design rule that a variant will not be a build time variant, or a load time variant, if it can be a run-time variant.  Whether it's a sizing option, a language option or a set of feature configurations, you can create separate images that support each of these.  You can just as easily add a requirement to the design team that says, the size will be configured at run-time by setting a size parameter, language through a run-time language setting, etc.  The main valid reason for variants to be handled in the CM process is different platform support.  This requires separate executables for each platform, but should never require branching.

In extreme cases you may be space constrained and can't load all of the 100s of options into one image.  In this case, options should be handled as separate files which can be co-compiled (i.e., have unique names and/or name spaces), and the problem is brought forward to link time, or perhaps even load time.  Files to be linked or loaded are tagged with the feature options so that a build specification need only identify the feature options.  Still, just the process of moving these options forward to link time will result in multiple deliverables that have to be managed, and multiple test beds that have to be reloaded.  So it should be avoided whenever possible.  In any case, the problem is not one which requires the use of branching to solve.  The use of branching for variants comes from the reuse of the same file name for each of the different variants, rather than the use of separate file names to support each variant.  Common code should reside in the common file, while variant dependent code should reside in a variant specific file (i.e., with a file name specific to the variant).

How hard is it to get the design to follow this rule?  Not difficult at all.  The most difficult step, by far, is communicating the rule, and the need for it, to all developers, and then ensuring peer reviews identify violations.  Apart from that, it is a trivial design change, and one that yields way more benefits than just avoiding variant branches.

A Next Generation Branching Standard?
I apologize for the length of this article.  If I had identified additional reasons for branching, you'd see an even longer article.  But it was necessary to justify each of the cases, and if you send me some others, I'll deal with them as well.

OK, you might not understand everything here.  Or maybe you do but you don't agree with it all (please send your comments).  But do you at least agree with the overall philosophy that branching is overloaded?  If you do, then I really, really, recommend you go back to the motivation paragraph.  We're not talking about a 5% or 10% reduction in complexity here.  No it's more like the difference between Assembly language code and Python

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.