Practical Team Foundation Server

Practical Team Foundation Server Marcel de Vries IT Architect Microsoft MVP Team System http://blogs.infosupport.com/marcelv [email protected]

Marcel de Vries Microsoft MVP Team System

http://blogs.infosupport.com/marcelv [email protected]

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

1

Prod. Branch V2 Optional baseless merge Bug Fix in R1

CHILD OF MAIN

1

Prod. Branch V1

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

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