Team Foundation Server Fundamentals: A Look at the Capabilities and Architecture

  • Article

 

Dennis Minium
Program Manager, Visual Studio Team System

January 2006

Applies to:
   Microsoft Team Foundation Server

Summary: Introduces the deployment topology, feature set, and extensibility architecture of Microsoft Team Foundation Server, which optimizes the process of developing software in teams. (7 printed pages)

Contents

What Is Team Foundation Server?
The Shape of Team Foundation
Elements of Team Foundation Server
Architected for Extensibility
Conclusion

What Is Team Foundation Server?

Microsoft has been in the business of creating sophisticated software for a long time. Large teams crank out and maintain complex code bases over multiple releases continuously. To be successful at producing software, we have had to develop effective approaches for version control, defect and work item tracking, and build management.

At the same time, we have spent considerable time with customers and industry experts to understand the broad spectrum of project management approaches employed by enterprise customers on a regular basis. With the help of the Microsoft Solutions Framework team, we have distilled the essence of these techniques into a set of flexible project management elements.

We have now combined the results of our experience and investigation in software creation and methodologies to produce a set of new technologies and techniques that are geared toward optimizing the process of developing software in teams. The result of this effort is Microsoft Team Foundation Server.

There are two sides to Team Foundation Server. On one hand, it is a collection of features that are shared by the various members of a project team to enable them to work together more effectively. Team members can share project plans, work products, and progress assessments easily and naturally.

The following major features are included in Team Foundation Server:

  • Version control, for managing source code and other deliverables that require versioning.
  • Work item tracking, for keeping track of such things as defects, requirements, tasks, and scenarios.
  • Project management functions, which allow the shaping of a team project based on a user-specifiable software process, and which enable planning and tracking using Microsoft Excel and Microsoft Project.
  • Team build, for enabling a common process for building executable products.
  • Data collection and reporting, which aid in the assessment of a team project's state, based on information gleaned from Team Foundation Server tools.
  • The Team Project Portal, which provides a central point of communication for a team project packaged as a Microsoft Windows SharePoint Services site.
  • Team Foundation Shared Services, which provide a number of common infrastructure services that invisible to end users but that are important to toolsmiths and extenders.

On the other hand, Team Foundation Server is a platform specifically architected for integration and extensibility. Customers and partners can customize elements of Team Foundation Server and complement it with new functionality. Extensions can range from the very simple to the very complex. They can range from renaming a field in a work item, to integrating an entirely new tool.

We will cover the feature set and extensibility architecture later in the article. First, though, it is important to understand the general deployment topology of Team Foundation Server.

The Shape of Team Foundation

Team Foundation is a three-tiered architecture comprised of a client tier, an application tier, and a data tier. Clients interact with the application tier through Web services, and the application tier connects to persistent data stores on the data tier by using database connections. An overview of the architecture appears in Figure 1.

ms364062.teamfoundfundamentals01(en-US,VS.80).gif

Figure 1. Architecture of Team Foundation Server

Much of the Team Foundation Server user interface is offered through the Microsoft Visual Studio IDE. This portion of the UI is implemented with the same VSIP interfaces that our customers and partners use. In addition, functionality is exposed on the client through Office applications—specifically Microsoft Word and Microsoft Project. There are some Web elements as well—most notably, the team project portal and the report server.

A simplified UI has been created for project managers and other non-developers for whom the Visual Studio IDE might be a complex and daunting environment. The Team Foundation Client (TFC) provides access to features that project members outside the technical staff will want to use, but without the clutter of language tools, debuggers, and developer utilities. This includes creating and monitoring project progress, controlling policies, and tracking work items. Developers and testers who need both the language tools and access to Team Foundation can also easily augment their full-function IDE with the capabilities of the TFC.

Whether a client application is written to run under the Visual Studio IDE or as a stand-alone Windows application, it communicates with the Web services on the application tier through an object model and a set of APIs that act as rich proxies. These mechanisms greatly simplify programming against the native Web services layer, and provide intelligent caching to minimize server round trips. In fact, because a great deal of functionality—including validation, caching, and cross-tool interaction—is embedded in the client APIs, it is strongly recommended that toolsmiths and extenders stick to using them and that they avoid coding directly against the Web services APIs. Even so, all APIs are public, including the direct Web services APIs, for which full Web Service Description Language (WSDL) is provided.

The server portion of Team Foundation Server consists of an application tier and a data tier. Both require the Microsoft Windows 2003 Server operating system. These tiers really represent logical divisions of functionality to enable scalability. As it happens, though, the functions of the application tier and data tier can be collocated on a single machine for smaller installations.

The application tier is where the majority of the work of Team Foundation Server is done: this is where each tool's Web services are exposed. The architecture of Team Foundation does not allow direct access to data stored on the data tier from client applications. All requests for data must be made through the application tier. Furthermore, all communication between components on the application tier is made through Web services.

In addition to each tool's Web services, the application tier hosts the Windows SharePoint Services (WSS) site for the project portal. This site fronts the WSS data store in which project documents are stored. Finally, the SQL Reporting Services Web site is hosted on the application tier.

All persistent data is stored on the data tier. This includes the operational stores of all Microsoft Visual Studio Team System tools, including the version control store, work item database, test results database maintained by the developer and tester tools, and team build database. In addition to these working production stores, the data tier hosts a hybrid relational and OLAP data warehouse that is used for project analytics and reporting. The preponderance of data in the data tier is stored in SQL Server databases. Team Foundation Server requires Microsoft SQL Server 2005, at a minimum.

In addition to the components that fit directly into the three-tiered architecture, Team Build allows for the introduction of dedicated build machines. Builds are initiated from a client, execute on the build machine, and send results into a results store on the data tier through a Team Build Web service on the application tier.

Elements of Team Foundation Server

As mentioned at the beginning of this article, Team Foundation Server includes several major features. Here we will explore them further.

Project Management

Using work item tracking and the Microsoft Office suite, along with information stored and analyzed in the reporting warehouse, users have the tools they need in order to be able to monitor a project's progress and health. Additionally, with Team Foundation's process template mechanism, they can tune the project process to their environment. A process template defines a set of instructions for setting up a new project, including such items as work item types, project roles and permissions, a set of pre-populated tasks to act as a project roadmap, document templates, and report definitions. Default process templates for the Microsoft Solutions Framework's Agile and Formal processes are installed with Team Foundation Server. These templates can be modified and extended, and new templates can be created, to enable customers to tailor the development process to their needs.

By the way, the concept of "team project" is very different from a Visual Studio language project. A team project involves a server-based, shared assortment of work items, source branches, reports, and documents, whereas a Visual Studio language project is typically a collection of data that is required to produce an executable or a .dll. The contents of a team project can be viewed through the Team Explorer.

Version Control

Team Foundation Server includes an industrial-strength version control system that targets enterprise source control requirements. Underpinned by SQL Server, this feature has been built from the ground up to offer reliable, secure, high-speed access to versioned data. Team Foundation has standard version control mechanisms for check-in, check-out, version management, and diff/merge. It also includes novel features such as shelving (the ability to store partial changes without performing a fully validated check-in) and dynamic check-in policies to address specific issues of large-scale development.

Work Item Tracking

Team Foundation Server's work item tracking system is used to store and assess bugs, requirements, scenarios, tasks, and any other sort of work item you choose to monitor. Work item types are stored as XML, so out-of-the-box work item types can be easily extended and modified with additional field types and rules. Additionally, whole new work item types can be created on a project-by-project basis.

Users can view and modify work items directly in the Visual Studio IDE. The work item tracking system is also integrated with Microsoft Excel and Microsoft Project, to enable viewing and editing of work items using familiar Office products.

Team Build

Team build provides a simple way to produce public builds. It augments the MSBuild engine with Team System-specific tasks such as automated testing, determining code churn, and updating work items. While team build interacts with clients through a Web service on the application tier, it also supports a separate "build server" on which builds and tests execute. The build server logs status and results to the team build store on the data tier. This data is subsequently pulled into the warehouse for analysis and reporting.

Data Collection and Reporting

Data persisted by Team Foundation Server tools is stored in SQL Server databases on the data tier. Each tool includes a warehouse adapter that pulls data from its normalized operational tables, and into a data warehouse used for analytics and reporting. This data warehouse is an SQL Server database organized by a star-like schema into fact tables and dimension tables. SQL Server Analysis Services cubes are built over these tables to allow easy aggregation, slicing, and dicing. Standard reports against the warehouse built using SQL Server Reporting Services are included in Team Foundation Server. These include a variety of reports that cut across tools and projects: bug trends, test coverage, code churn, and so on. Customers can also use Microsoft Excel and third-party reporting packages to produce custom reports.

The Project Portal

When a team project is created using the Project Creation Wizard, a Windows SharePoint Services site is instantiated on the application tier. The site acts as a portal for the team project. By default, the site's home page shows a set of project health reports. Its document library is prepopulated with user-modifiable document templates and sample files. The site can be customized individually for each project. An organization can redesign the templates used to create the project site.

Shared Services

The Team Foundation Server architecture rests on a set of shared services that are designed to simplify extensibility. The tools use these shared services to integrate. Customers and partners can also use them to make their tools behave as first-class citizens in the Team Foundation environment. These services are explored more fully in the following section.

Architected for Extensibility

Each tool offered in Team Foundation Server is highly customizable and automatable. Work item definitions, source control policies, build scripts, process templates, and programmability interfaces all enable customers to tailor their Team Foundation installation to their needs. In addition, at the core of Team Foundation Server is a set of mechanisms intended to enable outside tools to integrate into the Team Foundation Server environment as first-class citizens.

These shared Team Foundation Server integration services are depicted as blue boxes in Figure 2. The green boxes represent the elements a tool builder can provide to leverage the Team Foundation Server architecture. The orange boxes show the tooling included in Team Foundation Server.

ms364062.teamfoundfundamentals02(en-US,VS.80).gif

Figure 2. Integrating with Team Foundation Server

Team Foundation's shared services include the following:

  • The linking service enables tools to establish loosely coupled relationships ("links") between the data elements they hold. For example, in Team Foundation Server, the relationship between a defect work item and the source code that was changed to fix the defect is held as this sort of link. To participate, a tool must implement methods that expose their data as Team Foundation "artifacts" and respond to queries against them. By using this facility, a tool can participate in a relationship that it was not initially designed to recognize.
  • The security service supports Team Foundation Server-specific security groups, which can be used to collect Windows identities for permission assignment. These groups, which are local to a Team Foundation Server, can be administered without the help of the IT department. When a new tool is introduced to Team Foundation Server, it should respect these groups by using the group security service API. The security service also provides authorization services. Tools that do not offer their own authorization mechanism have the option to use the security service to secure objects and establish permissions.
  • The eventing service is a Web service-based pub/sub mechanism. As you would expect, tools can raise events to the eventing service. Subscribers can register to receive notification when an event matches their subscription criteria. A notification recipient can either be a Web service or an e-mail address. When it is a Web service, the subscription includes the URL of a Web service to be called when a notification is to be delivered. When it is an e-mail address, a notification can be delivered by e-mail, through an SMTP server.
  • The classification service works in coordination with the linking service to enable classification of Team Foundation Server artifacts according to predefined taxonomies. This enables tools in which the artifacts do not share a common "natural" taxonomy to organize their data in such a way that cross-tool reporting along common axes is possible. For instance, if work items are naturally organized by team, and tests are naturally organized by component, tests can additionally be organized by team, in order to enable them to be reported alongside work items.
  • When a new tool is introduced to Team Foundation Server, its artifact types, link types, event schemas, and service interfaces are registered through the registration service. Clients of the new tool discover its location by querying the registration service.

In addition to these shared services, customers and partners can take advantage of a variety of additional plug points to fully integrate a tool into Team Foundation Server. The following are from the green boxes in Figure 2:

  • For a consistent client experience, use VSIP to integrate the UI into the IDE. Alternatively, you can build a stand-alone Microsoft .NET application that accesses the application tier using the intelligent proxy layer.
  • Add creation of your tool's artifacts to the Team Project Creation Wizard (and, by implication, the process template that drives it).
  • Make your tool and its data visible as nodes on the Visual Studio Team Explorer.
  • Use the warehouse dynamic schema modification facilities to extend the warehouse with your tool's data. Then, build a warehouse adapter to pull your tool's operational data into the warehouse structures.

Conclusion

This tour has barely scratched the surface of Team Foundation Server capabilities and architecture. Additional information about Team Foundation Server can be found on MSDN, at https://msdn.microsoft.com/vstudio/teamsystem.

 

About the author

Dennis Minium is a lead program manager for Visual Studio Team System. He is responsible for defining and designing the integration architecture for VSTS. Dennis's principal focus is to ensure that the Team Foundation Server software on which VSTS is built is a rich and friendly environment for extension and customization by partners and customers alike. Prior to joining the VSTS team, Dennis worked on application development tools of various types at Microsoft. His career before Microsoft focused on the creation of tools and methods for enterprise application development.

© Microsoft Corporation. All rights reserved.