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: Navigation:
No comments:
Post a Comment