Anatomy of Team Foundation Server
| As discussed in Chapter 17, "Team Collaboration and Visual Studio Team System," Team Foundation Server (TFS) serves as the core collaboration hub for the Visual Studio Team System. It is TFS that enables source control, work item tracking, project alerts, reporting, and a host of other collaboration features. 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 parts of TFS are referred to as the application tier and the data tier. These tiers are logical and physically may map onto one or more servers. Some organizations may deploy both of these tiers onto a single server, whereas others might deploy the application tier into a web farm and the data tier onto several SQL Server installations. 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 consult closely before determining the best infrastructure arrangement. The Application TierThe application tier is composed of a set of web services (running under ASP .NET/Microsoft Internet Information Server) that provide source code control, work item tracking, reporting, and core TFS functionality. Figure 18.1 shows the general structure of a TFS application server. 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.
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 glimpse of web service functionality by simply calling the web service from your browser. This will give you a brief description of the service and a list of its supported methods. 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 name TfsServerScheduleris a generic service for scheduling a variety of TFS tasks. For example, the VSTS build system leverages this service to schedule builds. 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 TierThe data tier is essentially a SQL Server 2005 machine. It acts as the data repository for TFS and provides analysis and reporting services that are directly leveraged by Team Foundation Server (see Figure 18.3). 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. SecurityTeam Foundation Server uses the traditional and well-understood model of users and groups to implement security. Two broad categories of users need to be accommodated: server administrators and project members. Server administrators are responsible for the administration of all the TFS components from the web service configurations within IIS to the database setup under SQL Server. Project members are those users who comprise a project team. Although these broad categories may overlap, and certainly there is nothing preventing someone from sharing server administration responsibilities with project management responsibilities, they are served by different groups within a default Team Foundation Server install. Global Security GroupsGlobal 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 group contains the user population that is allowed to access the resources of a Team Foundation Server. Team Foundation Valid Users are further broken down at the project level by the project security groups. Project Security GroupsFor 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 decreasing level of privileges with respect to one another (see Figure 18.4). 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.
|
EAN: 2147483647
Pages: 195