Practical Team Foundation

Server
Marcel de Vries
IT Architect
Microsoft MVP Team System
http://blogs.infosupport.com/marcelv
marcelv@infosupport.com
Marcel de Vries
Microsoft MVP Team System

http://blogs.infosupport.com/marcelv
marcelv@infosupport.com

Practical Team Foundation

Server
Session Code: CV.29
 Agenda
• Team Projects, Reporting and Work items
– When to choose for a new Team Project
– Areas and Iterations
– Ad hock reporting from TFS Data warehouse

• Version Control
– Workspaces and Change Sets
– Solution size and inter solution dependencies
– Branching and base lining strategies

• Build
– Stamp build numbers in your assembly for traceability
– Generating Documentation
– Building Setup projects
 Team Projects
• TFS can hold 250-500 projects on a server
depending on WI schema
– Limitation mostly causes first time users to
have to wait very long when hitting a server
that exceeds this limit
• Due to a design issue that causes a large download
to the client (>32Mb)
• Team project is the bucket that contains all
artifacts
– Work items, Users rights, Build, etc
– Scope for reporting and building up metrics
from your teams
 Choosing Team Project
granularity
• Per Application
– The most common strategy for creating team projects is to create one
for each application under development.
– This strategy can support both large and small applications, as well as
multiple releases of applications being developed in parallel.
• Per Release
– In the “Team Project Per Release” strategy, every major application
release starts a new team project.
– This strategy works well for very large teams who are often working on
long-term projects.
• Per Team
– For a few customers, the best way to structure team projects is to align
them with the team boundaries in their organization.
– This strategy closely aligns a team with the workflows defined in TFS
work item types and provides a unit of reporting that spans the entire
team.
 Team Project substructure
Use Areas & iterations
• Areas can be used to break down your product complexities
– Are very useful for reporting purposes
• Can use it to measure what is adding the most costs to your project
– Define your areas of interest so you can measure them
• In software factories called viewpoints
– E.g. Break down a product into a feature tree
– Break down the project into architectural layers and from there into features

• Will help you determine #WI booked on certain artifacts

– Your entry point in improving your project!

• E.g. We determined that 60% of defects where caused by UI development

– This made us decide to invest in this area with more guidance and framework
• Result less defects in this area and therefore better predictability of our projects
 Reporting on TFS Data
warehouse
• TFS comes with a data warehouse
– Build in reports use ware house and TFS
databases for reporting
– You can extend the Data warehouse yourself
• Create a custom data warehouse adapter
• Areas and iterations are reflected back in the
warehouse to query on
• Building custom reports using SQL reporting
can be a time consuming task
– But you can also create ad hock reports using
Excel
 Demo
• Create ad hock report on TFS warehouse
– Work item breakdown assigned to specific
person
• Called bottleneck analysis 
 Agenda
• Team Projects, Reporting and Work items
– When to choose for a new Team Project
– Areas and Iterations
– Ad hock reporting from TFS Data warehouse

• Version Control
– Workspaces and Change Sets
– Solution size and inter solution dependencies
– Branching and base lining strategies

• Build
– Stamp build numbers in your assembly for traceability
– Generating Documentation
– Building Setup projects
 Version Control
• What is a workspace
– Mapping between Version control folders and
local file system
– Administered on the server!
• Local changes without notifying TFS are not
administered!
• Get latest will not do a Get in this case!
• What is a Change Set
– One complete atomic check-in of sources
– Includes metadata like associated work items
 Version Control
• Practical tips
– Always create one workspace for one TFS project
• Will only show pending changes for your current project
– Have only one mapping in your workspace
• Map team project root to local folder
– Makes searching very easy
– Cloak folders if get latest gets to big
– Install Power tools
• Easy rollback
• Tree diff
• Annotate
• Enables testing without Test Lists in build!
• … and much more
 Demo power tools
• Annotate
• Tree Diff
• Rollback
 Branching and baselining
strategies
• Branching defined:
– Taking a snapshot of source code to create isolation
• At a certain point in time
• At a stable or known state of source code
– Most of the time from a baseline
– Baseline == Label || Latest || hand picked set of change sets
– The resulting copy is the child branch, and the
source from which it was created is called the parent
branch.
– Bi-directional synchronization of changes with the
parent branch
• – usually referred to as integrating or merging
 Common used models

Branch per Release Branch per Task

Code-Promotion Branches
Branch per Component
 What branching model to
choose?
• Depends largely on size of the team and process to get to a
released product
– Also depends if you do single or multi release development
– ISV’s often do multi release development
• Recommend to use code promotion model
– In house development (not core business) often do single
release development (one version in production)
• Promotion model often overkill
• Large teams need more isolation
– Teams MS targets in whitepaper are large
– Sample includes 130 developers on 10 products!
– Use model published on codeplex
• http://www.codeplex.com/BranchingGuidance/Wiki/View.aspx?title=html
&referringTitle=Home
 What branching model to
choose?
• Common size teams require less isolation
– Team size 2-25 developers
• Recommendation, use a branch by purpose model
– Create one development branch to start
– Create a branch only when you are stabilizing
towards a internal/external release
– Keep a branch for maintenance if you develop for
multiple releases
• Add your documents to version control
– Let’s you create a baseline across code and
requirements
– Impossible when documents only on share point
 Branch by purpose model
Multi release

CHILD OF MAIN
Bug Fix in R2

Prod. Branch V2
1
Optional baseless merge
Bug Fix in R1 CHILD OF MAIN

Prod. Branch V1
1

Main branch(dev)

Legenda

# Build / week

Merge
Baseline
Branch
 Branch by purpose model
Single release

Bug Fix Bug Fix

Prod. Branch V1 Prod. Branch V2

Main branch(dev)

Legenda

# Build / week

Merge
Baseline
Branch
 Solution structures
• Visual Studio solutions with >10 project become
impractical
– Slow startup times
– More potential locking on shared resources
• Team Test files (e.g. vsmdi, runconfig, etc)
• Split your product across multiple solution
– But what about my dependencies?
• Use File dependencies via a substituted drive
– Model will scale to really large software products
– Solution == Configuration item
– Configuration item is unit of design, development and
versioning
• Often compared to a subsystem
 Solution structures
• Facilitate the file references in version control
– Create a folder that contains referenced
assemblies from other solutions
• With TFS very efficient storage
• E.g
– Extref folder containing some subfolders:
• For every deliverable (output from other solution)
• For every 3th party product you use
– If using com interop, generate interop assembly by hand
and reference interop assembly!
• Location to keep the Strong Name file
 DEMO
• Solution Structures for large scale
applications
• Signing with only one snk file at one
location
• Branching of a version 1.0 of the product
for bug fixing
 Agenda
• Team Projects, Reporting and Work items
– When to choose for a new Team Project
– Areas and Iterations
– Ad hock reporting from TFS Data warehouse

• Version Control
– Workspaces and Change Sets
– Solution size and inter solution dependencies
– Branching and base lining strategies

• Build
– Stamp build numbers in your assembly for traceability
– Generating Documentation
– Building Setup projects
 Stamp build numbers in your
assembly
• How can you determine what assembly in
production is related to a build?
– You need to stamp the build number into your
assembly to create effective problem solving
• Same as MS does with it’s assemblies
– No out of the box solution from Microsoft
• Can be done extending Team Build
– Team build is based on MS build
• Wizard generates script based on provided scenario
details
– Extensibility of team build is based on MS build
extensibility
 Stamp build numbers in your
assembly
• Difference between Assembly version
number and file version numbers
– Assembly version is used by fusion loader if
assembly is strong named
– File version number is the one shown by the file
system and used by e.g. installers
• To prevent assembly binding hell
– Set a fixed assembly version number
– Make the file version number reflect assembly
version and the current build
 Create an effective build numbering scheme

1.5 dddyy
“Major”
Version
“Minor” version build Revision (# build on a day)

• AfterGet is where you can alter the sources in team

build
• Build custom task to tweak the attributes
– Can also use AssemblyInfo task from GDN
– Build number must be kept < 65535
• Is a short int 
 DEMO
• Stamping the build number in your
assembly by extending team build
 Generating documentation
• Leverage XML documentation in C# or
VB.NET (Since .NET 2.0)
• Currently we used NDOC
– NDOC is officially stopped by it’s founder
• Microsoft is working on an alternative
– Called sandcastle
– Requires XML documentation to be turned on
during build
• Can be enforced with check-in policy 
 Creating an installer
• Visual studio setup projects are not
supported out of the box of Team Build
– Can be fixed by creating your customized build
scripts and installing visual studio on the build
machine
• Better is to use WIX in stead
– WIX is an XML based script language
– Open source project by Microsoft
– Provides visual studio integration and MS build
extensions
• Install extensions on build server and development
workstations
Running tests without Test SKU
• Unit tests require a vsmdi file to run during the build
– You can specify which list to run
– Only problem, you need the test SKU to create a list
• Power tools enable you to run the tests without the
vsmdi file
– Need to replace the build targets file
– Need to copy the power tool dll that contains the new task
– Specify the testcontainers in the build
• All tests executed in the specified assembly will be run
– Requires you to split the test scenarios into separate
assemblies
Demo Running Test without
VSMDI
 Agenda
• Team Projects, Reporting and Work items
– When to choose for a new Team Project
– Areas and Iterations
– Ad hock reporting from TFS Data warehouse

• Version Control
– Workspaces and Change Sets
– Solution size and inter solution dependencies
– Branching and base lining strategies

• Build
– Stamp build numbers in your assembly for traceability
– Generating Documentation
– Building Setup projects
Team System Poster
at info support booth
 Q&A
• Where to find more information
– http://Blogs.infosupport.com/marcelv
– Downloads:
• http://accentient.com/widgets.aspx
Evaluation form
Vul je evaluatieformulier in en maak kans
op een van de prachtige prijzen!!

Fill out your evaluation form and win one of

the great prizes!!

Session Code:CV.29