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).
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.