Configuration Management Branching Strategy  

This article describes three key branching models used in Software Engineering projects. These branching strategies are employed to streamline software development and support release management needs. The models are:

Model-1 Small Team Model using Emergency Fix Branches

Model-2 Medium Team Model using a separate developer and release branch

Model-3 Large Team Model using parallel development streams

Below we describe each model in more detail i.e. discussing structure, advantages, disadvantages and recommendations. At the end we provide a matrix for easy comparison.

Note: All models are based on their predecessor i.e. Model-2 extends Model-1, Model-3 extends Model-2. All models assume the use of a modern Version Control tool and the implementation of basic best practices like baselining.

Note: As a minimum recommendation all projects should use Model-2 or better.

Model-1 Small Team Model (Single Stream with EFIX Branches)

Summary: Developers and Release Manager use a single mainline. Branching is only used to support Emergency Fixes. To avoid loss of emergency changes, make sure that the team retrofit the emergency branch back to main line at regular intervals (& always before next major release).

Note: This is a very traditional model, however is vulnerable to serious problems.

Advantages of Model:

• Simplicity and Minimal need for Branch Integration (post Efix)

• Support tools with Weak Merge/Integration Facilities

• Allows fixes to be done in separate parallel branch

• EFIX branch supports quick fixing of historic baseline

• EFIX  branch prevents latest changes being released during a fix

Disadvantages of Model:

• Main line vulnerable to chaotic check-in and ultimately non-working code

• Inability to easily choose any code other than latest

Recommendation:

This model is only suitable for very small teams. To be effective it ultimately relies on good developer discipline and very good communication. The risk of mainline corruption (& costly rollback) increases as team size grows.

Model-2 Medium Team Model (Dual Stream)

Summary: Extension of previous model with Main line restricted to official releases only. Developers work on development stream (branch) and merge mature code back to main line at relevant milestones.

Note: In example DEV branch is periodically retrofitted (shown in red) with changes on the main line. This regular integration action ensures that e-fixes are also seen in development and that the final merge (from Dev branch to MAIN) is relatively trivial.

Advantages of Model:

• Simplicity and Minimal need for Non-Trivial Integration (Merges)

• Still support tools with fairly Weak Merge/Integration Facilities

• Avoids Release and Development contention

• Eases teams ability to select code other than latest

• Allows fixes to be done in separate parallel branch

• Stabilizes main line (less fluid, no casual change)

• EFIX branch supports quick fixing of historic baseline

• EFIX  branch prevents latest changes being released during a fix

Disadvantages of Model:

• Requires more Merging (however should be trivial merges).

• Not all Version Control tools have a suitable (intelligent) merge facility.

Recommendation:

This model is suitable for most teams. The incorporation of a second branch to manage development helps slow down main-line change, enhances developer fluidity, increases likelihood of mainline stability and helps us promote code (from DEV to Main) based on business requirements and code maturity.

Hint: If in doubt use this model.

Model-3 Large Team Model (Multi Stream)

Summary: Extension of previous model with addition of multiple developer streams. Note: Developer streams could be created to focus on delivering separate functional components or meeting different requirement delivery deadlines.

Ultimately developer work must be integrated back to main line before release. This may be done either directly (e.g. DEV#M to MAIN) or indirectly (e.g. DEV#M to DEV#1 to MAIN etc).

Note: This model supports any number of parallel branches, however experience shows that parallel streaming beyond four levels would typically cause confusion and configuration management difficulties. 

Note: In example above both streams integrate back to main directly.

However DEV branch #M is periodically retrofitted (shown in red) with changes on the main line. This regular integration action ensures that final merge from Dev branch #M to MAIN is relatively trivial.

Advantages of Model:

• Allows project work to be streamed into logical sub-projects.

• Developer Productivity Maximized (closer to zero contention).

• Avoids Release and Development contention

• Eases teams ability to select code other than latest

• Allows fixes to be done in separate parallel branch

• Stabilizes main line (less fluid, no casual change)

• EFIX branch supports quick fixing of historic baseline

• EFIX  branch prevents latest changes being released during a fix

Disadvantages of Model:

• Requires more Non Trivial Merging (can cause complex merges)

• Not all Version Control tools have a suitable (intelligent) merge facility.

Recommendation:

This model is suitable for large teams working on sub-requirements of the same project. Each team can work separately from each other (hence supporting their fluidity and avoiding sub-project contention).

Note: Most Version Control tools poorly support this form of Parallel Engineering.

Hence, To alleviate merge difficulties, integrate often.

Summary of Model Differences

The following matrix summarizes the primary differences of the above models.

Copyright © 2002 SnuffyBear Company (Sydney Australia).