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
• Areas can be used to break down your product complexities
– Are very useful for reporting purposes

Use Areas & iterations

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 Optional baseless merge Bug Fix in R1
CHILD OF MAIN

1

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

1
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
“Major” Version “Minor” version

dddyy
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

Sign up to vote on this title
UsefulNot useful