Team Foundation Server Version

Control and Related Topics

Adopting Visual Studio Team System 2008

Mickey Williams Director, Center of Excellence

mickey.williams@neudesic.com
 Customized to Your Process
Work Item Types

• Every organization works differently

– You must be able to customize
• Each type consist of:
– Fields, form, rules, states
• Build on standard methodologies
– MSF Agile
– MSF Formal

2
 Tightly Integrated
Work Item Tracking

• Version Control check-in links

• MS Project and Excel integrations
• Found In/Fixed In Build Integration
• Testing Integration
• Shared Infrastructure
– Reporting
– Authorization and Security
– Project and Iteration Hierarchies
– Email alerts

3
Demo - Work Item tracking
 Team Foundation Version Control
• Full featured software configuration management tool
– 3-Tier ASP.NET web service
– Leverages SQL Server 2005
– Advanced SCM capabilities
– Focuses on key development scenarios

• Deeply integrated into VSTS

– Future direction for version control from Microsoft

5
 Developer Check-in
• All check-in activities in a single UI
– Validate and commit source changes
– Resolve work items
– Send e-mail

• Changes encapsulated as a changeset

– Files that are checked-in together are versioned together
– Applied atomically to the repository
– Convenient for managing change

6
Check-in details
Visual
Studio
Work Item WorkItem 33231
Workspace
Tracking
Checkin

3 Update
Work Items Artifact
1 Validate 2 Link
Policies Commit Change Set 727012
Changes Change Set 727012
Change Set 727012
Checkin Policy Change Set 727012
Engine Change Set 727011
Change Set 727012
V2 V5 V1
V3 V4
WI Association

Static Analysis

Custom Policy

V5
Unit Testing

Version
Control
Integration Infrastructure
4
Events Raised for Check E-mail
3rd party sync purposes Notification
7
Demo – Integrated Version Control and Work Items
 Parallel Development
• Path-space branching
– Branches appear to have new server paths
– Aids in isolation scenarios

• Powerful merging
– Merge file adds, deletes, renames, etc.
– Computes changes that need merging
– Can cherry-pick individual changes

9
 Innovative Shelving
• Capture changes without a check-in
– Optionally restore unmodified files

• Scenarios:
– Interrupted work
– Backup/checkpoint work-in-progress
– Transfer changes
– Code review or buddy test

10
 Shared Checkout
• Shared or exclusive – you choose!
– Customize for your team project
– Customize for file types

• Exclusive == Lock on checkout

• Latest version required for check-in

– Otherwise triggers a merge conflict

11
 Traditional Promotion Modeling
Source baselines of varying quality

foo.cs 12 17 19 20

Prod Test Dev

bar.cs 10 18 19 21

12
 Team Foundation Promotion Modeling
Branches of varying quality

foo.cs 9 12 14 15 19 21 25
$/…/Dev
bar.cs 9 10 15 16 20 22 25

foo.cs 13 17 23 26
$/…/Test
bar.cs 13 17 23 26

foo.cs 18 24 27
$/…/Prod
bar.cs 18 24 27

13
Demo – Branching, Merging, Shelving
 Check-in Policy

• Set per-project or in process guidance

– Require specific notes
› Easily done
– Custom check-in policies
› Requires some code

16
 Check-in Policy

• Commonly asked-for policies

– Check-in comment required
› See Jim Manning’s blog
› http://blogs.msdn.com/jmanning
– Block file types
› Sample included in VS SDK
› http://msdn.microsoft.com/vstudio/extend
– Require specific comments/names/etc.
› Roll your own
– Several policies included in TFS Power Tools

17
 Check-in Policy

• Policies are just code

– Interact with TFS client user
› Policy has access to client and server information
› Can display UI
› Can load and examine source file
› Can veto check-in
• Well, almost
– Subclass PolicyBase

› Microsoft.TeamFoundation.VersionControl.Client.PolicyBase
› Class must be serializable
› Must be registered on each developer desktop

18
Team Build
 What Is Team Build?

• An automated build solution that is easy to use

• Capable of a complete end-to-end build
• Seamlessly integrated into VSTS
• Fully extensible through standard MSBuild
extensibility mechanisms
• Supports Continuous Integration

20
 Overall Architecture of MSBuild and Team Build

Team Build
Web Service Tasks Loggers .TARGETS

Visual Studio Team Foundation

MSBuild.exe project system
Server
MSBuild (core components) Work
Engine Loggers Source
item
control
tracking
Tasks .TARGETS

.NET Framework

21
Build Automation
Out-of-the-box daily build
• Good build process is hard to achieve from scratch
– Sometimes too difficult to attempt
– Requires complex combination of skills

• Simple processes are easier to adopt

– Builds are reproducible
– Multiple scheduling options
– Visual Studio Projects are built directly
› Leverages MSBuild
– Build report is centrally published

• Tight integration with Visual Studio Team System tools

– Work Item system
– Version Control

22
 Build Options
• Check-ins can optionally trigger a new build (Continuous Integration scenario)
– Check-ins can cause a build to be queued or can be accumulated
– Build frequency can be throttled

• Builds can be triggered by schedule

• Builds can be triggered by script

– Useful for some scenarios

23
Team Build Demo
 The <MSBuild …/> Task

• Executes target(s) in another MSBuild project

• Runs entirely in-process
• Never builds the same target in the same project twice within a build
• Used for communication between projects
– Gathering information from referenced projects
– Building child projects

25
 MSBuild Task Implementation

public class MakeDir : Task

{
private string[] directories;
public string Directories
{
get {return directories;}
set {directories = value;}
}

public override bool Execute()

{
foreach (string directory in directories)
{
System.IO.Directory.CreateDirectory(directory);
}
return true;
}
}

26
 Project-to-Project References

<MSBuild Projects=“@(ProjectReference)”>
<Output TaskParameter=“TargetOutputs” ItemName=“ResolvedReference” />
</MSBuild>

<Csc Sources=“...” References=“@(ResolvedReference)” />

• Automatically picks up the right configuration

• Automatically rebuilds the referenced project if
necessary
• Automatically cleans the referenced project when
parent is cleaned
• Referenced project need not be in the same .SLN

27
Passing In Properties To The Child Project
<Target Name=“BuildDebugAndRelease”>

<MSBuild Projects=“MyApp1.vbproj”
Targets=“Build”
Properties=“Configuration=Debug” />

<MSBuild Projects=“MyApp1.vbproj”
Targets=“Build”
Properties=“Configuration=Release” />

</Target>

• The “Properties” parameter can be used to pass in

global overriding properties into the child project
• Different sets of global properties cause new
instances of the child project to get loaded

28
 Team Build
Architecture

Team Foundation Client Drop

Location
Create build type
Start build
View Reports

Application Tier
Team Build Web Build Machine
Services

Data Tier
Sources
Team Work items MSBuild
Foundation
warehouse Team Build data

29
Questions?