The what, why and how of Team Foundation Server - Part 1

In this two part article I will look at the core features of Team Foundation Server with a particular emphasis on how those pieces integrate in the day to day usage of the product.

During my professional career as a software developer I've had the opportunity to work with a large number of tools designed to support the software development process, from version control tools, bug tracking packages, build scripting languages, unit testing frameworks and requirements analysis tools. On the .NET platform a lot of the supporting tools worked well independently but there was often a far bit of manual work involved getting each of these systems to talk to each other.

With the introduction of Team Foundation Server into the Visual Studio group of products, Microsoft has helped development teams take a huge leap forward in the application of solid software engineering practices, and it is not because each of the exposed features inside the product are necessarily best of breed. The key ingredient is integration.

Getting started with Team Foundation Server

Team Foundation Server (TFS) is a server product which needs to be deployed into your development environment, where developers can access its various services. Because TFS is designed to scale to very large teams there are two topologies to choose from, dual server or single server.

In a single server deployment TFS is installed onto a Windows 2003 server with SQL Server 2005, IIS and Windows SharePoint Services. This kind of installation can handle a relatively large number of users and is suitable in most situations. Dual server deployments break off the database engine and analysis services components of SQL Server 2005 and place them on a separate machine to allow for greater scalability (by allowing more headroom for large check-in operations and separating data warehouse processing load onto a separate machine which can potentially be 64-bit).

Once the TFS server is installed clients access it by installing Team Explorer, a set of client-side components which includes a limited version of Visual Studio 2005 (if installed over the top of an existing installation it simply adds more functionality) as well as a number of add-ins for Microsoft Excel and Microsoft Project, each of which can be used to access data stored within the Team Foundation Server databases.

Team Explorer can be used to access each of the following feature areas of Team Foundation Server:

• Process Guidance
• Work Item Tracking
• Version Control
• Build Automation
• Reporting

Creating a Team Project

Before a development team can start using Team Foundation Server they must first create a Team Project. Team Projects represent a “unit of management” in which all team activities occur. To create a Team Project a Team Foundation Server administrator needs to open up Visual Studio 2005 and open the Team Explorer tool window (from the View menu). Once the Team Explorer window is visible a connection to the server can be established.

Right mouse clicking on the server node in the tree view will allow the TFS administrator to select “New Team Project”. The fact that this option is hidden away here is probably some indicator of how infrequently a new Team Project needs to be created. In most cases a software development team will only have one Team Project through the lifetime of a major software release.

The first thing that a development team needs to do when creating a Team Project (after giving it a name) is determine which process template to use.

Choosing a Process Template

Team Foundation Server allows development teams to choose what specific software development methodology that they want to use. Out of the box Team Foundation Server comes with two Process Templates:

• MSF for Agile Software Development
• MSF for CMMI Process Improvement

Each process template has a unique set of customisations including definitions for work items (things to do, things to fix, requirements etc), process guidance and reports. The following table shows the breakdown of the different work items in the two default Process Templates:

In this case even the difference in the number and naming of work items should be some kind of indicator of the general approach each of these two process templates promote. Rather than development teams speculating how they should use each of these work item types, Process Templates can optionally contain a set of Process Guidance pages.

If the out of the box Process Templates don't suit your specific requirements then you can customise them; in fact there are already a number of third-party process templates available including one for Scrum and Process MeNtOR.