blog

Guidance - Branching for each Sprint

Published on
4 minute read

There are a lot of developers using version control these days, but a feature of version control called branching is very poorly understood and remains unused by most developers in favour of Labels. Most developers think that branching is hard and complicated. Its not!

What is hard and complicated is a bad branching strategy. Just like a bad software architecture a bad branch architecture, or one that is not adhered to can prove fatal to a project. We I was at Aggreko we had a fairly successful Feature branching strategy (although the developers hated it) that meant that we could have multiple feature teams working at the same time without impacting each other. Now, this had to be carefully orchestrated as it was a Business Intelligence team and many of the BI artefacts do not lend themselves to merging.

Today at SSW I am working on a Scrum team delivering a product that will be used by many hundreds of developers. SSW SQL Deploy takes much of the pain out of upgrading production databases when you are not using the Database projects in Visual Studio.

With Scrum each Scrum Team works for a fixed period of time on a single sprint. You can have one or more Scrum Teams involved in delivering a product, but all the work must be merged and tested, ready to be shown to the Product Owner at the the Sprint Review meeting at the end of the current Sprint.

So, what does this mean for a branching strategy?

We have been using a “Main” (sometimes called “Trunk”) line and doing a branch for each sprint. It’s like Feature Branching, but with only ONE feature in operation at any one time, so no conflicts Guidance - Branching for each Sprint

Guidance - Branching for each Sprint  

Figure: DEV folder containing the Development branches.

I know that some folks advocate applying a Label at the start of each Sprint and then rolling back if you need to, but I have always preferred the security of a branch.

Like:

Don’t Like:

Why take the chance of having a problem rolling back or wanting to keep some of the code, when you can just abandon a branch and start a new one?

It just seems easier and less painful to use a branch to me! What do you think?

Technorati Tags: Scrum    SSW    TFS 2008    TFS 2010    ALM    Branching    Version Control 

tools-and-techniques blog configuration develop infrastructure practices process scrum ssw tfs tfs2008 tfs2010 version-control

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

Brandes Investment Partners L.P. Logo
Hubtel Ghana Logo
ALS Life Sciences Logo
Freadom Logo
Healthgrades Logo
Jack Links Logo
MacDonald Humfrey (Automation) Ltd. Logo
Alignment Healthcare Logo
Trayport Logo
Boeing Logo
Akaditi Logo
Sage Logo
Qualco Logo
Slicedbread Logo
Bistech Logo
Microsoft Logo

CR2

Epic Games Logo
Nottingham County Council Logo
New Hampshire Supreme Court Logo
Royal Air Force Logo
Washington Department of Enterprise Services Logo
Washington Department of Transport Logo
Department of Work and Pensions (UK) Logo
Alignment Healthcare Logo

NIT A/S

Illumina Logo
SuperControl Logo
Boeing Logo
Workday Logo