VSS versus TFS

FAQ: VSS vs TFS

I get a lot of questions about what is the difference between TFS and VSS and if I move to Team Foundation Server then what functionality will i lose. After hearing this question many times, I decided to compile a table of features and commands that are available in both the systems to show that TFS has all the functionality that VSS has plus more new features like annotation and a change management. Visual SourceSafe is just a source control system whereas TFS is a change management system that provides work item tracking, project tracking, reporting and document management. The table below shows the list of VSS commands and their availability in TFS:

VSS Feature	Compare with TFS
Label Version	Feature is available in TFS
Merge	Feature is available in TFS
Check-in / Check-out	Feature is available in TFS
Delete / Destroy / Purge	Feature is available in TFS
Rollback	Feature is available in TFS>
Search files	Feature is available in TFS
Sharing / Merging / Branching	Feature is available in TFS
View History	Feature is available in TFS
View Differences	Feature is available in TFS
Source Control Security	Better security model
Integration with Visual Studio	Has TFS Plug-in

By the way, TFS comes with a migration tool for moving VSS data and version history into TFS so if you are thinking about moving to TFS then read my article on TFS planning and migrating VSS data to TFS.

Agile vs CMMI

FAQ: Compare TFS Methodologies

TFS comes with two methodologies out of the box namely MSF for Agile Software Development and MSF for CMMI Process Improvement. I get a lot of questions about what is the difference between the two methodologies so I decided to compare them. The first difference is that they both have different types of work items. The table below shows this information:

Methodology Name	WorkItem Type
MSF for Agile Software Development	Scenario
MSF for Agile Software Development	Quality of Service Requirement
MSF for Agile Software Development	Task
MSF for Agile Software Development	Bug
MSF for Agile Software Development	Risk
MSF for CMMI Process Improvement	Bug
MSF for CMMI Process Improvement	Change Request
MSF for CMMI Process Improvement	Issue
MSF for CMMI Process Improvement	Requirement
MSF for CMMI Process Improvement	Review
MSF for CMMI Process Improvement	Risk
MSF for CMMI Process Improvement	Task

The state transitions for the two methodologies are quite different also. We can make that comparison by looking at the state transition diagrams shown below:

MSF Agile State Transition Diagram

MSF for CMM Process Improvement State Diagram

Both methodologies use Mirsoft Solutions Framework ( MSF ) under the hood so your project will go through the lifecycle shown below:

1. Envisioning
2. Planning
3. Developing
4. Stabilizing
5. Deploying

TFS Planning - Part 4 - Migration from VSS

Introduction

Microsoft provides a command line tool for migrating Visual SourceSafe databases to TFS. Before we begin the migration, it is better to analyze the VSS databases and gather some general information like Database Name, Database Size, Owner, user list and applications that reside in the databases. I am attaching a template for gathering this information in the resources section of this post.

Solution

Install Visual SourceSafe 2005 on the TFS 2008 server. Make a copy of the SourceSafe databases that need to be converted and place them on the TFS Server. It is risky to run the migration on the original databases. It is better to make a copy and then run the migration on the copy of the VSS databases. The process involves three steps namely copy, analyze and migrate. We need to run the migration utility in analysis mode and then cleanup our VSS databases based on the output of the analysis and then run the utility again in migration mode to do the actual migration.

Preparation

You will need to create three directories to organize your migration process. There will be a vssDatabases directory where all the databases that need to be migrated will reside. There will be a vssMigrate directory where the actual migration reports and output will be generated. I recommed putting the vssMigrate directory underneath visual studio directory where the migration executables are located. The third directory you will need is called TFS_Scripts and you can put this any where. I am putting this directory on my c: drive just to keep it separate from other directories but you can put it in another place if you like.

Solution Details

1. Install Visual Source Safe 2005 on the TFS 2008 Server
2. Create a new folder called c:\vssDatabases and put all source safe databases in there.
3. Create a new folder called …\Microsoft Visual Studio 8\Common7\IDE\vssMigrate. This is going to store all the migration reports and log files which will show if our migration completed successfully.
4. Create a new folder called c:\TFS_Scripts and put all your migration xml scripts in there. Later in this post we will see how to create these xml files.
5. Create a Settings.xml file which will contain migration analysis instructions.
6. Prepare the VSS databases for migration by running Analyze.exe to fix errors inside VSS databases. This should clean up the databases and make them ready for conversion. Run vssConverter.exe in analysis mode.
7. Create a MigrationSettings.xml file which contains the actual migration instructions.
8. Run vssConverter.exe in migration mode.

Sample command line instructions:-

-- Preparation work
mkdir c:\vssDatabases
copy DatabaseName c:\vssDatabases
cd c:\Program Files\Microsoft Visual Studio 8\Common7\IDE
mkdir vssMigrate
mkdir c:\TFS_Scripts

-- Simple instructions
cd C\Program Files\Microsoft Visual SourceSafe
analyze.exe -F -V3 -DB c:\vssDatabases\DatabaseName\data
analyze.exe -F -V3 -DB c:\vssDatabases\DatabaseName\data
analyze.exe -FP -V3 -DB c:\vssDatabases\DatabaseName\data

cd c:\Program Files\Microsoft Visual Studio 8\Common7\IDE
vssConverter Analyze vssMigrate\DatabaseName\Settings.xml
vssConverter Migrate vssMigrate\HistoricalDSS\MigrationSettings.xml

-- Instructions for use in a batch script
echo Step 1 - Run VSS Analysis
cd c:\Program Files\Microsoft Visual SourceSafe
analyze.exe -DB c:\vssDatabases\DatabaseName\data
analyze.exe -F -V3 -D c:\vssDatabases\DatabaseName\data
analyze.exe -DB c:\vssDatabases\DatabaseName\data

echo Step 2 - Run TFS Migration Analysis script
cd c:\Microsoft Visual Studio 8\Common7\IDE
VSSConverter Analyze c:\TFS_Scripts\Settings_DatabaseName.xml

echo Step 3 - Run TFS Migration
cd c:\Program Files\Microsoft Visual Studio 8\Common7\IDE
VSSConverter Migrate c:\TFS_Scripts\Migration_Settings_DatabaseName.xml

What does a Settings.xml file look like?

<?xml version='1.0' encoding='utf-8'?>
<SourceControlConverter>
<ConverterSpecificSetting>
<Source name='VSS'>
<VSSDatabase name='c:\vssDatabases\DatabaseName'></VSSDatabase>
</Source>
<ProjectMap>
<Project Source='$/'></Project>
</ProjectMap>
</ConverterSpecificSetting>
<Settings>
<Output file='Analysis.xml'></Output>
</Settings>
</SourceControlConverter>

What does a MigrationSettings.xml file look like?

<?xml version='1.0' encoding='utf-8'?>
<SourceControlConverter>
<ConverterSpecificSetting>
<Source name='VSS'>
<VSSDatabase name='c:\vssDatabases\DatabaseName'></VSSDatabase>
<UserMap name='D:\TFS_Scripts\Usermap.xml'></UserMap>
<SQL Server='gtnahouappv97' />
</Source>
<ProjectMap>
<Project Source='$/' Destination='$/tfsProjectName'></Project>
</ProjectMap>
</ConverterSpecificSetting>
<Settingsv
<TeamFoundationServer name='tfsServerName' port='8080' protocol='http'></TeamFoundationServer>
<Output file='Migration_Analysis.xml'></Output>
</Settings>
</SourceControlConverter>

Note:

The MigrationSettings.xml file can be used to control what projects need to be migrated. You can control if you would like to migrate everything or just a few projects. The $/ means migrate all projects. There is also a command line argument to set the migration date so that all changes beyond that date are migrated. If you ran the migration once and had some problems then you will need to use tfsDestroy command to destroy the source control project in TFS and then create a new TFS source control project using Team Explorer and then you can run

What does a UserMap.xml file look like?

<?xml version='1.0' encoding='utf-8'?>
<UserMappings xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:xsd='http://www.w3.org/2001/XMLSchema'>
  <UserMap From='grominger' To='domain\grominger' />
  <UserMap From='gcharles' To='' />
  <UserMap From='fred' To='' />
</UserMappings>

Note:

This UserMap.xml file is automatically created by the VSS Converter automatically. You can create this file yourself also if you would like to control the user mapping or modify the security on the TFS side. For example, <UserMap From='Jane' To='MyDomain\Janep'></UserMap> This mapping causes all actions logged by VSS user “Jane” to be changed to Team Foundation user “ MyDomain\Janep ” during the migration so you can change version tracking history. Leaving the To field blank will keep the original credentials as they are. If a user line is removed then that user will not be added to the TFS security database.

Resources:

• Migration Planning [Excel Format]

Navigation:

• Part 3

FAQ : How to setup Team Explorer?

Introduction

Visual Studio 2005 and 2008 Professional Editions do not come with Team Explorer. The Team Suite version comes with Team Explorer but not the professional version. If you have Visual Studio Professional Edition then you will need to install Team Explorer in order to access Team Foundation Server. Team explorer is available from Team Foundation Server 2005 DVD. It is also available from the Team Foundation Server 2008 DVD. Depending upon the version of Visual Studio you have, you may want to install the appropiate version of Team Explorer. There is not much difference between Team Explorer versions since they are just plug-ins into the IDE so if you go with either one of these versions you should be fine. Just stick the DVD in and run setup.exe. This should bring up an installation dialog box as shown below: 

On the screen shown above, please select Team Explorer and then click the link. [ For Visual Studio 2008 you have to click the install button]. Please take all default prompts during the installation. After the installation has been completed successfully, the Team menu should now be available but in a hidden state. Once you add a connection to your Team Foundation Server and select TFS as your source control plugin then you will see the Team menu. For the time being, you can verify that Team Explorer has been installed successfully by bring up the about dialog box in Visual Studio Help. This should work for Visual Studio 2008 also.

In order to setup TFS, Click on Tools > Options > Source Control and then select TFS as the source Control Plugin as shown in the screen below:

After that go to the next item and then set your environment settings as shown below:

Now we need to connect to the TFS server. In order to do this click on Tools > Options > Connect to Team Foundation Server. This should bring up the dialog box shown below. Just enter your server name in the dialog box without the port number by clicking on the Servers button. By default TFS runs on port number 8080 but you don't need to enter that in the dialog box. The dialog box is smart enough to automatically add the default port for you. Once you have entered the server name then you should be able to use Team Explorer.

Now that you are connected to TFS, you should bring up Team Explorer by clicking View > Team Explorer. Also look at the Source Control Explorer window by clicking View > Other Windows > Source Control Explorer. The pending changes is another good window to look at which is also available through View > Other Windows > Pending Changes

Now we are ready to create a local folder on our computer at C:\Workspaces so that we can map our local folder to TFS Source Control. Just create this folder if you haven't already done so and create a team project in TFS server if you don't have one. Just give the team project the name Test. Create a folder called C:\Workspaces\Test on your computer and map it to TFS. You can do this by bringing up the source control explorer window and clicking on the Workspaces dropdown. By default, Visual Studio will give you a workspace with the name of your computer. I would just add your new folder in there by clicking the edit button.

Once you have your workspaces mapped. You are ready to begin using TFS Source Control.

TFS Planning - Part 3 - System Requirements

Introduction

After selecting the server architecture, the next step is to make decisions about the hardware and software configuration of the servers. There are numerous choices to be made during this selection process and the hardware and software choices affect each other so we have to be careful to select the right components so that they are compatible with each other. I have compiled a selection matrix to make it easy to try out all the various TFS setup possibilities before doing the actual install.

1 – Software Choices:

Here is the selection matrix for the software choices. I have highlighted the default choices that are recommend for a quick setup. The software selection will need to be made at the application and data tiers and if you are setting up a build server then you would have think about storage and other requirements as well.

2 – Hardware Choices:

Here is the selection matrix for the hardware choices. Make your selection based on the number of users that you have in your environment.

After reviewing the hardware and software matrix, we can mix and match and try different setup scenarios. I have tried different setup possibilities and in my opinion the best setup is a dual tier architecture and this is what it looks like:

Resources:

• TFS Choices Spreadsheet [Excel Format]

Navigation:

• Part 2
• Part 4

TFS Planning - Part 2 - TFS Topology Selection

Introduction

Before you begin deployment of your TFS server, you have to select a server topology. The topology you select will be based on the questions that were asked in the previous section. Please review the questions in the previous section and fill in the planning spreadsheet shown below.

TFS Planning Spreadsheet – Please complete before proceeding…

After filling the spreadsheet you will arrive at the topology. It will be one of the four topologies shown below.

1 - Single Server Installation:

2 - Moderate Installation:

3 - Complex Installation:

4 – WAN Installation:

Resources:

• TFS Planning Spreadsheet

Navigation:

• Part 1
• Part 3

TFS Planning - Part 1 - FAQ

Introduction

This guide will take you from planning for TFS to actually doing the installation. Since TFS is such a complicated product, it is better to plan for it before you begin your deployment and if you are going to be doing a migration from an existing TFS Server then the situation becomes even more complicated and it requires more planning.

This guide has been compiled after reading the TFS installation documentation and the TFS documentation that is available on MSDN. The resources and references for this guide are all available at the end of the document for further reading. This guide contains a lot of hands on issues that I experienced while setting up TFS Server. This is part 1 of the guide which is more focused on planning for deployment and talks less about the actual installation process. This guide does not cover Team Foundation Server Web Access ( TSWA ) which is a separate add on product.

Here are some questions you may want to ask yourself during the planning phase. These questions are in order of importance and the answers to some of the questions effects other questions.

Question 1:What version of TFS will you be installing?

There are two versions of TFS out there namely Team Foundation Server 2005 and Team Foundation Server 2008. There are beta versions for these products also but for the sake of simplicity we will only discuss actual releases.

Recommendation: It is better to install the latest version since that will have the most bug fixes and it will be most stable.

Question 2: How many projects i.e. team sites will you create?

This question is directly related to server sizing and capacity planning. The TFS server license has a max capacity of 500 projects and if you go over that capacity then you have to buy another license. Also it is not recommend by Microsoft to house more than 500 projects on a single TFS server since this will degrade server performance and greatly reduce server output and you should consider adding another server. If you have worked with TFS then you will know this for a fact that TFS server is slow. Even TFS Server 2008 with all its bug fixes and improvements requires a lot of processing power to run and it takes a while to load so it is better to create less projects.

Recommendation: Create team projects or team sites sparingly. These are valuable resources and you should not create a whole project just to house a few applications. Even Empty projects consume space also once a project has been created, it cannot be destroyed so it will always hang around consuming space on your server. Create projects after proper planning and after identifying the business owners, developers, subject matter experts, project administrators etc. This will save you a lot of re-work later.

Question 3: How many users will you have?

Again, this question is directly related to server sizing and capacity planning. Microsoft recommends that you use single server architecture if you have less than 400 users but if you have more than 400 users then it is recommended to setup a Dual Tier Architecture. It may seem like this question is not a very important question to ask but trust me, if you read MSDN documentation on TFS then you will notice that this is a very important factor for server planning. Even the TFS capacity planning document on codeplex mentions number of users as an important factor in determining the size of your TFS implementation.

Question 4: What does your current environment look like?

This is an important question to ask. If you are currently running TFS beta or the old TFS Server 2005 then you need to consider server migration as part of your deployment strategy and the down time that you will have to have during the migration. No matter what you do, do not try to do an in place migration even though you might be tempted to stick the CD into the TFS Server and then just perform an in place upgrade. It may look like that you will be done within a couple of hours and you won’t have to worry about this task any more but trust me things are a bit more complicated then they appear. TFS runs on top of numerous Microsoft products and technologies and everything has to be just right before you begin your migration.

The first step for the migration must involve backing up all your databases. If you do not do the backup then I am telling you this from experience that you will regret it later and you will risk losing months worth of work. An in place upgrade is not a good idea since you have to backup the SQL Reporting Services encryption key also and re-encrypt your TFS reporting data.

Recommendation: TFS runs on top of SQL Server Reporting Services, Windows SharePoint Services and the .NET Framework 3.5. So there are a lot of moving parts so it is better to evaluate your current environment and test your migration plan on a test server or a virtual machine before you do it on production. You will need to backup all your TFS databases and the SQL Server Reporting Services encryption key and restore everything onto the new TFS server. There is an MSDN article that describes this process in great detail.

Question 5: Will you be setting up TFS Build?

It is better to setup TFS Build in phase 2 since it is a separate process. TFS Build is installed from Team Foundation Server CD build directory. You just have to run the setup.exe file to install it. It is better to do this step after you have set up your TFS server and after you have finished migrating all your source code into TFS. Recommendation: Install Team Build / MSBuild for TFS later. Focus on server migration and planning first.

Question 6: Will you migrate your existing code to TFS?

TFS supports migration from Visual SourceSafe. There is a tool called VSSMigrate that you can run to migrate all your existing code from VSS to TFS. In order to do this you will have to install Visual SourceSafe 2005 on your server. Also you will have to create xml config files manually for this tool to use so that you tell it where to pickup the code from and where to put it into TFS. This tool does not have a GUI front end way of creating config files for now. You will have to create config files for your user list from VSS also. The rule of thumb is to migrate a VSS database as a TFS Project. If your VSS databases are too old then be careful about migrating them into TFS since the migration process will bring in all change control and version control history and make the TFS database size huge.

Recommendation: If change control history and version control history is important to you then you should consider migrating your code from VSS to TFS. I think it is better to just take a baseline snapshot of your final code and just upload that instead of using the VSSMigrate utility to upload all the versioning and history tracking information. I say this because the migration process will make TFS database sizes quite big.

Question 7: Which server architecture / physical architecture will you pick?

There are four server architectures to choose from namely Single Server Installation, Moderate Installation, Complex Installation and WAN Installation. We will go into more detail on this in Part 2 of this post.

Recommendation: It is better to go with single server installation in most cases.

Question 8: Do you want redundancy and high availability at the Application Tier?

If you want redundancy and high availability then you have to go with complex installation.

Recommendation: It is better to use a virtual server for your application tier and you can just backup this server and restore it if things go down.

Question 9: Do you want redundancy and high availability at the Data Tier?

If you want redundancy and high availability then you have to go with complex installation. There are three types of redundancy and high availability namely hot, warm and cold.

• In a cold stand by scenario you just have a SQL Server 2005 stand by server and in case your primary server goes down then you just restore all your data on to this stand by server and you will be up and running in 3 to 4 hours. The advantage is that you do not need to have a TFS license for cold stand by servers.
• In a warm stand by scenario the redundancy is achieved through database mirroring.
• In a hot stand by scenario the redundancy is achieved through clustered database servers.

Recommendation: It is better to have cold stand by data tier server so that you don’t have to pay for the additional TFS Server license.

Question 10: How will security be managed for the TFS projects?

For each TFS project that you create, you will need to have a Project Administrator which is going to be someone from the business side. This role is different from the TFS Server Admin role which will manage the configuration of all projects and adding project admins to the projects.

Recommendation: Setup four different types of user roles on the TFS Server. The roles are Reader, Contributor, Developer and Project Administrator.

Question 11: Do you have a backup strategy for your TFS environment?

It is good to have a backup strategy for your TFS server since TFS is made of 11 databases. There are two reporting services databases, two Windows Services databases and rest of the databases belong to TFS.

Recommendation: I recommend doing weekly backups at least.

Resources:

• TFS Planning Roadmap
• TFS Install Guide

Navigation:

• Part 2