Team Foundation Server (TFS) – Branching Guidance 2010

2010-03-20 Visual Studio ALM Rangers

· DEVELOPMENT branches Changes for next version work.

· MAIN branch This branch is the junction branch between the development and release branches, representing a stable snapshot

of the product that can be shared with QA or external teams.

· SERVICE PACK (SP) A collection of hotfixes and features targeting a previous product release.

· HOTFIX A change to fix a specific customer blocking bug or service disruption.

· RELEASE branch A branch where ship stopping bug fixes are made before major product release. After product release this branch

usually becomes read-only.

· FORWARD INTEGRATE (FI) Merges from parent to child branches.

· REVERSE INTEGRATE (RI) Merges from child to parent branches.

· RELEASE VEHICLE How your product gets to your customer (e.g. major release, hotfixes and/or service packs).

Basic Branch Plan

The Standard branch plan introduces a new release branch to support an additional release vehicle. Most organizations will call this a servicing branch to enable development of Hotfixes and Service packs.

· You have multiple ship vehicles (e.g. major release and additional service packs for that

release).

· You want to enable concurrent development of service pack and next version products.

· You have any compliance requirements that require you to have an accurate snapshot of your

sources at release time.

The Advanced plan is for products that must support many release vehicles and servicing scenarios. The plan allows for concurrent development of a major release, service packs, hot fixes and next version work.

Vocabulary

BRANCHINGQuick Start

Below is a basic plan that enables concurrent development for your next release, a stable

main branch for testing and a release branch for any ship blocking bug fixes.

Consider when à · You have a single major release that is shipped

(i.e. a single release vehicle) to customers.

· Your servicing model is to have customers upgrade to the next major release.

· Any fixes shipped from the release branch will include all previous fixes from that branch.

Standard Branch Plan

Consider when à

Advanced

Branch Plan

CommonSCENARIOS

For more information, refer to http://tfsbranchingguideiii.codeplex.com

DEV FT1

MAIN

Bra

nch

RI

PRODUCTION

V1.0.1

FI

V1.1 (Release)

V1.0 (hotf ix)

V1.1 Golden

DEV FT2

DEV FT3

Bra

nch

V1.1 FT2

V1.1 FT1

V1.1 FT3

RI

RI

RI

Bra

nch

Bra

nch

FI

V1.1 FT2 (start)

V1.1 FT3 (start)

V1.1 FT1 (start)

V1.1 FT1

VSS

BM

V1.0

FEATURE 1

TEAM 1

RELEASE 1

MAIN

Bra

nch

FEATURE 2

TEAM 2

Bra

nch

Bra

nch

Bra

nch

RI

RI

RI

1

DEV

MAIN

Bra

nch

FI

V1.1 (start) V1.1 FT3

RI

V1.1 (bug f ix)

FI

V1.1

FI

V1.2

RI

V1.2

V1.0

Production

Single Team Branching ModelAllows an organization to improve their engineering practices, by focusing on the flow of

source code throughout the development process, using very simple branching model.

It is imperative that the MAIN branch be stable with the latest customer-ready version

Concurrent Hot Fix, Service Pack and V.Next Branching ModelThis scenario allows organizations to service a released

product with hot fixes, with a cumulative service pack that

includes all approved hot fixes, and the ability to work

simultaneously on the next version of the product.

Multi Feature Teams ScenarioBranching Model

In the Multi Feature Teams

scenario, The DEV now becomes

a container node which contains a

group of branches where each

branch is dedicated for a particular

feature. The MAIN is still a single

branch as alike other scenarios.

When MAIN is ready to release, create

the SERVICE PACK, HOT FIX, and

RELEASE branches at the same time.

The RTM branch is a read-only copy of

what was released

Team, Feature, Release Isolation Branching Model

In this scenario branching is used as a policy for code promotions

and each branch has an owner. The owner of the branch has to

ensure that the policy is enforced (for example code reviews have

been completed).

This scenario is time intensive and involves quite a

number of people.

KE

YS

Branching Node

Label

Milestone

Build

FI Forward Integration

RI Reverse Integration BM Baseless Merge

BR

AN

CH

ES Main

Production

Other

Development

Feature

Release

Changeset

Source Structure

WoodGroveBanking

Dev

Source

Main

Source

$

+

-+

-

Source Structure

+

-

-+

-+

-

WoodGroveBanking

Dev

Dev-1

Source

Dev-2

Main

Source

Production

Source

Dev-3

$

+

+

Source Structure

--

+

+

-

-+

+

-

-

-+

-

+

-

WoodGroveBanking

Dev

Feature1

Source

Feature2

Source

Main

Source

Team

Team1

Source

Team2

Source

$

Production

Release1

Source

Source Structure

+

--

+-

+

-+

+

-

+

-

-

-

WoodGroveBanking

Dev

Dev-1

Source

Dev-2

Source

Main

Source

V1

Hotfix

Source

RTM

Source

Service Pack

Source

V2

$

+

Bra

nch

DEV-1

DEV …

MAIN

R1 (SP)

RTM

Bra

nch

Bra

nch

Bra

nch

Bra

nch

Bra

nch

Bra

nch

Bra

nch

Bra

nch

SERVICE PACK

R2 (SP)

HOT FIX

R1 (SP0) R1 (SP1)

R1 (SP0) R1 (SP1)

R2 (SP0)

R2 (SP0)

FI

1

2

2

3

4

5

6

7

8

DEVELOPMENT

MAIN

Bra

nch

RELEASE

Bra

nch

Development

Production /

Release

flo

w o

f me

rge

s (c

han

ges)

flo

w o

f me

rge

s (c

han

ges)

DEVELOPMENT

MAIN

Bra

nch

SERVICE PACK

RELEASE

Bra

nch

Bra

nch

Development

Production /

Release

flo

w o

f me

rge

s (c

han

ges)

flo

w o

f me

rge

s (c

han

ges)

MAIN

SERVICE PACK

HOT FIX

RELEASE

Bra

nch

Bra

nch

Bra

nch

Production /

Release

flo

w o

f me

rge

s (c

han

ges)

Team Foundation Server (TFS) – Branching Guidance 2010

Visual Studio ALM Rangers

Select the relevant branch,

i.e. Main in the Source

Explorer and select

“Properties” from the

context menu

Default Permissions = Allow R

ead

ers

Pro

ject

Ad

min

istr

ato

rs

Co

ntr

ibu

tors

Bu

ilder

s

Pro

ject

Co

llect

ion

Se

rvic

e A

cco

un

ts

Pro

ject

Co

llect

ion

Bu

ild

Serv

ice

Acc

ou

nts

Pro

ject

Co

llect

ion

A

dm

inis

trat

ors

Read

Check Out

Check In

Label

Lock

Revise other users’ changes

Unlock other users’ changes

Undo other users’ changes

Administer labels

Manage permissions

Merge

Manage Branch

Select the relevant branch, i.e. Feature 1, and

select “Reparent Branch” from the context

menu.

Branches are now First Class ObjectsReparenting Branches

Branch Visualization

Changeset Tracking

Branch Properties

Permissions

Used to establish parent-child relationship between baseless merged branches as well as to alter existing branches' parent-child relationship in a branch hierarchy.

To "reverse" an existing parent-child relationship, the child branch will need to be disconnected from the parent branch via "No parent" option, and then re-parent the former parent branch to the former child branch.

Select the relevant branch, i.e.

Main, from the “Branching and

Merging” context menu and

select “View Hierarchy” option to

obtain a logical and visual view.

You can drag from Dev (33) to Feature1, to

perform a drag and drop merge instruction.

New branch icon emphasizes first class branch objects

Branches enable features such as:· The ability to store properties like

the owner and a comment to each branch

· Viewing the branch hierarchy graphically

· Tracking where and when changesets have been merged