SCM Branching Strategies
From the Disciplined Agile Blog
by Tatsiana Balshakova,
Mark Lines, Mike Griffiths, James Trott, Bjorn Gustafsson, Curtis Hibbs, Scott Ambler
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.
View Posts By:
Tatsiana Balshakova
Mark Lines
Mike Griffiths
James Trott
Bjorn Gustafsson
Curtis Hibbs
Scott Ambler
Past Contributors:
Joshua Barnes
Michael Richardson
Daniel Gagnon
Valentin Tudor Mocanu
Kashmir Birk
Glen Little
Klaus Boedker
Recent Posts
DA 5.6 is released
Disciplined Agile 5.5 Released
Choose Your WoW! Second Edition Is Now Available
Requisite Agility applied in Project Management
Disciplined Agile and PMBoK Guide 7th Edition
Categories
#ChoiceIsGood,
#ChooseYourWoW,
#ConsumableSolution,
#ContinuousImprovement,
#CoreAgilePractices,
#experiment,
#Experimentation,
#GuidedContinuousImprovement,
#Kaizen,
#LifeCycles,
#ProcessImprovement,
#TealOrganizations,
Adoption,
agile,
agile adoption,
Agile Alliance,
Agile Business Analyst,
Agile certification,
agile data,
agile governance,
agile lifecycle,
agile metrics,
agile principles,
agile transformation,
Agile2018,
Agile2019,
Agile20Reflect,
AgileData,
Analogy,
announcement,
Architecture,
architecture,
architecture owner,
Articles and publications,
Asset Management,
Atari,
Backlog,
Barclays,
being agile,
benefits,
bi,
blades,
book,
Branching strategies,
Browser,
Business Agility,
business intelligence,
business operations,
capex,
Case Study,
Certification,
certification,
charity,
Choose your WoW,
CMMI,
cmmi,
Coaching,
Collaboration,
Communications Management,
Compliance,
Compliancy,
Conference,
Construction,
Construction phase,
Context,
Continuous Improvement,
coordination,
COVID-19,
Culture,
culture,
Cutter,
DA,
DAD,
DAD Book,
DAD discussions,
DAD press,
DAD roles,
DAD supporters,
DAD webcast,
DADay2019,
Data Management,
database,
dependencies,
Deployment,
Development Strategies,
DevOps,
disaster,
Discipline,
discipline,
Disciplined Agile,
disciplined agile delivery,
disciplined agile delivery blog,
Disciplined Agile Enterprise,
disciplined devops,
Documentation,
Domain complexity,
dw,
DW/BI,
Energy Healing,
Enterprise Agile,
Enterprise Architecture,
Enterprise Awareness,
enterprise awareness,
Essence,
estimation,
Evolving DA,
Executive,
Experiment,
facilitation,
FailureBow,
feedback-cycle,
finance,
Financial,
FLEX,
Flow,
foundation layer,
Funding,
GCI,
GDD,
Geographic Distribution,
gladwell,
global development,
Goal-Driven,
goal-driven,
goals,
Governance,
GQM,
Guideline,
Hybrid,
Improvement,
inception,
Inception phase,
India,
information technology,
infosec,
Introduction,
iterations,
Kanban,
large teams,
layer,
lean,
Lean Startup,
learning,
Legal Project Management,
LeSS,
Lifecycle,
lifecycle,
Manifesto,
mark lines,
marketing,
MBI,
Metaphor,
Metrics,
metrics,
mindset,
Miscellaneous,
MVP,
News,
News and events,
Non-Functional Requirements,
non-functional requirements,
Non-solo development,
offshoring,
Operations,
opex,
Organization,
Outsourcing,
outsourcing,
paired programming,
pairing,
paper,
People,
People Management,
phases,
Philosophies,
Planning,
PMBoK,
PMI,
PMI and DA,
PMI Chapter,
Portfolio Management,
post-format-quote,
Practices,
practices,
Principle,
Process,
process improvement,
process tailoring,
Product Management,
product owner,
Product Owners,
productivity,
Program Management,
Project Management,
project-initiation,
Promise,
Quality,
quality,
rational unified process,
Refactoring,
Reiki,
Release Management,
release management,
Remote Training,
Remote Work,
repeatability,
requirements,
Requirements Management,
research&development,
responsibilities,
retrospectives,
Reuse,
Reuse Engineering,
ride for heart,
rights,
Risk Management,
Risk Management,
Risk management,
Roles,
RUP,
SAFe,
sales,
Scaling,
scaling,
scaling agile,
Scheduled Workshops,
SCM,
scorecard,
Scrum,
ScrumMaster,
SDLC,
Security,
security,
self-organization,
SEMAT,
serial,
skill,
solutions software consumable shippable,
Stakeholder Management,
strategy,
Support,
Surveys,
Teal organizations,
team development,
Team Lead,
team lead,
Teams,
Technical Debt,
Teleconferencing,
Terminology,
terraforming,
test strategy,
testing,
time tracking,
Tool kit,
Toolkit,
tools,
traditional,
Transformation,
Transition iteration,
transition phase,
Uncategorized,
Upmentors,
Using PMI Standards,
value stream,
velocity,
vendor management,
Virtual Training,
Workflow,
workflow,
workspaces
Date
In this blog posting we overview the decision point, Choose an SCM Branching Strategy, of the Accelerate Value Delivery process goal.
Figure 1. The goal diagram for Accelerate Value Delivery (click to enlarge).
As you know, the Disciplined Agile (DA) tool kit helps you to make better decisions by describing the trade-offs associated with a practice/strategy. The following is an excerpt from the Choose Your WoW! book:
Accelerate Value Delivery==>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. |
Posted
by
Scott Ambler
on: March 27, 2018 07:32 PM |
Permalink
Comments (2)
Please login or join to subscribe to this item
Hi Scott! As co-author of SCM Patterns book, Streamed-Lines branching patterns, and having consulted for trunk-based dev, and Fowler's recent 'branching patterns" work, I think I can help you out significantly (along with some overall guidelines & principles to choose appropriate combo of branch-style, merging-style, and risk-profile for the degree scope scale variability support).
Is there a better forum/group to discuss at length before putting stuff here?
References mentioned (and a couple not):
- scmpatterns.com/book
- bradapp.net/acme/branching
- trunkbaseddevelopment.com
- martinfowler.com/articles/branching-patterns.html
- slideshare.net/bradapp/scm-patterns-for-agile-architectures-63349807 (I think you and I had our first face-to-face here)
Scott Ambler
Consulting Methodologist| Ambysoft Inc.
Toronto, Ontario, Canada
Brad, just ran into this now. First of all, thanks! Second, yes, we could definitely flesh this out a bit. I'll put on the backlog right now.
Please Login/Register to leave a comment.
