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 EditionsMicrosoft 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. 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/. 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.
Click Here to Purchase this Book