Anatomy of Team Foundation Server






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 Tier

The 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 shows the general structure of a TFS application server.

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 shows these web service directories within IIS Manager.

2. Team Foundation Server web services.


Within each service directory, there are one or more web service endpoints. The list is provided in Figure.

Application Tier Web Services

Service Directory

Web Service(s)

Build Services

BuildController

BuildStore

Integration

PublishTestResultsBuildService

Core Services

EventService

AuthorizationService

CommonStructureService

GroupSecurityService

ProcessTemplate

ProjectMaintenance

Registration

ServerStatus

Warehouse

WarehouseController

Version Control

Administration

Integration

ProxyStatistics

Repository

Work Item Tracking

ClientService

ConfigurationSettingsService

ExternalServices

Integration

SyncEventsListener


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 Tier

The 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).

3. Team Foundation Server: data tier.


Physically, TFS stores its data across seven different databases:

  • An activity log database (TfsActivityLogging)

  • A build database (TfsBuild) that holds data related to system builds such as build steps and build quality indicators

  • An "integration" database (TfsIntegration) that stores core team project information, security settings, and event registrations

  • A version control database (TfsVersionControl)

  • A data warehouse database (TfsWarehouse) that serves as the analysis and reporting store

  • A work item database (TfsWorkItemTracking) that stores work items

  • A work item attachment database (TfsWorkItemTrackingAttachments) that has a single table, Attachments, that serves as a collection of pointers to the work item attachment files

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-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 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 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 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 decreasing level of privileges with respect to one another (see Figure).

4. Team Foundation Server security roles.


Project Administrators

Project 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.

Contributors

Contributors 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.

Readers

Readers 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 Groups

In 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. Figure shows how the MSF Agile and MSF CMMI roles map into the three project-level groups used by the Foundation Server security subsystem.

MSF Roles and TFS Security Groups

MSF Agile Roles

Role

Group

Architect

Contributor

Business Analyst

Contributor

Developer

Contributor

Project Manager

Project Administrator

Release Manager

Project Administrator

Tester

Contributor

MSF for CMMI Roles

Role

Group

Auditor

Contributor

Build Engineer

Project Administrator

Business Analyst

Contributor

Developer

Contributor

Development Manager

Project Administrator

Infrastructure Architect

Contributor

IPM Officer

Contributor

Lead Developer

Project Administrator

Product Manager

Contributor

Project Manager

Project Administrator

Release Manager

Project Administrator

Solution Architect

Contributor

Sponsor

Reader

Subject Matter Expert

Reader

Test Manager

Project Administrator

Tester

Contributor

User Education Architect

Contributor

User Experience Specialist

Contributor




 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows