Planning a Deployment

Installing and deploying a product such as Visual Studio 2005 Team System involves a lot of preplanning and forethought. You must consider variables such as capacity, scale, disaster recovery planning, backups, and the underlying infrastructure. There are several important sources you can refer to that will help in your deployment efforts:

• Existing infrastructure documentation - If your company had to write up a disaster recovery plan (which may have stemmed from the Year 2000 fiasco), then you are in a great position as all your software and assets have been catalogued.

• Visual Studio Team Foundation Planning Guide - Along with the Installation Guide (TFSInstall.chm) and Administration Guide (TFSAdmin.chm), the Planning Guide will provide you with hints on what to look at in the planning process. Unlike the other guides (which are also great tools to help you plan your deployment), the Planning Guide (TFSPlanning.chm) is not available on the Team Foundation Server CD or DVD.

• Microsoft Operations Framework (MOF) - The Microsoft Operations Framework provides guidance on the proper implementation of technology based on Microsoft's own internal experience and practices derived from the IT Infrastructure Library (ITIL). You can learn more about MOF at microsoft.com/technet/itsolutions/cits/mo/mof/

• Governance documents - Your company may need to follow strict or specific rules for legal reasons. You need to consider these governance rules and practices when planning your deployment.

Some of the key questions you have to ask include whether you'll need one or two Team Foundation Servers (depending 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 a thousand simulated users? If so, a test rig may be required. Here is a more in-depth look at these variables and how they may affect your implementation of Team System.

Capacity Planning

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

Performance and Scope

Team System was designed to work with a single Team Foundation Server instance at the core. Microsoft is currently investigating scenarios where multiple Team Foundation Servers instances are used to scale up to larger sized teams. However, note that Team Foundation Server does not currently support clustering and mirroring. (However, this is supported on the SQL Server 2005 data tier, which is really the key area because all project assets are stored in the database.) Team Foundation Server supports a warm standby scenario, if an issue should occur. For more information about availability within Team System, refer to "Ensuring Team Foundation Server Availability" on MSDN at http://msdn2.microsoft.com/en-us/library/ms253159.aspx. The Microsoft Operations Framework also has information about service management functions, including availability management, at http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfavamg.mspx.

The responsiveness of Team System depends greatly on the amount of memory you have in your Team Foundation Server and, most important, your SQL Server 2005 instance. The more memory and processor power you can add in, the better your user experience will be.

In planning your deployment, you must consider whether you will use Team Foundation Server for one or two configurations. Some of the questions you might be asking yourself include the following:

• How many users will you support?

• Are Proxy Servers required (for distributed version control support)?

• Will you support clusters of remote users?

• Where on your network is your build server?

• Do you need test rig and how many test users will you simulate?

• Will you integrate with Active Directory?

Small-to-Medium Deployments

There are two fundamental scenarios to consider for small-to-medium deployments: Let's first define a small-to-medium deployment as one to 2,000 users.

A one-user scenario may include a customer evaluating a demo version of the product, a consultant giving a presentation on Team System (perhaps through a single machine VirtualPC install), 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 of the product). 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 for two to 2,000 users. In this scenario, Team System is installed on a single server and deployed to a small team. Because there are multiple users, the client tier (in other words, Visual Studio) is installed on machines separate from those with the application tier and data tiers. This allows 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

The final scenario to consider is the very large team of more than 2,000+ developers, testers, and architects (assuming a dual-server install). To go beyond 2,000 users, you need to bump up the processor scale and performance along with memory on both the application and database tiers. A large infrastructure requires larger capacity, security, manageability, and support for geographically distributed software teams. Team System supports a large team by dividing the tiers on different machines. (Note that a single machine will not support anywhere near 2,000 users.) To support such a large number of users, you must use Active Directory 2000 or 2003. (Otherwise, from an operational perspective the management of the users and shifting needs will require more overhead than can be afforded.) Team Foundation Proxy allows distributed teams to access the source control portion of the product. You can optionally set up multiple build servers, multiple proxies, and, in some cases, multiple Team Foundation Server!

Important

At the time of writing, Microsoft is internally evaluating 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. The Prescriptive Architectural Guidance Group, as well as a number of other small organizations, is currently deploying Team Foundation Server.

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

Network Topologies

Depending on your target environment, the network topology may present a special set of challenges. Here are common deployment models that 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).

Important

We define a single server as a 2.2 GHz Pentium IV or Athlon, with 1 gigabyte (GB) of memory that will support a team of 50 or less. If you double the memory, support goes to 250. If you use dual-processor support on both machines with 4GB memory, support for 500 users is obtained. You may also wish to consider your build requirements, which may further determine the machine sizing.

The MSDN Subscriber Download site provides 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 (VPC) or Microsoft Virtual Server. VPC requires at least 1.5 gigabytes of memory for even modest usability. Two gigabytes is highly suggested.

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 login to the server. (See multiserver deployment for details.) Second, your passwords and user accounts must be synchronized with Team Foundation Server. Otherwise, users will not be able to log in to the server.

Dual-Server Deployment

If you are planning to divide the tiers on separate machines, note that you should set up your servers on a domain. In order 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.

Architecting Your Active Directory (AD) Structure

To set up and configure Team Foundation Server in dual-server deployment, you must use computers that are joined to an Active Directory domain. With the Workgroup edition, you have the choice whether you want to join it (or not). If you are working within a large infrastructure, Active Directory will be a given for managing your users on Team Foundation Server.

There are several reasons you would want to use Active Directory over the workgroup configuration. First, from a convenience perspective, you can implement single sign-on. Active Directory has security features that help prevent scenarios such as unwanted clients or servers running on your network. Second, 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 Team Foundation Server. For example, if a developer decides to leave a company running Team System, the administrator will have to remove privileges from not only the network, but also the server.

Team Foundation Server supports Active Directory 2000 and Active Directory 2003. (Windows NT is not supported.) Team Foundation Server will interact with Active Directory 2000 in native mode; mixed mode is not supported. Specifically, Team Foundation doesn't support NT4 and so does not support AD2000 mixed mode. It does support AD2003 mixed mode. Team Foundation Server also supports oneway 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 (VPC) and Microsoft Virtual Server. Virtual PCs are not just for testing. There is a trend to deploy VSTS on the workstation as a VPC. This makes it far easier for developers to get around IT-mandated machine configurations and is simpler to install. They can also be used for evaluation and training. Also, some organizations have adopted VPC on the Team Foundation Server side. Often this is used for evaluation, but also more and more for pilot efforts. There are many advantages to doing so, especially in a test environment:

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

• There is no need to reinstall 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 that allows 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 with 100-percent precision 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.

Important

After Visual Studio 2005 Beta 2, the profiler does work with VPC; however, the profiler under VPC does not go down to the bare metal as originally planned. The dev/test team removed the exception that detects whether you are on a virtual machine. It is now left up to the user to know what the profiler meaning is. For most users, this is quite fine, as they want only a relative view of their hot spots, not an absolute view.

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

Client Planning

Before attempting to install any software within a large-scale environment, it is quite important to plan your deployment. Microsoft itself is still learning how to effectively deploy Team Foundation Server. Because there are so many variables, it is impossible for us (or Microsoft) to provide absolute guidance in all deployment scenarios. However, we can provide best practices based on our personal experience and expertise.

Team Editions

Microsoft has designed three versions of Visual Studio 2005 to support three roles in your typical software development team: Team Edition for Software Developers, Team Edition for Software Testers, and Team Edition for Software Architects. Before you deploy these products, you have to determine which edition best fits your team members. If there is an overlap between responsibilities or tools, then you can install Team Suite.

Team Suite

Team Suite encompasses the functionality of all the other Team Editions. It is useful to install on Team Foundation Build to get the full range of testing capabilities. Project managers should definitely get a copy of the suite product to be able to view architecture, development, and test solutions across the entire project.

Team Explorer

In most development roles, you are required to connect to Team Foundation Server, be it to generate a work item, upload source code, or run a build. Each instance of Visual Studio that will be performing these tasks needs Team Explorer and an accompanying client access license (CAL).

A project manager who has never used Visual Studio can use Microsoft Excel or Project integration to connect to Team Foundation Server. Keep in mind that Team Explorer will have to be installed regardless on their systems - the Office plug-in gets installed as part of the Team Explorer install process - and the project manager's system will also require a CAL.

The only roles that don't require Team Explorer are the client and upper management. They can examine the project portals and reporting features; the only requirement is a browser. No client CALs are required to view content on the Reporting site or the Project Portal.

There are other Team Explorer–like client tools developed by third-party vendors for the Team Foundation Server; these include Teamplain (a Web interface to interact with the work item database) and Teamprise (a Team Explorer–like plug-in for Eclipse developers).

Security Planning

To correctly configure your security within Team Foundation Server, you have to put some thought into what users and roles you will define within your development environment. You must consider several layers of security:

• Network security (enforced by Active Directory)

• Operating System security on the machine hosting Team Foundation Server

• Security within Team Foundation Server

• Security on a project level

Roles (as defined by the Microsoft Solutions Framework) play a main part in determining security settings. Would you want any developer on your team to create or delete projects on the fly? Probably not. Applying proper least-privileged user account (LUA) principles to your access controls is the best approach. In a nutshell, LUA advocates providing users with just enough privileges to do their job - no more, no less.

Where should you start? The first thing you can do is look at your current Active Directory user and group configuration. If possible, map and define groups within Active Directory that correspond to the roles defined by Team System. For example, architect, developer, tester, and project manager.

To save administrative headaches, you can map these groups to the groups within Team Foundation Server by adding the domain groups as part of the server groups. This will simplify the task of adding users in Active Directory and will provide a single point of contact for all user administration.

Here is a practical example: let's say a tester is promoted to be a test lead (which entails project management tasks). You can simply change the user in Active Directory from the tester group to the project management group. As a result, the permissions will trickle down to Team Foundation Server and the new test lead will gain more control over server functionality.

In a workgroup install, you must manually make changes on both the target operating system and within Team Foundation Server. As this is more administrative overhead, consider using the workgroup installation only if you manage a small number of users.

Refer to Chapter 4 for detailed information about configuring and administering security within Team Foundation Server.

Creating a Test Plan

Before you install Team System, you must consider who will be implementing tests, and how tests will be implemented. 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 look at all the tests available in Team System to see which ones you can leverage. Frequent testing improves the quality of your code and, as a result, improves productivity. Chapter 13 has some coverage on how to implement test case management.

Test Rig Considerations

If you try to run a load test with more than a few users within Visual Studio 2005, 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 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. Let's now look at the individual components. The Team Test Load Agent is discussed in detail in Chapter 15.