Planning a Deployment

Installing and deploying a product such as Visual Studio 2005 Team System involves a lot of preplanning and forethought. You must take into consideration variables such as capacity, scale, and the underlying infrastructure.

Some of the key questions you have to ask include whether you'll need one or two Team Foundation Servers (which will depend on the scale of your team). Will you need a proxy server? (In other words, will you support geographically distributed teams?) Do you need more than one build server? If so, where will they be installed? Do you need to create load tests with more than 1,000 simulated users? If so, a test rig may be required. The following section provides a more in-depth look at these variables and how they may affect your implementation of Team System.

Unsupported deployment scenarios

According to Microsoft, the following Enterprise scenarios are not supported on Team Foundation Server:

• Application tier network load balancing and clustering — in other words, you can't cluster Team Foundation Server

• Dividing Web services from the application tier on several servers

• Running several instances of Team Foundation Server on the same box

Capacity planning

The best way to look at capacity planning is by thinking about and looking at scenarios. First, you will look at the performance and scope of a deployment. Next, you will look at deployment on a small and then larger scale.

Performance and scope

Team System was designed to work with a single Team Foundation Server at the core. Microsoft is currently investigating scenarios where multiple Team Foundation Servers are used to scale up to larger- sized teams. However, please note that the product does not currently support clustering and mirroring. (This is, however, supported on the SQL Server 2005 data tier.) The responsiveness of Team System will depend greatly on the amount of memory you have in your server machine. The more memory that you can add in, the better its response will be.

In planning your deployment, you must consider whether you will use a one- or two-Team Foundation Server configuration. Questions you might ask yourself include: How many users will you support? Are Proxy Servers required (for distributed support)? Will you support clusters of remote users? Where on your network is your build server? Do you need a Test Rig (a collection of load test agents and controllers), and how many test users will you simulate? Finally, another question you may want to ask is whether you will integrate with Active Directory.

Small to medium deployments

You have two fundamental scenarios to consider for small to medium deployments. First, we define a small to medium deployment as 1 to 500 users. The first scenario is a single machine to a single user install. The second scenario is a multi-server install for teams of 2 to 500 users.

A one-user scenario may include a customer evaluating a demo version of the product, a consultant giving a presentation on Team System, or even a small learning environment to help a group of users experiment with the product. The one-user version of Team System is usually installed on a single machine and may contain demo or evaluation versions of the product (rather than the full retail version). The single-machine install contains all the components of Team System, including the client tier (CT), build engine, data tier (DT), and application tier (AT).

The second scenario in small to medium deployments is the 2 to 500 user scenario. In this scenario, Team System is installed on a single server and deployed to a small team. Since there are multiple users, the client tier (in other words, Visual Studio) is installed on machines other than the application and data tiers. This enables multiple users to access a single instance of the server. You can also optionally install Team Foundation Build on a separate machine or even on the client's desktop. This deployment model is configured to support workgroups or Active Directory.

Enterprise deployment

There is a single scenario to consider is the very large team of 500 to 2,000 developers, testers, and architects. A large infrastructure requires larger capacity, security, manageability, and support for geographically distributed software teams. Team System supports a large team by dividing up the tiers on different machines. To support such a large number of users, you must use Active Directory. (Otherwise, from an operational perspective, managing the users and the shifting needs will require a lot of overhead from the standpoint of day to day administration.)

Note

At the time of writing, Microsoft is internally deploying Team System as a tool to manage ambitious development projects such as Windows or Office. In fact, the Team Foundation Proxy was designed to effectively tackle latency challenges with remote teams.

For updates regarding how Team System can scale for larger teams, we highly recommend you look at Brian Harry's blog at http://www.blogs.msdn.com/bharry/.

User accounts

Three accounts are required to run and administer Team Foundation Server, as described in Table 24-1.

Table 24-1

User Name	Description
TFSSETUP	This account is used to log on to the different computers and run the installation applications.
TFSSERVICE	This account is used to run the different services that make up the Team Foundation Server. It is also used for different application pools related to Team Foundation Server.
TFSREPORTS	This account is used to access the data sources using SQL Server Reporting Services.

The user names listed in the preceding table are sample names. You can use any name you would like. This book will use these names in discussing the installation and configuration of Team Foundation Server. The TFSSETUP account must be in the local Administrators group on each Team Foundation Server machine. The TFSSERVICE and TFSREPORTS accounts should not be in the local Administrators group.

In a multi-server installation, all machines must be a member of an Active Directory domain. The user accounts defined in the previous table must be members of that Active Directory domain.

In a single-server installation, the user accounts can either be members of an Active Directory domain or local user accounts on the machine. Also, for a single server installation, you can use the same account for the Team Foundation Server Setup and the Team Foundation Server Service account. The Reporting Services Account must still be a separate account.

Firewall configuration

Table 24-2 contains a list of the ports used by Team System's data and application tiers. These ports should be opened in any intervening firewalls to enable communication in multi-server installs. Please note that firewall ports don't need to be opened on a single-server install.

Table 24-2

Port	Protocol	Reason
80	TCP	Application Tier
1433, 1434	TCP	SQL Server
2382, 2383	TCP	Analysis Services

Network topologies

Depending on your target environment, the network topology may present a special set of challenges. The following sections describe common deployment models which you may encounter.

Single-server deployment (workgroup configuration)

A single-server deployment is the simplest configuration option you can pick. It is advised if you want to deploy Team System for testing purposes or for very small teams. Typically, the single-server deployment is set up using a workgroup configuration (although it is possible to set it up on a domain).

Note

The MSDN Subscriber Download site includes virtual machine images of a single-server deployment, which makes it very handy for you to test and evaluate Team System in a lab-like environment. You can deploy these virtual machines using either Microsoft VirtualPC or Microsoft Virtual Server.

Please note that the workgroup version of the Team System installation process has a couple of notable limitations. One of the limitations is that the domain users can't log in to the server (see the following section, "Multi-server Deployment," for details). Also, your passwords and user accounts must be synchronized with Team Foundation Server. Otherwise, users cannot log in to the server. Figure 24-3 shows a standard single-server configuration setup.

Figure 24-3

Multi-server deployment

If you are planning to divide the tiers on separate machines, please note that you should set up your servers on a domain. For your components to access the domain, it is extremely important for you to set up your TFSSETUP, TFSREPORTS, and TFSERVICE accounts using domain accounts. Otherwise, TFSSERVICE will be unable to effectively interoperate and authenticate with the domain controller. Figure 24-4 shows a multi-server deployment and the different configuration options you have at your disposal.

Figure 24-4

Architecting your Active Directory (AD) structure

If you are working within a large infrastructure, Active Directory will be a given for managing your users on Team Foundation Server. Why would you want to use AD over the workgroup configuration, you may ask? First of all, from a convenience perspective you can implement single sign-on. Active Directory has security features that will help prevent scenarios such as unwanted clients or servers running on your network. And, most important of all, is manageability. In Workgroup mode, you have to manually add all users and groups to the server — if you have hundreds of users, this can be a pain from an administrative standpoint, because all changes made to the external network will have to be replicated locally on TFS. For example, if a developer decides to leave a company running Team System, the administrator will not only have to remove that user's privileges from the network, but also on the server.

Team Foundation Server supports Active Directory 2000 and Active Directory 2003. (Windows NT is not supported.) Team Foundation Server will interact with AD 2000 in Native mode — Mixed mode is not supported. Team Foundation Server also supports one-way trusts, full trusts, explicit trusts, and cross-forest trusts.

Team Foundation Server does not support a configuration of the Application and Data tiers on separate domains (or subdomains). You can't mix domains and workgroups either — they have to be on the same domain. Finally, make sure that your network isn't using Windows NT 4.0 Domain Controllers.

Test deployment using virtualization

You can test your deployment using a variety of tools, including Microsoft Virtual PC and Microsoft Virtual Server. There are many advantages to do so, especially in a test environment:

• Virtual images created from one product are compatible with the other.

• No need to re-install Team Foundation Server. The virtual image can be redeployed to a production server quite easily.

• You can create a base installation of Team Foundation Server, which would enable you to restore the server to a pristine state rather than try to clean up the projects.

Almost all the features of Team System work within a virtual environment, with the exception of profiling. The profiler will not work correctly in a virtualized environment because of virtual driver limitations. Think of it, the profiler uses the core system as a baseline to execute the tests — if the core environment is virtualized; it is difficult if not impossible to get accurate performance readings.

Note

Andy Leonard documented a way to configure a virtual domain controller with Team Foundation Server. You can read the details on his Web site at http://www.vsteamsystemcentral.com/dnn/.

Creating a test plan

Before you install Team System, you must consider who will be running the tests and the approach that should be taken to implement them. If you are running a large project, you may require additional build and test rigs to support the extra load. Testing can be done manually or as part of a build. You should think about what best practices you want to put into place to create an environment that fosters Test Driven Development (TDD).

All tests will run seamlessly as part of a build with the exception of Manual Tests. As a best practice, you should create dedicated test runs of manual tests. The two reasons are that it will make the tests easier to administer and will not impede the run of automated tests.

You should also take a look at all the tests available in Team System to see which ones you can leverage. Frequent testing will improve the quality of your code and, as a result, improve productivity.

Test rig considerations

If you try to run a load test with more than a few users within Visual Studio 2005, you'll notice that Visual Studio may become unresponsive, or you may experience performance problems at the outset. If you want to run capacity and performance tests, it is best to use a remote test rig (consisting of a test load agent and controller) to run the tests without affecting the overall operating environment.

Using the test runs that you can configure by using Team Edition for Software Testers, you can use a test controller to manage several load agents situated on several machines. By distributing the load, you can most effectively test your applications without loss of productivity. It goes without saying that the larger the project, the more test rigs will be required. Now to take a look at the individual components. Figure 24-5 shows a typical test rig and controller configuration and how it interplays with Team Foundation Server.

Figure 24-5