Search This Blog

Sunday, July 30, 2006

Moving TFS To Another Server

This weekend I have moved the Team Foundation server to another server. I used How to: Move Your Team Foundation Server from One Hardware Configuration to Another document to do this.
One problem I had that the referenced document: How to: Restore Team Foundation Server Data to a Different Server is a little confusing since it is not taking into consideration the possibility that you are moving a single server deployment and you have already done some stuff. I found that some of the things I've done in the main document are repeating in this document.
At the bottom line if you follow the guide it works and smoothly.

Thursday, July 06, 2006

TFS API

Team Foundation API is wide open and straight forward you can do everything you do through the Team Explorer and command line using the API. I'll post some examples using this API using Visual Studio 2005 and C#.

Creating a Team Foundation server

You should add reference to: Microsoft.TeamFoundation.Client.dll

Team Foundation assemblies are located under: C:\Program Files\Microsoft Visual Studio 8\common\IDE\PrivateAssemblies.

On the using clause add:
using Microsoft.TeamFoundation.Client;

// Create the server object and connect to the server.
TeamFoundationServer teamServer = TeamFoundationServerFactory.GetServer(serverName);

// Check the connection
teamServer.EnsureAuthenticated();

Now you have a Team Foundation Server object to work with. Check out the TeamFoundationServer class using Reflector or ObjectExplorer to see other members of the class.

TFS Source Control Strategy

I'm considering which startegy to use with Team Foundation source control.
I'm thinking of:

  • One main branch for the next release. Most of the work is done on this branch.
  • One bug fixing branch for a released version. This branch lives until a new version is released.
  • Temporary branch for changes needed to be enter to the next version prior to the current version release.
  • Branches for feature development that cannot be implemented in one release


Should look like this:
$/{Project}

  • main (v2.0 development prior to a release)
  • v1.1 (v1 bug fixes)
  • v3.0 (temporary branch until v2 is released)
  • FeatureBranch (for big developemnt effort that cannot be implemented for the next release)


  • Developers work on the main branch most of the time
  • If they have a fix for a released version then they need to merge it to the next versions too
  • When a temporary branch is opened the main branch should be merged to it often
  • When a feature is decided to be released it should be merged from the feature branch to the main branch
  • The main branch should be merged to the feature branch one a week

TFS Installation Guide

The installation guide is great! I have never seen such documented step by step guide. If you follow the guide you will have a successful installation of the server.
The most current version of the guide is available from Microsoft:
http://go.microsoft.com/fwlink/?LinkId=40042
Since we have small number of users I have installed the single server version of Team Foundation Server. You can get help on deciding how to deploy Team Foundation Server here: http://msdn.microsoft.com/vstudio/teamsystem/team/quickstarts/tfs_plan/

TFS Implementation

I've started an implementation of Team Foundation Server in my organization. I will try to document the process and maybe post some good stuff for others that are trying to implement Team Foundation Server too.