Planning a Team System Deployment
It can’t be stated enough that planning is an essential part of any process. Without planning, you may unnecessarily complicate the deployment process or, worse yet, miscalculate what your needs are and have to reinstall the product. (As a consultant who has deployed Team System hundreds of times, I speak from experience.) Deployment does not necessarily mean just the installation of the product. Once Team System has been installed, you must configure it correctly. (For example, you must set up the proper permissions, change the process template to match the target environment, and handle other details including source code migration and extension or customization of tools to make them interact with Team Foundation Server). If you are a consultant, you’ll often get client requests to install Team System in, say, two days. Team Foundation Server takes at the very least a day to correctly install and configure in an enterprise environment. Working on a two-day engagement to deploy Team System is the equivalent of asking a home builder to build a house from scratch in two weeks! It’s best to set the proper expectations with your clients, work out a deployment plan, and work out realistic timeframes. In this chapter, you learn the major components of Team System and how to plan your deployment based on your capacity and needs. The final part of the chapter discusses strategies to help you migrate your existing tools and data to Team System.
Team Foundation Server Overview One of the big challenges of working on a software development team is getting all the members of the team to collaborate seamlessly. There are always so-called silos that are created for each role on a team. For example, developers like to live in Visual Studio and can easily relate to development talk and issues, whereas most project managers have no Visual Studio experience whatsoever; they are used to working with Excel spreadsheets working up use cases, scenarios, and project milestones. Architects map out application designs in Visio, testers use testing tools. The groups and roles are quite different. Trying to integrate it all is difficult and requires a lot of coordination—and frequently intercession—on the part of the project manager, who must set up status meetings and track deliveries from a number of sources. To successfully deploy Team System, you’ll need cooperation from the entire development team, and especially the operations team. Installing Team System involves setting up accounts in Active Directory, changing firewall port settings, prepping hardware, making sure the licensed software is available on DVD or on a network share, and so forth. Get the operations team involved early in the process and get them to read the Team Foundation Server installation guide (and quiz them on it). Both of these steps will make the deployment process a lot easier. Team System (and specifically Team Foundation Server) provides tooling and a framework to simplify collaboration between team members. The server allows you to communicate with anyone on your team using a number of tools including the Visual Studio editions, Microsoft Excel, Microsoft Project, and Team Explorer. All team members get access to a common set of services including a Team Portal, version control, build engine, and reporting. Everything is integrated in one location. All of this means that you need fewer status meetings, and you get more transparency and clarity with regards to the work being done within a project. Team System can be viewed as three logical tiers: the client tier, which includes the Team Editions of Visual Studio 2005; the application tier, in other words, Team Foundation Server; and the data tier (SQL Server 2005), which provides the data management and storage support behind the scenes. This very basic architecture can be seen in Figure 1-1. When you are planning a deployment, it is important to consider what deployment scenario will work best for your needs and what client/server configuration will give you the best bang for your buck in terms of management and configurability. Let’s start by looking at the essential parts that make up the client and server components of Team System.
Team System Overview Team Foundation Server plays a very important part in Team System. It is the collaborative suite that supports the entire software development life cycle (SDLC). Prior versions of Visual Studio supported developers only and everyone else had to rely on third-party products to achieve any kind of integration. The different tiers of Team System can be further broken down into its client and server components.
Client Components Here is a listing of Team System’s core client components. You can’t really talk about a server without discussing how the clients interact with the server (of course). Along with these clients, the Team Foundation Server API (also known as the Team Foundation Core Services) contains methods that allow you to programmatically connect to Team Foundation Server (and create your own custom clients).
Visual Studio 2005 Team Editions—Even though this is a book on Team Foundation Server, we would be remiss not to cover client features and how they integrate with Team Foundation Server. Refer to the individual editions below for details on the coverage level.
For software architects—Unfortunately, this book has little to no coverage of the architecture tools. If you are interested in Team Edition for Software Architects, we would like to refer you to Professional Visual Studio 2005 Team System (Wrox Press, ISBN: 0764584367).
For software developers—For developers, the book covers version control management (Chapter 12) and extensibility (Chapters 9 through 11).
For software testers—For testers, refer to Chapter 15 for information about the Team Test Load Agent. We also cover test case management to a limited degree in Chapter 13.
For database professionals—Chapter 8 is devoted to Team Edition for Database Professionals and how the data development lifecycle ties into the software development lifecycle.
Visual Studio 2005 Team Suite—Visual Studio 2005 Team Suite integrates the features of Team Edition for Software Architects, Team Edition for Software Developers, and Team Edition for Software Testers. Starting late 2006, Team Suite will also include Team Edition for Database Professionals.
Brian Harry has posted on his blog a Visio diagram outlining how Team System was deployed within Microsoft. Specifically, it maps out the overall topology of both server and components. You can download the Visio file at the following link: http://blogs.msdn.com/bharry/archive/2006/08/22/712746.aspx.
Team Explorer—Team Explorer ships on the Team Foundation Server media and provides connectivity between Visual Studio 2005 and Team Foundation Server. You can learn more details about Team Explorer in Chapter 2.
Third Party Tools—There are a number of third-party companies developing tools for Team Foundation Server. When appropriate, we have provided you with links to these complementary tools.
MSSCCI Provider (for Visual Studio 6.0 and 2003)—Many companies have made investments in .NET 1.0 and .NET 1.1, and need to support Visual Basic 6.0. The Microsoft Source Code Control Interface provider allows these IDEs to connect to Team Foundation Server.
Microsoft Office Excel 2003—Microsoft Excel is used as a project management tool within Team System. (A developer or any other team member can also use it to manage their work items.) You can learn how to make the most out of Excel in Chapter 13.
Microsoft Project 2003—Microsoft Project has special capabilities and limitations that are documented in Chapter 13.
Server Components
These server components provide the infrastructure backbone for Team System. In this book, we examine each one of these in detail:
Team Foundation Server—Team Foundation Server is comprised of a number of components and services. The installation of the product is covered in Chapter 2, you learn about backup and recovery strategies in Chapter 5, right up to retirement in Chapter 17.
Team Foundation Build—Team Foundation Build provides an automated, integrated build experience. You can learn a great deal more about Team Foundation Build in Chapter 3.
Team Test Load Agent—The Team Test Load Agent is composed of an Agent and Controller, which allows you to test Web applications against a profile of a thousand users or more. There is coverage of these tools in Chapter 15.
Team Foundation Server Proxy—Team Foundation Server Proxy is a tool that helps improve the performance of Team Foundation Version Control over HTTP. We cover the proxy in Chapter 15.
Team Foundation Core Services (TFCS)—Team Foundation Core Services is a set of services and APIs that allow you to extend Team Foundation Server. You can learn more about extensibility in Chapter 9.
Active Directory domain controller—If you are working within a big enterprise, Active Directory (AD) is essential for the management of your user’s roles and credentials. You’ll find deep coverage of AD in Chapters 2 and 4.
Mail server—Team Foundation Server has the ability to leverage a mail server to send out alerts to your team members. The alert and eventing infrastructure is covered in several chapters, most notably in Chapter 14.
Compiling Your Project Data
There is key data you should compile to plan a deployment. Otherwise, you may be unprepared for the installation and it may be unnecessarily complicated. Here are some of the data points you should collect:
Hardware infrastructure—This includes a full audit of all the target systems that will be used alongside Team System. This audit should be undertaken in consultation with your operations team. Equipment usually takes time to order, therefore you may want to consider dates—a nontrivial requirement because they will affect the dates in which you can start the deployment. Part of the hardware infrastructure review includes writing a maintenance plan, which includes backup/recovery, a maintenance task list for administrators to perform regularly, and so forth. Your operations team should be deeply involved in this process.
Software infrastructure—List all the software required for the deployment, and the software currently in place in your environment. The software check may reveal systems with incompatible software, in which case the operations team must upgrade the target systems before starting the deployment process. A close consultation with your operations team is key to obtaining a solid understanding of the target environment. Another element that can’t be understated is licensing. Do you have all the necessary licenses for Team System? A good place to start is look at the 1:1 correspondence between the software you need and licenses you need. After that, you will need to look at client access licenses (CALs) for those who will be accessing Team Foundation Server without a Team Edition.
Network infrastructure—Your network infrastructure may appear deceptively simple, but there are many things to consider including security settings, user account settings, topology challenges, and so forth. For example, if you have governance rules in place, your user accounts may have special restrictions such as password policies that will complicate a deployment. Another scenario is that ports may need to be opened on your network to allow Team Foundation Server communication to flow through. In order for the ports to be opened, a security audit might be required. It’s important to note not only the components that are required, but also the process behind those components.
Project documentation—Find all documents relating to your software development process and the documents supporting that process, including templates, lists, and so on. If some of these seem ad hoc, not to worry. Team System provides a solid mechanism for aggregating and publishing software project assets.
Build requirements—The complexity of your build may depend on many factors, including what type of software you are developing, if you are building a multiplatform or distributed solution, and so forth. The key information you will want to record includes what needs to be built, what you are expecting as a release at the end of the build process, and if any special tasks are required along the way (for example, automatically copying files via FTP to another server).
Source code—How much source code do you have? Where is it stored? What policies and procedures have you put in place to track versions and integrate source code? You must document all of this to decide how you will migrate the code and what approach to take to configure Team Foundation Version Control. Another thing you can do that can’t be understated is creating a checklist before deployment. Figure 1-2 shows the installation checklist available in the Visual Studio Team Foundation Installation Guide. It breaks down the installation steps for both single-server and dual-server deployments. You can create a personal checklist in Excel that reflects the software, hardware, and tasks you need to accomplish to successfully deploy Team System. Figure 1-3 shows an inventory of software, which you can check off as you obtain it. Once all the software has been checked off the list, for example, you know that you are ready for the deployment.
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! 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). 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. 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. 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.
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.
Click Here to Purchase this Book