Microsoft Visual Studio 2005 Unleashed - page 127
Summary
Visual Studio Team System focuses on enabling all tracks of the SDLC, not just the development track. A holistic approach toward managing progress through the SDLC is key. VSTS extends the reach of Visual Studio from the developer to include other pivotal roles in the SDLC such as
In this chapter, you learned that VSTS is a set of different Visual Studio versions, each
In the following chapters, we will look at the individual tools associated with Visual Studio Team System and see how they can be utilized within the fabric of a development team. 
|
Chapter 18. Managing and Working with Team Projects
The
You can think of Team Foundation Server as the central collaborative hub in a Visual Studio Team System environment: Visual Studio provides role-specific tools for
|
Anatomy of Team Foundation Server
As discussed in Chapter 17, "Team Collaboration and Visual Studio Team System," Team Foundation Server (TFS) serves as the
You can best think of TFS as a suite of web services running over the top of a data store. Physically, this means that TFS functionality is surfaced through Windows IIS web services, with data storage, warehousing, analysis, and reporting services provided by SQL Server 2005. These two
Note
The decision on how to deploy TFS is largely driven by the infrastructure and needs specific to your organization. Team Foundation Server ships with a lengthy set of installation instructions that you should
The Application Tier
The application tier is
Figure 18.1. Team Foundation Server: application tier.
The web services on the application tier act as wrappers over the top of the TFS API, which provides the actual functionality delivered by TFS. These services are hosted in virtual directories under the root Team Foundation Server website. Figure 18.2 shows these web service directories within IIS Manager. Figure 18.2. Team Foundation Server web services.
Within each service directory, there are one or more web service endpoints. The list is provided in Table 18.1. Table 18.1. Application Tier Web Services
Tip
In general, you don't need to worry about the TFS web services. They function as the server's API, which is used by various TFS tools such as the Team Explorer. However, if you want to extend TFS functionality, the web services are a great place to start. Documentation on the TFS web services is spotty, but you can find some information on extending and integrating with TFS in the Visual Studio 2005 SDK (see http://msdn.microsoft.com/vstudio/extend/default.aspx). You can also get a small
In addition to these web services, a Windows service is also deployed and run on TFS application tier servers: the task scheduler service. The task scheduler servicewhich runs under the
Note Team Foundation Build is the server application designed to run and manage automated software builds. It relies on its own service, the Team Build Service, which runs independently from the task scheduler. The Team Build Service can be deployed onto the application tier server but doesn't have to be. It also can be deployed on a client or on a standalone server. The Data Tier
The data tier is
Figure 18.3. Team Foundation Server: data tier.
Physically, TFS stores its data across seven different databases:
Work item attachments are actually stored in the file system. It is important to note that the relationship between TFS and SQL Server is a close one: TFS relies on and requires SQL Server Analysis Services and SQL Server Reporting Services to complete its various reporting requirements. Security
Team Foundation Server uses the traditional and well-
Global Security Groups
Global security groups are the high-level, universal groups that broadly organize users into administrator or user-level permission sets: The Team Foundation Administrators group has full rights to all pieces of the TFS deployment, and the Team Foundation Valid Users
Team Foundation Valid Users are further broken down at the project level by the project security groups. Project Security Groups
For each individual project, TFS defines permissions and access levels by classifying users into three different groups: project administrators, contributors, and readers. Each of these groups has a
Figure 18.4. Team Foundation Server security roles.
Project AdministratorsProject administrators have permission to manage individual projects en masse. They control content in the project portal sites, determine team membership, set security parameters, and have full control over a project's work items. ContributorsContributors represent the bulk of the team members; they are the individuals responsible for executing the project and therefore are imbued with permissions to add, edit, and delete work items in a given project, and can view information published on the project portal site. ReadersReaders are individuals who have a vested interest in looking at project artifacts but don't contribute principally to the project. As the group name implies, they have only view permissions and will primarily interact with project data through the project portal site. Mapping Roles to GroupsIn Chapter 17, we covered two of the project process models that are supported. TFS uses process templates to describe how to physically implement a particular process using the components of TFS and Visual Studio Team System. We cover process templates in more depth in the following section; they are important to mention here because security is one area covered by a process template. It effectively takes the roles defined by the process and maps them into the security groups that TFS cares about. Table 18.2 shows how the MSF Agile and MSF CMMI roles map into the three project-level groups used by the Foundation Server security subsystem. Table 18.2. MSF Roles and TFS Security Groups
|
