Continuous Integration (CI) branching strategy and Configuration Management (CM) Framework

Rustem Abdrakhmanov

Apr 12, 2018 • 3 min read

There are many branching strategies available.
rustem_git_branching_strategy

The most popular of them are listed below:

Single branch (trunk based) - 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.

Sign up for more like this.