Branching and Merging for Parallel Development

Jeff Levinson (@tfsjeff)Senior ALM ConsultantNorthwest Cadence

DEV306

Branching And MergingAgenda

What are we trying to solve?Basic branching patterns and scenarios

Branch by ReleaseBranch by QualityBranch by Feature

What to consider when deciding on a strategy

What problems does branching solve?

Release code when it is readyIndependent construction of featuresSuspension of coding (code freeze)Know what code is released

Branching Patterns

Branch By Release (Staircase)LE

GEN

D

Branching / Merging point

Development

Test

Production

R1

R2

R3

BranchOn Test

Development Test Production

BranchOn Test

Branch By Release (Staircase)Handling bugs

R1

R2

R3

R4

BranchOn Test

Development Test Production

ForwardIntegrate asnecessary

BranchOn Test

BranchOn Test

ForwardIntegrate asnecessary

ForwardIntegrate asnecessary

LEG

END Development

Test

Production

Branching / MergingPoint

Branch by Release (Mainline)LE

GEN

D Release Branch

Development

Branching / Mergingpoint

Main

R1

R1.1

R2

R2.1

FI for Release

FI for Release

FI for Release

FI for Release

Branch by Release

Demo

Branch by Quality

Dev

QA

Bra

nch

ProdB

ranc

h

Firm

Soft

LEG

END Branching / Merging point

Branch

Branch by Quality (Safekeeping)

Dev

QAB

ranc

h

Prod (Safekeeping)

Bra

nch

Bra

nch

R1 R2

Bra

nch

R3

LEG

END Branching / Merging point

Branch

Branch by Quality (Permanent Hotfix)

Dev

QA

Bra

nch

Prod

Bra

nch

Hotfix

Bra

nch

LEG

END Branching / Merging point

Branch

Bug Found In Test

R1

Dev

QA

Bra

nch

Prod

Bra

nch

R2

L1 L2

Rx

Hot Fix

Code under test

L1

FI

RI

LEG

END

X Branching / MergingPoint + Label

Bug found

Multiple stepsdone as a singleunit of work

Branching / Mergingpoint

Bug Found In ProductionFixed on QA Branch

When the rules don’t work – break them

But understand why!

R1

Code under test

Dev

QA

Bra

nch

Prod

Bra

nch

R2

L1

R1

L2L2

Code under test

D1

L3

Rollback to L2

R3

R1

L4

D2

Code under test

L5

LEG

END

X Branching / MergingPoint + Label

Bug found

Multiple stepsdone as a singleunit of work

Branching / Mergingpoint

Bug Found In Production

Dev

QA

Prod (Safekeeping)

Bra

nch

Bra

nch

R1

R1

Code under test

LEG

END

X Branching / MergingPoint + Label

Bug found

Multiple stepsdone as a singleunit of work

Branching / Mergingpoint

R2

Code under test

R3

Fix the bug

RI

Bra

nch

R2

Fixed on release branch

Branch by Quality

DEMO

Branch By Feature

DEV

F1

F2

F3

QA

PROD

LEG

END

Branching / Merging point Multiple steps

done as a singleunit of work

Branch by Feature

DEMO

What to consider when deciding on a strategy

What strategy?

How many releases?

Single Release time?

Short Quality

Long Release

Multiple Concurrent?

Yes Release (Mainline)

No Release

Business is uncertain

Iteration length?

Short Quality

Long Feature

Question & Answer

Any scenarios you want to discuss?

For Reference

Pros and Cons

Branch by Release - Staircase

Pros

Simplest model to use

Good choice for single version web applications

Same pattern for hot fix or maintenance release

Minimal amount of branching

Cons

Not as flexible as other patterns

More active releases = more difficulty doing Forward Integration

Multiple test environments needed

Doesn’t support multiple concurrent releases well

May have to re-create the builds for new releases

Branch by Release - Mainline

Pros

No dependencies on any version except the prior .x version

Cons

Branching can get very complicated

Requires numerous merges and active management

Requires numerous test environments

Initial release from main, subsequent releases from release branch

Forward integrating bug fixes is difficult

Branch by Quality

Pros

Maximum flexibility

Easy ability to deal with multiple branches

Supports multiple paths to production (multiple test environments, fixes from different branches)

Cons

Can be extremely complex

Requires a dedicated build person

Without documented processes, can spiral out of control and you can “lose” source code because you can’t find it!

Branch by Feature

Pros

Separates out features

Allows for flexibility in release

Allows for easier debugging (a problem with one feature doesn’t effect another feature)

Builds on the Branch by Quality pattern

Helps deal with longer running features

Cons

Can get as complicated as Branch by Quality

Feature teams need to remember to sync often with dev branch

Can get confusing for teams working on multiple features

Requires at least one test environment per feature

May need multiple integration branches

Related Content

Breakout SessionsDEV202: Team Foundation Server for EveryoneDEV310: Team Build 2010: From Build Definition to Custom Workflow Activities in 75 MinutesDEV311: Deep Dive into Microsoft Visual Studio Team Foundation Server 2010 ReportingDEV327: The Accidental Team Foundation Server Admin

Interactive SessionsDEV271INT: Would You, Could You with TFS?

Hands-on LabsDEV366HOL: Branching and Merging Visualization with Microsoft Visual Studio Team Foundation Server 2010DEV367HOL: Planning Your Projects with Microsoft Visual Studio Team Foundation Server 2010

Find Me Later At… the Testing booth!

Track Resources

Resource 1

Resource 2

Resource 3

Resource 4

DEV Track Resources

http://www.microsoft.com/visualstudio http://www.microsoft.com/visualstudio/en-us/lightswitch http://www.microsoft.com/expression/http://blogs.msdn.com/b/somasegar/http://blogs.msdn.com/b/bharry/http://www.microsoft.com/sqlserver/en/us/default.aspxhttp://www.facebook.com/visualstudio

Resources

www.microsoft.com/teched

Sessions On-Demand & Community Microsoft Certification & Training Resources

Resources for IT Professionals Resources for Developers

www.microsoft.com/learning

http://microsoft.com/technet http://microsoft.com/msdn

Learning

http://northamerica.msteched.com

Connect. Share. Discuss.

Complete an evaluation on CommNet and enter to win!

Scan the Tag to evaluate this session now on myTech•Ed Mobile