Understanding Team Foundation Server logical architecture
Understanding Team Foundation Server physical architecture
Taking a look at deployment scenarios
Upgrading Team Foundation Server
As discussed in Chapter 17, Visual Studio Team Foundation Server 2010 contains a variety of features you can use to manage your software development projects. From working item tracking to version control to reporting, Team Foundation Server provides all the tools needed to make software projects successful.
Team Foundation Server is based on a modern, service-oriented, three-tier architecture comprised of a client, an application tier, and a data tier. The application tier is facilitated by an ASP.NET Web server hosted in an IIS6 or IIS7 environment. The data tier is supported by SQL 2008. The architecture of Team Foundation Server is optimized around the following basic assumptions:
A high-bandwidth connection exists between the application and data tier.
The application-tier and data-tier servers can co-exist on the same side of a switch, which limits the impact their traffic has on the overall network.
Clients may talk to the application tier beyond the switch in possibly remote locations.
A combination of low-bandwidth and high-bandwidth connections exists between the clients and the application tier.
The general architecture of Team Foundation Server stayed relatively constant between Team Foundation Server 2005 and Team Foundation Server 2008. However, all applications need to evolve, and this is exactly what has happened with the most recent release. Team Foundation Server has undergone some significant architectural changes, designed to help ease and strengthen the management of team projects.
This chapter examines some of the enhancements and changes to the Team Foundation Server architecture. The discussion begins by looking at the old logical architecture of Team Foundation Server 2008, and contrasting it with the new logical architecture of Visual Studio Team Foundation Server 2010. After that, the chapter examines the physical architecture, and the new hardware and software requirements. Some of the different deployment scenarios for Team Foundation Server are considered, and the chapter wraps up with a brief overview of the two main clients used to access Team Foundation Server.
When talking about Team Foundation Server, both the physical architecture and the logical architecture must be considered. It is easier to start with the logical architecture, because there are multiple ways to configure the physical architecture, as will be shown later in this chapter. The logical architecture of Visual Studio Team Foundation Server 2010 has changed significantly from previous versions.
First, let's briefly cover the logical architecture of Team Foundation Server 2008. This will provide a basis for understanding some of the changes in Visual Studio Team Foundation Server 2010.
Figure 18-1 shows the logical architecture of Team Foundation Server 2008.
Team Foundation Server is a Web application consisting of multiple Web services running on the application tier. These Web services drive all the functionality of Team Foundation Server. You have the capability to create your own applications to run against these Web services (for example, creating your own application to access the work item tracking system or the version control system). But that is not advised.
Instead, you should make use of the Team Foundation Server Object Model. This object model is an application programming interface (API) into Team Foundation Server. While the Web services can and will change from one version of Team Foundation Server to the next, the object model will always remain similar or will at least degrade gracefully. You can be fairly confident that if an application is built against the Team Foundation Server Object Model, it will easily port to new versions of Team Foundation Server with minimal changes. The same cannot be said for applications written directly against the Team Foundation Server Web services.
The application tier is where most of the work in Team Foundation Server starts. That is where all the processing for accessing the work item tracking and version control systems happens, as well as monitoring and tracking of build and report information.
On the data tier, Team Foundation formerly used SQL Server 2005 or 2008. The data tier is composed of multiple relational databases and a data warehouse. Team project information is stored in the relational databases, and, at scheduled intervals, the information from the relational databases is pulled into the data warehouse. Having all the data from Team Foundation Server reside in SQL Server made backup and restore of the Team Foundation Server as easy as running a nightly backup of the database server.
However, the architecture of Team Foundation Server 2008 was not without its problems. There was no good way to group team projects into a kind of organizational structure. The only possible option for that was to have a separate Team Foundation Server for every group you wanted to collect. This was not feasible from an expense or a maintainability viewpoint. There was no way to restore a particular team project in the event of a catastrophe with that team project. You could restore the entire Team Foundation Server database to a point in time, but that would affect all the team projects on that server. Again, this was not the best solution.
Since the data tier was just SQL Server, you were able to use database clustering and mirroring for maintaining uptime on the data tier. However, there was no equivalent option on the application tier. The closest option available was the ability to have a warm standby Team Foundation Server. If the main application tier suddenly went down, you could turn on the standby server, run some configuration commands, and within few minutes have a new application tier up and running.
There were no options for network load balancing against the application tier. And finally, the application tier was still a 32-bit application. While 64-bit SQL Server 2005 and 2008 were supported, the application tier itself could only be installed on a 32-bit version of the operating system.
While all of these issues may not have been completely addressed, a majority of them have been taken into account in the new architecture of Visual Studio Team Foundation Server 2010.
Now, let's look at the new logical architecture of Visual Studio Team Foundation Server 2010, as shown in Figure 18-2.
The new logical architecture still uses all the old concepts (such as having an application tier and a data tier), but some of the concepts (especially relating to the application tier) have changed significantly. The best way to understand all the changes is to break them down into individual pieces. Let's start with the changes to team projects and work our way out.
As discussed in Chapter 17, in Visual Studio Team Foundation Server 2010, the concept of a team project remains relatively unchanged. The team project is still the "bucket" where all the stuff related to your project (work items, source code, reports, and so on) is stored. In Team Foundation Server, team projects have become lighter-weight, easier to organize, and easier to manage. All of this is facilitated through the concept of team project collections.
A team project collection, at its core, is simply a way to group team projects together. By grouping team projects together, it's easier to take advantage of certain features across team projects, such as branching and merging, and atomic check-ins. In effect, a team project collection is similar to an instance of Team Foundation Server 2008 — that is, a container of different team projects. Where with Team Foundation Server 2008 you would have to spin up a separate server to create a new collection of team projects, with Visual Studio Team Foundation Server 2010, all that is needed to create a separate group is to create a new team project collection. The concept is very similar to SharePoint Site Collections and SharePoint Sites (for those familiar with SharePoint architectures).
Team project collections provide a nice isolation mechanism for keeping team projects separated. For example, let's assume there are two teams: Team A and Team B. Team A and Team B both develop widgets, and they have a team project for each widget they create. They want to host all these team projects on Team Foundation Server, but want to isolate each group's team projects.
To do so, they would create a team project collection for each team. Team A would connect to their team project collection, which contains only the team projects for Team A. Team B would connect to their team project collection, which contains only the team projects for Team B. Work items and version control changesets for Team B would all be numbered sequentially for that project collection. Changes made to the projects in Team A's project collection would have no impact on the Team B users.
On the database server, each team project collection is housed in its own database. This makes the team project collection a manageable unit for administration. For this reason, it is important that all the team projects in a team project collection be tightly coupled, because many operations will be performed at the team project collection level, not the team project level. Backup, restore, and move operations are carried out at the team project collection level, and are not available at the team project level. A single team project cannot be restored from a database backup. However, the capability to restore individual team project collections now minimizes the impact that a database restore will have on the rest of the team project in a Team Foundation Server, because only the team projects in the team project collection being restored will be affected.
As mentioned earlier, team project collections are very similar to an instance of Team Foundation Server 2008. As such, they have some of the same limitations:
No branching, merging, or sharing of code between team project collections
No backup or restore of individual team projects in a team project collection
No atomic operations (such as check-ins) can happen across team project collections
Some serious thought should go into how to organize your team projects in collections before you begin with Team Foundation Server. Before creating a new team project, consider all the artifacts that will be part of the project, and the purpose of the team project, to see if it belongs in the current team project collection, or if a new collection should be created.
Note
For more information, see the Scaling Team Foundation Server 2010 whitepaper at http://go.microsoft.com/?linkid=9707136.
A single Team Foundation Server can support many team project collections (hundreds or thousands, depending on physical resources available, such as database disk space). However, the number of "active" team project collections available on the server is less, in the order of 150-200 active collections per SQL instance. Note that as you can host project collections on different SQL instance you can increase this for a Team Foundation Server instance. For example, if you have your project collections split across 3 SQL instances, then you could get up to 600 active team project collections.
When a user connects to a project collection that is not active, Team Foundation Server will spin up all the resources and database connections necessary to connect the application tier to that project collections database. Those resources will continue to be occupied until there are no connections to that project collection for a given period of time (usually around 5 minutes). After that time, the project collection will go dormant, and the application-tier resources will be freed up. This means that project collections are an excellent way of handling projects that get archived.
At some point, even the best thought-out plans must be changed. With some work, it is possible to move a team project into a new project collection. But it is not possible to merge two team project collections, or move team projects from one collection into an existing one.
The introduction of the Team Foundation Server Farm is another big architectural change in the 2010 release. In the past, you were able to share the load of the Team Foundation Server application across an application-tier machine, database server, SharePoint server, reporting services server, and so on. However, you could only have a single machine that was the application tier, which had obvious downsides for ensuring availability of the Team Foundation Server application.
With Team Foundation Server 2010, you can configure multiple Team Foundation Server application-tier machines to service the same set of team project collections, and those application tiers can sit behind a network load-balancing device to not only share the load of in inbound requests, but also to allow for a better availability story. Any one of the application-tier machines can fail, and the farm will continue to operate without significant user interruption. This also improves the capability when performing such tasks as operating system patches, which can be done in a standard rolling manner (that is, take an application-tier machine offline, patch, and then return back into the pool).
In addition to the application-tier scale out support, now each project collection may point to a different SQL Server instance when storing its data. Because each project collections database is independent, SQL Server administrators have a great degree of flexibility in how they wish to manage their SQL resources. A single project collection may be easily suspended while its database is moved to a different SQL instance without affecting the other project collections. This gives SQL administrators the capability to manage capacity, retire old servers, and so on.
The Team Foundation Server application is an ASP.NET Web application running on the Team Foundation Server application tier. Its main purpose is to perform operations on the team project collections. The Team Foundation Server application uses the Configuration Database (more on this later) to store its configuration information and information about which team project collections the Team Foundation Server application is responsible for.
On each application tier, there is one configuration server instance running, and all application-tier state is stored in the databases. Each Team Foundation Server application can host multiple team project collections. A request can come for one of the multiple team project collections and be handled by any one of the application instances in a Team Foundation Server Farm.
Having the configuration server instance manage all the services for one or more team project collections allows for centralized administration to be built directly into the framework. This allows for many new options not available in previous version of Team Foundation Server, including the following:
The capability to start, stop, and pause a Team Foundation Server application or team project collection
Capability to move project collections between application tiers
Earlier in this section, the Configuration Database was mentioned. The Configuration Database is a SQL Server database containing the configuration information about the Team Foundation Server application and the collections managed by it. Examples of the information stored in the Configuration Database include the following:
The team project collection map
SQL Server access information
Logging data
The main benefit of the Configuration Database is that it allows administrators to make global changes to the Team Foundation Server application, and apply those changes to all the team project collections managed by the Team Foundation Server application. That way, the administrator does not have to touch each individual team project and team project collection in order to make changes.
The Configuration Server has a set of public APIs for interacting with it.
Note
For more information see the MSDN help on the Microsoft.TeamFoundation.Client namespace (http://msdn.microsoft.com/en-us/library/microsoft.teamfoundation.client.aspx) under the class TfsConfigurationServer. Note that this class was called TeamFoundationApplicationInstance in early beta versions of Team Foundation Server 2010, in case you find any old examples still referring to that name.
Thus far, you have learned about some of the specific new features and changes for both the application tier and the data tier. Now, let's step back and define the concept of what actually is a Team Foundation Server instance.
At its most basic form, a Team Foundation Server instance is a Team Foundation Server application tier (or multiple applications in a Team Foundation Server Farm) that handles requests for sets of team project collections. The SQL Server databases that contain the data associated with these team project collections are also part of the Team Foundation Server instance. A Team Foundation Server instance can be made up of one or more physical servers. Ancillary servers (such as the SharePoint portal or Reporting Services servers) are also often considered to make up the Team Foundation Server instance, despite their being somewhat separate.
Most users will need only one Team Foundation Server instance, but there are times when multiple instances may be needed. For example, an enterprise organization may have an IT organization that is split by division. Each division might want its own Team Foundation Server instance in order to have separate operations, management, and security policies.
Because of the new improvements in load balancing and scalability in Team Foundation Server 2010, along with the introduction of team project collections, the decision whether to have multiple Team Foundation Server instances is usually a financial one in larger enterprises. Say that Department A paid for all the servers and so on, and, therefore, Department B may not use "their" instance. Because Team Foundation Server offers a level of scalability and requires very little management overhead, there has been a significant movement inside IT-focused organizations for Team Foundation Server resources to be managed by a central IT organization (much like the Exchange email services) with centralized billing of that capability. This also ensures that the Team Foundation Server instance is treated with the same importance as any other production system.
You have multiple options when configuring your Team Foundation Server deployments. You can deploy all the components (Team Foundation Server application, SQL Server, Reporting Services, and Windows SharePoint Services) onto one machine. This is called a single-server installation and should work fine for a total number of users of 450 or less. In general, single-server installations are the easiest installations.
For more than 450 users, a multi-server installation should be considered. There are several flavors of multi-server installations. At its most basic, there are two servers. One server is the data tier, running SQL Server, and the other is the application tier, running Team Foundation Server, Reporting Services, and Windows SharePoint Services.
Your organization may have an existing SharePoint Portal Server, and/or SQL Server Reporting Services Server that it wants to use in conjunction with Team Foundation Server. For that scenario, you would then have a physical server for running Team Foundation Server Web Services, a physical server for running the SQL Server databases, and separate servers for running SharePoint Portal Server and Reporting Services.
For high-availability scenarios, clustering of machines is available at each point in the architecture. As previously discussed, the Team Foundation Server application-tier machines can be located behind a network load-balancing device. The SQL Server instances referred to by the Team Foundation Server application and project collections can also be clustered.
Table 18-1 shows the hardware requirements for a single-server installation, where the application tier and data tier reside on the same physical machine. However, keep in mind that these numbers are estimates, and, obviously, the more hardware you can throw at a problem, the better.
Table 18.1. Hardware Requirements for Single-Server Installation
NUMBER OF USERS | CPU | HARD DISK | MEMORY |
|---|---|---|---|
Less than 20 users | One 2.2 GHz processor | 8 GB | 1 GB |
20 to 250 users | One 3.6 GHz processor | 230 GB | 2 GB |
250 to 450 users | Two 2.9 GHz processors | 500 GB | 4 GB |
For a multi-server installation (where you have distinct physical servers for the application tier and the data tier), Table 18-2 lists the application-tier hardware requirements.
Table 18-3 lists the data-tier hardware requirements.
Table 18.3. Data-Tier Hardware Requirements
NUMBER OF USERS | CPU | HARD DISK | MEMORY |
|---|---|---|---|
450 to 2,200 users | Four 2.6 GHz processors | Dual Drives or Drive Array; 480 GB and 3.75 TB | 8 GB |
2,200 to 3,600 users | Eight 2.6 GHz processors | Dual Drives or Drive Array; 480 GB and 3.75 TB | 16 GB |
Keep in mind that the application tier may be hosting Windows SharePoint Services and/or SQL Server Reporting Services, in addition to Team Foundation Server. This might require you to bump your hardware numbers in some form or fashion.
Virtualization is a hot topic these days. Virtualization allows you to buy a large server, and then virtually host several different servers on one physical machine, allowing an organization to make the most of a physical machine's resources. There are some pieces of the Team Foundation Server environment that can be safely hosted in a virtual environment, and some that should never be virtualized.
Ideally, the following pieces should be installed on physical servers:
SQL Server 2008 Database Engine
SQL Server Reporting Services
SQL Server Analysis Services
SQL Server is the foundation for holding all the information regarding Team Foundation Server. Should it become corrupted, the entire Team Foundation Server system will go down. To minimize the chances of database corruption, you should avoid hosting SQL Server 2008 in a virtualized environment.
The following can be safely installed in a virtualized environment with minimum to no impact on the Team Foundation Server system:
Team Foundation Server application tier
Windows SharePoint Services
Team Foundation Build servers
Visual Studio Team Foundation Server 2010 can be installed on the following operating systems:
Windows Server 2003 Datacenter Edition with Service Pack 2
Windows Server 2003 Enterprise Edition with Service Pack 2
Windows Server 2003 Standard Edition with Service Pack 2
Windows Server 2003 R2 Datacenter Edition with Service Pack 2
Windows Server 2003 R2 Enterprise Edition with Service Pack 2
Windows Server 2003 R2 Standard Edition with Service Pack 2
Windows Server 2008 R2
Windows Vista
Windows 7
Visual Studio Team Foundation Server 2010 can be installed on both 32-bit and 64-bit versions of any of the listed operating systems. (Previous versions were only available on 32-bit operating systems, but this restriction has been removed in the 2010 release.) Keep in mind, however, that Team Foundation Server does not support Itanium-based systems.
Team Foundation Server requires SQL Server 2008. During the beta phase, there was a lot of debate over whether to make Visual Studio 2010 Team Foundation Server backward compatible with SQL Server 2005, but, in the end, the capability to use many of the new features in SQL Server 2008 won out. The following editions of SQL Server 2008 are supported:
SQL Server 2008 Standard Edition
SQL Server 2008 Enterprise Edition
SQL Server 2008 Express Edition
If you are installing Team Foundation Server's databases onto an existing database server, ensure that the existing database server is configured correctly. Consult the Team Foundation Server Installation Guide (available online at http://msdn.microsoft.com) for more information on this.
Team Foundation Server optionally uses SharePoint products to create its team project portal. If you want the application tier to also host the portal site, then Windows SharePoint Services 3.0 can be installed on the application tier as part of the application install. If you want the portal site to be on a different server, there are two options:
Install Windows SharePoint Services 3.0 on a separate server.
Use Microsoft Office SharePoint Server, either an existing installation or a fresh install.
Again, consult the Team Foundation Server Installation Guide for more information.
Once the decision has been made to use Team Foundation Server 2010, the next step is to actually get it deployed and working in your organization. A good bit of planning must take place before the actual installation can occur:
What sort of installation will you need — single-server or multi-server?
Will you make use of existing servers and software (such as a pre-existing SQL Server 2008 server, or a pre-existing SharePoint Portal Server 2007 server)?
Will you attempt the installation yourself, or bring in a consultant who specializes in Visual Studio Team Foundation Server?
Will you use a vanilla, out-of-the-box installation of Team Foundation Server, or do you want to customize it to fit your specific needs?
The place to start preparing for your deployment is with the Team Foundation Server Installation Guide. This guide gives you in-depth, detailed information on how to plan and implement the installation of your Team Foundation Server. It is so detailed that it even provides step-by-step instructions for every step of the install, down to exactly what needs to be clicked on every screen of every installation program. The installation guide can be downloaded from the Microsoft Web site. Always ensure that you have the latest version of the Installation Guide, because it is updated from time to time to account for bug fixes and service packs.
If problems are encountered during the installation and deployment, one of the best resources to turn to is the MSDN forums (http://forums.microsoft.com/msdn). There are a specific set of forums dedicated to Visual Studio Application Lifecycle Management (ALM) topics and Team Foundation Server, and a specific discussion group for installation and deployment issues. The forums are constantly monitored by both members of the product team from Microsoft, as well as recognized experts in the field and other interested, knowledgeable people. The forums are your best source for quickly finding answers to any of your deployment problems.
Once Team Foundation Server is installed in your organization, a typical enterprise will need a quarter to half an administrator resource/operations person to handle any day-to-day operations related to Team Foundation Server. Some of these operations include initial configuration, backing up and restoring data, and handling security permissions. A good resource for your administrators is the Team Foundation Administrator Guide. This free reference, also available from the Microsoft Web site, is a treasure trove of information. It contains detailed information on all the scenarios discussed next, and more, including walkthroughs. It also covers administrative information related to all the different pieces of Team Foundation Server (such as SharePoint and SQL Server). As with the Installation Guide, check the Microsoft Web site to ensure that you have the latest version of the Administrator Guide.
There are five main scenarios to consider when planning a deployment of Team Foundation Server:
Individuals and small teams
Small companies
Large enterprises
Hosting organizations
Upgrading from a previous version of Team Foundation Server
Team Foundation Server now supports a basic installation mode. In this mode, no SharePoint portal or reporting services are set up for the server. In addition, a SQL Express-based data tier can be created by the installer itself, rather than using an existing SQL instance. Also, on more recent operating systems (such as Windows Vista, Windows 7, or Windows Server 2008), if IIS is not installed, then the installer can install it and configure the required prerequisites.
This, combined with the fact that Team Foundation Server can be installed on a client machine (such as a Windows 7 desktop) or a machine with other applications running on it (such as Small Business Server, or even Windows Home Server), means that Team Foundation Server is, more than ever, suitable for use by individual software developers or small teams. A basic install of Team Foundation Server using SQL Express can be backed up and restored to a "full" install of Team Foundation Server running against a standard full SQL Server-based database instance, and the portal and reporting systems configured. Therefore, the basic installation mode is a great way to get started with Team Foundation Server.
For smaller shops, with a total number of Team Foundation Server users of 450 or less, a single-server installation should be sufficient. All the components of Team Foundation Server can be installed on a single server. Figure 18-3 shows an example of the architecture for a small shop.
The small shop has one physical server. (For server specifications, see the earlier section in this chapter "Hardware Requirements.") The physical server contains only one Team Foundation Server instance. The application tier and the data tier are both installed on the same physical server. There is one application tier, containing one Team Foundation Server application. On the data tier, there is one Configuration Database. There can be one or more team project collections, with each team project collection maintaining up to 500 team projects.
Single-server installations (and, by extension, small shop deployments) are usually the easiest to perform, even for someone who has never installed Team Foundation Server before. All the different components of Team Foundation Server (including SharePoint and SQL Server) will be installed fresh on the target machine. Read the Team Foundation Server Installation Guide carefully, ensure that you follow the step-by-step instructions, and take your time. You should have minimal problems with the installation.
For a large number of Team Foundation Server users (450 or more), or for large enterprises in general, a multi-server installation will probably be required. The large enterprise scenario has the potential to be the most complex install, but also the most common for large enterprises. Figure 18-4 shows an example of the architecture for a large enterprise.
The large enterprise deployment is made up of multiple physical servers. This deployment includes one or more application-tier servers, each with its own Team Foundation Server application. Network load balancers can be used to balance the load across these multiple application tiers. There are multiple data tiers with multiple team project collections. These multiple data tiers can all reside on one physical SQL Server machine, or can be spread across multiple machines with project collections having their databases located on separate SQL instances. For high-availability requirements, those instances can be clustered, if required.
Large enterprises may already have servers running SQL Server 2008 and SharePoint, and may want to leverage their existing investment in those infrastructures. Team Foundation Server allows that to happen in a multi-server installation. Again, the Installation Guide is your best friend in this scenario, because it walks you through all the different combinations that would be available to large enterprises.
As well as adding data-tier machines into your environment, Team Foundation Server allows you to add additional Team Foundation Server application tiers to an existing deployment, allowing you to scale out capacity as needed.
One of the major goals of the architecture redesign of Team Foundation Server was to allow for Team Foundation Server to work in a hosted environment. With Team Foundation Server 2008, there was a large demand for running Team Foundation Server in a hosted environment — in effect, outsourcing the installation and maintenance.
Organizations wanted to use all the features provided by Team Foundation Server, but did not want the overhead of installing or administrating the physical machine. While this was possible with Team Foundation Server 2008, it was not easy to set up, and you had to jump through several hoops to make it work correctly. Following were some of the main issues:
No support for encapsulation or isolation for customers other than new server instances (making it expensive to host Team Foundation Server).
No central area for administration.
Creation of team projects is a client-side-driven operation, and requires server farm administration privileges in SharePoint, which creates some security issues when dealing with shared infrastructure.
Visual Studio Team Foundation Server 2010 was redesigned with hosting in mind. Figure 18-5 shows the architecture for a hosted scenario.
The goal of a hosted environment is to facilitate hardware sharing and, therefore, reduce the cost per transaction. This environment starts out with one instance, and has as many customers as possible sharing project collections and security settings for customer isolation. They begin by scaling out this instance by first using network load balancing of the application tier and multiple SQL Server instances for project collections. Then, if performance starts to degrade, that may expand out to multiple instances of Team Foundation Server.
Making it easier to install and configure Team Foundation Server in a hosted environment will contribute significantly to increasing its adoption in the application lifecycle management space. Not every company is currently ready to entrust their source code and work items into the cloud with a hosted solution. But hosting is particularly attractive to smaller companies, start-ups and non-IT-focused organizations that do not wish to invest the hardware infrastructure costs required in hosting themselves.
However, the same features that make hosting in the cloud possible also make it easier for large enterprises to centralize hosting of Team Foundation Server resources inside the company, allowing the organization to make dramatic cost savings in terms of development infrastructure at the same time as reducing the training and support requirements by having a common environment for all teams to use.
For customers who have existing installations of Team Foundation Server 2005 or 2008, the upgrade story is going to be of keen interest. The upgrade path in Team Foundation Server 2010 is a major upgrade requiring some reading up, planning, and practice — but one that is well-supported.
Note
The best place to find out more information is the Team Foundation Server 2010 Installation Guide, available on the Team Foundation Server installation media, or you may download a more up-to-date version from MSDN.
When you are upgrading you may wish to also consider the following:
Do you wish to take the opportunity to upgrade operating systems (that is, from Windows Server 2003 32-bit to the latest Windows Server 2008 R2 64-bit)?
You must upgrade to SQL Server 2008 for your data tier if you are currently running on a SQL Server 2005 database.
What additional tools do you use and what customizations have you made to Team Foundation Server?
Do you wish to change the architecture of your Team Foundation Server installation to take advantage of new features and scenarios available to you with Team Foundation Server 2010?
Have you made plenty of back-ups and have a suitable roll-back plan if the upgrade does not run smoothly?
There are two major paths available to you when upgrading to Visual Studio Team Foundation Server 2010:
In-place upgrade
Migration upgrade
An in-place upgrade is one in which you are using the same set of hardware with the same operating system version that is running the current Team Foundation Server instance. In this scenario, you basically uninstall the existing Team Foundation Server application from the application-tier machine, and install the new version, pointing it at the existing database data. This will enable you to run the upgrade wizard, which will take care of making all the database schema changes necessary.
For example, if you have a single-server installation, you would uninstall the Team Foundation Server application, upgrade to SQL Server 2008 (including Reporting Services and Analysis Services, if applicable), Upgrade to Windows SharePoint Services 3.0 SP1 or later, run the Team Foundation Server 2010 Setup, and select Upgrade from Previous Version.
A migration upgrade is one in which you are using a separate, duplicate set of hardware to perform the upgrade. In this scenario, you basically create a new set of servers with all the prerequisites installed (IIS, SQL Server, Windows SharePoint Services, and so on). You then copy the existing Team Foundation Server-related databases over to the new database server, install the Team Foundation Server application, and call the upgrade wizard.
For small Team Foundation Server installations that are well backed up, or for ones with a constrained budget for new hardware, then an in-place upgrade may well be the easiest solution. If your installation is pretty much a standard Team Foundation Server installation, then everything should work as planned. However, it would be recommended to test this first in a virtualized copy of your production system. You should also ensure that you have adequate back-ups and a tested roll-back plan in case the upgrade process does not go smoothly.
The migration path gives the greatest flexibility and allows you to do plenty of testing beforehand. It also gives you the opportunity to upgrade your server infrastructure to the latest versions available, and to a 64-bit environment, giving you plenty of room for growth in the future. The final benefit of the migration path is that the fall-back plan is very straightforward. Should anything go awry during the upgrade process, you can fall back to the existing hardware, and resume using the old Team Foundation Server installation.
Once you have performed the upgrade, there are a number of additional tasks that you may want to perform that are well documented in the Team Foundation Server Installation Guide. For example, you may want to update your process template to enable features introduced in the new process templates in 2010 (such as hierarchical work items and to enable the new test tools), and you may also want to convert some branch folders into fully fledge branches in Team Foundation Server version control.
This chapter has shown how the architecture of Visual Studio Team Foundation Server 2010 has changed significantly from its previous versions, but for the better. You learned about the original architecture of Team Foundation Server 2008, and some issues that arose from that architecture.
This chapter examined the new Team Foundation Server 2010 architecture, explaining new concepts such as team project collections and the configuration database.
You learned about the physical hardware required to install Team Foundation Server, as well as the software needed. The discussion touched upon the different deployment scenarios for Team Foundation Server, from small shops to large enterprises, and touched on the upgrade path from previous version of Team Foundation Server.
Chapter 19 takes a deeper look at the version control features available in Team Foundation Server, and what new functionality has been introduced in Team Foundation Server 2010.