As a developer at Magnetix A/S, I am currently spearheading the implemention of Microsoft Team Foundation Server (TFS) across the organization. This include moving most of our codebase from our old Visual Source Safe, setting up custom project templates and describing best practices and workflows.

The process have not been without problems, but my general experience is that TFS, once up and running, offers a some substantial step forward compared to our previous setup.

The Team Foundation Server is build upon Sharepoint and Reporting Services and combine advanced source control with reporting, task and document management. The server is exposed via Web Services and the TFS Client API. The most important client tool is the Team Explorer add-on for Visual Studio, but other clients exists including some third party applications. I am not going further into the product details as these a readily available on the web. Rather I am going to describe some of the choices and problems we faced during the implementation, and some of the decisions we took.

First of all, as a company developing custom Web Applications, we maintain a rather large collection of source code. Most of our solutions are Visual Studio 2008, but we do some active projects written in Visual Studio 2005 and even Visual Studio 2003.

Team Projects

Team Foundation Server organize projects and in Team Projects. Each Team Projects is based upon a project template, and includes a Sharepoint site (called Project Portal), a collection of documents, a source code folder and a collection of work items. Work items are a central concept in TFS: Work items a pieces of work, that needs to be dealt with. This could be a bug, a change request, a risk assessment or some other task. The types and layout of work items avaiable is defined in a project template. The project template describes many other aspects of the Team Project, includes policies and workflows, the initial structure of the document collection and so on. The template also includes a process guidance, that is a description of the project model in the form of a collection of web pages.

Creating custom project templates

TFS ships with two project templates describing a Microsoft Solutions Framework process for Agile software development, and another template describing a heavyweight CMMI process. But using the Team Foundation Server Power Tools, you can define you own templates – either from scratch or based upon a existing template. Other third party templates are also available.

At Magnetix A/S, we use our own process model mainly informed by Agile software development. Therefore I created a template based upon the Agile template, but modified according to our model. These modifications included changing the available tasks, which is done using XML.

Visual Studio solutions versus Team Projects

A Team Project defines a Sharepoint site, called the Project Portal. As we are planning to expose this portal to our customers, we generally opted for a single Team Project (and Portal) for each customer. This generally means that our Team Projects contains multiple Visual Studio solutions, as we typically develop more than one product for each of our customers. I believe that this decision is the right one, as Team Projects cannot be nested hieracally, and we really did not want to maintain a Team Project per Visual Studio Solution. Instead we created a Project area for each solution, so that e.g. work items can be target to a specific solution within the collection of solution that make up the Team Project. A few of our customers are so large that a single portal is not viable. These customer was divided according to the divisions within the customer.

Adding source code

With the Team Projects in place, I was ready to move our code base. The solutions was downloaded from our Visual Source Safe, and the source control bindings was removed. We initially left the solutions in Visual Studio as a precaution, but set them all to read only, so that no one accidently checked new code into our now deprecated Visual Source Safe.

As most of our solutions are Web Application, we generally do not support more than the most recent version, stored in the Main branch. Therefore, I predict that the Releases folder will be only sparsely used. Instead I recommend that our developers to apply a TFS label their releases. The label marks a certain version of the source code, and in this way, the labelled version can be restored later and then branched if the need arises.

Files that should placed under source control

When adding solutions to source control, you want to make sure that only the relevant files are placed in the source control repository. As a rule of thumb, not files that are generated by the build process must be placed under source control. Also, we recommend that documentation is placed somewhere else, e.g. on the Project Portal. This is because TFS do not handle changes done outside Visual Studio very well: If you want to edit a Word document, you need to check out the document in Visual Studio, do the editing and finally check the document back in via Visual Studio, as Visual Studio do not reconize any change done from the outside (a behavior that hopefully will change in 2010). Also, you do not want to add the following file types: Solution user option files (*.suo), project user option files (*.csproj.user or *.vbproj.user) and WebInfo files (*.csproj.webinfo or *.vbproj.webinfo).

The content of the bin folder is generally created during the build, and hence the bin folder should not be placed under source control. Some exceptions to this rule is the .refresh files that is placed in the Bin folder of Web Sites as these files controls the inclusion of references during the build. Also some systems (like Sitecore or EpiServer CMS) places large amount of libraries in the Web Applications bin folder. You may want to check these files in – if your policy is to keep complete system in the repository (this can be somewhat problematic in Sitecore 5.3, as the complete Web Application include more than 25.000 files!).

A special case occures you later references some of these CMS libraries. As soon as you reference a file in the bin folder, you should move the file outside the bin folder, and place it in a dedicated folder for third party assemblies (e.g. libs).

What’s next

Using TFS is a whole chapter in it self. A lot of can be said about the way in which files is checked out and placed on the local harddrive via Workspaces, how to branch files and how to expose the Web Access and the Project Portals (we are in the process of creating a work item webpart for the Project Portal, so that our customers can report issues directly from they portals – I found a proof of concept on Richard Fennells blog). I will return to these subjects in a later post. Also, you may what to explore the possibilities for TFS integration in programs other than Visual Studio – e.g. Excel and Microsoft Project. A good starting point is the Team System Developer Center.