Practical Team Foundation

Server

Marcel de VriesIT ArchitectMicrosoft MVP Team System

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

Session Code: CV.29

Practical Team Foundation

Server

Marcel de VriesMicrosoft MVP Team System

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

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 substructureUse 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

Code-Promotion Branches

Branch per Task

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 modelMulti release

Main branch(dev)

Prod. Branch V1

Prod. Branch V2

1

1

Legenda

# Build / week

Merge

BranchBaseline

Bug Fix in R1

Bug Fix in R2

CHILD OF MAIN

CHILD OF MAIN

Optional baseless merge

Branch by purpose modelSingle release

Main branch(dev)

Prod. Branch V1 Prod. Branch V2

1

Bug Fix Bug Fix

Legenda

# Build / week

Merge

BranchBaseline

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

1.5

“Major” Version

“Minor” version

dddyy

build Revision (# build on a day)

Create an effective build numbering scheme

• 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 Posterat 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