SCM Branching Strategies

A few weeks ago on the DA LinkedIn forum there was a discussion around software configuration management (SCM) branching strategies.  It was pointed out that DAD didn’t have much coverage of them, which was correct.  So we’ve decided to rectify the situation.  We’ve added a decision point, Choose an SCM Branching Strategy, to the Move Closer to Deployable Release process goal.

Figure 1. The goal diagram for Move Closer to Deployable Release (click to enlarge).

Process Goal: Move Closer to a Deployable Release

As you may know, we are currently working on a new book tentatively titled The DAD Handbook, and are posting excerpts to the book on the Sneak Previews page (for DAC Members only).  We’ve decided to deviate a bit from that plan and share the table describing the options for this decision point.  Our hope is that you’ll choose to provide us with feedback as this is still an initial draft.  Anyone who provides feedback that we act on will be acknowledged in the book when it is published.

Move Close to Deployable Release==>Choose an SCM Branching Strategy

We need to identify our team’s branching strategy for our source code repository.  A branch is a copy or clone of all, or at least a portion of, the source code within the repository. We branch our code to support concurrent development, capture of solution configurations, multiple versions of a solution, and multiple production releases of a solution. so that it may be worked on in parallel.  As you can see in the following table there are many branching strategies available to us, strategies which may be applied in combination.

Options (Not Ordered) Trade-offs
Single branch (trunk based). As the name suggests there is only the mainline branch (the trunk). • Straightforward approach.
• Well suited for continuous delivery.
• Merge conflicts are usually straightforward and easy to address.
Branch by customer/organization. A customized release created for a customer or organization. Standard features are developed on the mainline branch, while customer-specific features are maintained on their branches. • Short term solution to delight a customer.
• Supports customer-specific functionality that is more complex than what can be implemented via configuration data.
• You need a tenancy strategy that ensures privacy for each customer.
• Potential to create a significant maintenance burden over time as the number of supported customer versions grows.
• Defects need to be analyzed to determine if they pertain to standard functionality or customer-specific functionality.
• Strategy needed to promote customer-specific features to become “standard product” features on the mainline branch.
Branch by developer/workspace. Developers have their own private branches to work on. • A promotion strategy, where you update ancestor/parent code versions, is required.
• A rebasing strategy, how you update descendent/child code versions, is required.
• Often used in combination with other branching strategies.
• Enables experimentation by developers.
• Enables review of changes in staging areas before they are promoted to the trunk.
Branch by module/component. A branch is created for a specific module (or cohesive functionality such as a component, subsystem, library, or service) of the larger solution. Effectively a single branch strategy for a module. • Enables parallel, component-based development teams.
• Requires a clean architecture.
• Requires system integration testing (SIT) across the modules to ensure the overall solution works together.
Branch by phase/quality gate. A branch is created for a specific project phase or approval stage. Sometimes called a “waterfall branching model.” • Enables the team to continue working on new code while they wait for the previous version to be reviewed and approved.
• Any changes required by the review will need to be implemented in the reviewed version of the code, reviewed again, and when accepted rebased up into the mainline branch.
• May be required under strict interpretations of regulatory compliance.
Branch by purpose. You only create a new branch when it is absolutely necessary – you must start work on a new version but still need to maintain the current version. • Supports baselining of previous versions/releases if required.
• Works well when you have a single release of a solution that you wish to maintain, but still may need to temporarily branch for defect fixes or to temporarily support parallel development.
• All development can occur via a single branch strategy when previous releases are not maintained.
Branch by task/story. A branch is created to work on a piece of functionality, perhaps described as a user story or usage scenario. • Enables feature-based development teams.
• Code needs to be merged back into the mainline branch.
• Opportunity for significant collisions when features developed in parallel cause changes to the same code files.
Branch by version/release. A new branch is created for a release of a solution while maintenance of previous versions still occurs. Version/release branches are often created at the start of the Transition phase (if you still have one) so that developers can begin working on the next/upcoming release. • Enables you to maintain multiple versions of your solution in production.
• Requires serial changes to code, with sequential check ins/outs.
• Adds overhead to maintenance of released versions due to need to make changes in the version branch and then promote to the trunk and any appropriate version/release branches.

We would love to hear your feedback about this material, so please add a comment below.

Also, as you’d expect, we soon hope to have a full excerpt of this goal posted for feedback at the Sneak Previews page.

4 thoughts on “SCM Branching Strategies

  1. Frank Schophuizen

    Not all these “branching strategy” are branching strategies. Branching typically involves duplication of a version of an object so that modifications can happen relative to that (common) version. Having 2 different objects is not “branching”. So “branching by module/component” is not branching; it is an integration strategy, as integrating different modules/components requires integration to become a single solution.
    Similarly, several branching strategies are no integration strategies. An integration strategy typically involves bringing together different objects or different versions of the same objects to become a single solution. Many branching strategies involve an integration strategy, but some branching strategies do not aim for integration into a single solution. For example “branching by phase/quality gate” is not about integrating, but about replacing a solution in a particular stage by a new version.
    In fact, I think that a description of branching strategies should go hand-in-hand with integration strategies and an architecture of variants.

    In the ‘trade-offs’ column I would expect some statements about early vs late integration, backward / forward compatibility and code-time/build-time/install-time/run-time diversity.

    I am missing a description of combining different branching strategies and the trade-offs that are made when doing so. Also, I am missing the decision points for changing from one branching strategy to another, for example when an organization grows and the branching strategy for the smaller organization does no longer fit the larger organization. Think for example about extending the portfolio to multiple products with a common architecture, or developing systems-of-systems.

    Also, I think that in the trade-off it should be made clear how to deal with combining different branching strategies.

    Reply
    1. Scott Ambler Post author

      Frank, some thoughts:
      1. Good points. We’ll update the posting soon based on what you’ve said.
      2. Regarding components/modules, it depends. In some situations we’ve seen these things be many thousands of lines in size. Think large-scale domain components or modules (e.g. Customer or Transactions in a bank).
      3. For branching by gate, what about gates where development streams are parallel? e.g. We get going on the code while some aspects are still being thought through? I clearly need to point that out in the description as it’s not there now.
      4. I like the idea of discussing how branching and integration tend to go hand-in-hand.
      5. Good points about trade-offs.
      6. The goal of this book isn’t to cover combinations of strategies. That’s the topic of a follow-up “Playbook” that we have planned.

      Reply
  2. Frank Schophuizen

    Thanks Scott. Sorry for being a bit blunt in my response; I am Dutch 🙂 I think it is a great article; I wouldn’t have bothered responding if it wasn’t.

    Ad 2. You’re right: sometimes it is difficult to make the distinction between a branch (parallel variants of the same object) and not-a-branch (parallel development of different objects). May be I shouldn’t be that puristic about it! I did encounter situations where different components are developed in parallel where the integration strategy was actually called “branching strategy”. So may be “parallel development for the same product” could be considered as “branching”.
    On the other hand, version control (VC) tools typically apply branching only for parallel variants from a common ancestor.
    Ad 3. Indeed, that wasn’t clear to me, so some clarification would help
    Ad 4. The idea that branching and integration go hand in hand gave me another thought: branching for code may be different from branching other assets. For example, code may be developed in branches (e.g. feature branches) while requirements, design and tests may without branches or with a different branching strategy/strategies as code (e.g. release branches). of course, that may be too complicated for this article, but in practice organizations may have to take that into account.
    Ad 6. I am looking forward to the book and the “Playbook”

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *