Create 

a Team Project Define an isolation model Code Migration

Project Name
Project Description Consolidating common
Project Methodology (MSF CMMI, MSF Agile, Scrum, Light‐Weight Scrum) project lifecycle Feature Integration
Version Control (create empty source folder, new branch from existing, or none) workflows, feature • Parallel Releases • Sub‐team trees Define a code migration path, dealing
• Developer trees
Define coupling, demarcation of • Experimentation
(consider workspaces)
• Staging of with parallel development activities
• Risky features • Changes
Project administrators responsibilities, • Stabilization and associated merging of branches
Project contributors (analysts, developers, testers, etc.)
Project readers (view project data only) accountability, auditing where applicable.
Resources who will be managing builds and representing your Isolation Team
Version control check‐in policies (code analysis, testing policy, work items, custom)
Check‐in notes (none, code/security/performance reviewer)
development lifecycle
Backup urgency (none, daily or weekly) phases.
Think about Project‐Level Isolation

Isolation
Project‐Level Isolation Migration
Development

Development
What are the criteria for consolidation of artifacts, Catchup with latest in parent branch
i.e. sources, documents, work items, etc.?
How much visibility/sharing of those artifacts do we
O need? v1 v2
What compliance/auditing factors must we cater for

Catchup with latest 
from child branch
in terms of above? FEATURE 1

Reverse/Forward Integration
tion
tion
n
code promotion path

io
Do we want to apply different Work Item Type (WIT)

egrat

tegra
tegra
hierarchies and sub‐classification for WIT?
Do we want isolation at the project level or can that Reverse Integration Reverse Integration
t

ard In
Branch

ard In
ard In
be achieved thru a combination of version control Typical Isolation by
(Merge) (Merge)
branching and WIT hierarchies? Feature branch BRANCH X FEATURE 2

Forw
Forw
Forw

Team
Integration
Main

O O v1 v1 v2 v2 FEATURE ...n
Build v1 Build v2
ROOT
“Exceptional case”
baseless merge baseless merge

Typical Isolation by
Release
RELEASE 1

Reverse/Forward Integration
Branch Applies to all reverse integration steps Forward Integration Forward Integration Integration
Production

Production
branch BRANCH Y RELEASE 2
O v1 QFE QFE v2 QFE

Build v1 Build v2 code promotion path RELEASE ...n

Quality Bar Stakeholders Security/Rights Patterns to AVOID

Define quality criteria which
Bugs Define stakeholders, based Branching
must be met before code is
Impediments on one or more roles, who Cascading … branching, but never merging.
merged with parent
can accept/transact merges Maniac … branching for no apparent reason
branches. Testers Developers Lead Build
to and from another Developers Master Berlin wall … branch to split team, instead of features
branch.
Define build criteria which
Typical example ... Merge
must be met throughout the Stability
project. Features Development: Read‐Write Read‐Write Read‐Write Read‐Write Big Bang … deferring merging to the end
Main: Read Read‐Write* Read‐Write Read‐Write Mania … merging instead of developing
“Build often and build early.” Production: Read Read Read‐Write* Read‐Write
* Right to unblock a build. Critical scenario only!

Feature 
http://www.codeplex.com/VSTSGuidance
Feature(s) Tested Stable
Complete

v1.1 (2008-06-17)