branching and merging for parallel development
Post on 23-Feb-2016
78 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related