Team Foundation Server

From Wikipedia, the free encyclopedia

Team Foundation Server (commonly abbreviated TFS) is a Microsoft offering for source control, data collection, reporting, and project tracking, and is intended for collaborative software development projects. It is available either as stand-alone software, or as the server side back end platform for Visual Studio Team System (VSTS).

Contents

[edit] Architecture

Team Foundation Server 3-tier architecture
Team Foundation Server 3-tier architecture

Team Foundation Server works in a three-tier architecture: the client tier, the application tier and the data tier. The client tier is used for creating and managing projects and accessing the items that are stored and managed for a project. TFS does not include any UI for this tier, rather it exposes web services which client applications can use to integrate TFS functionality with themselves. These web services are used by applications like Visual Studio Team System to use TFS as data storage back end or dedicated TFS management applications like the included Team Foundation Client. The web services are in the application layer. The application layer also includes a web portal and a document repository facilitated by Windows SharePoint Services. The web portal, called the Team Project Portal, acts as the central point of communication for projects managed by TFS. The document repository is used for both project items and the revisions tracked, as well as for aggregated data and generated reports. The data layer, essentially a SQL Server 2005 Standard Edition installation, provides the persistent data storage services for the document repository. The data tier and application tier can exist on different physical or virtual servers as well, provided they are running Windows Server 2003 or better. The data tier is not exposed to the client tier, only the application tier is.

Most activity in Team Foundation Server revolves around a "work item". Work items are a single unit of work which needs to be completed. In many respects they are similar to a "bug" item in bug tracking systems such as Bugzilla, in that a work item has fields to define Area, Iteration, Assignee, Reported By, a history, file attachments, and any number of other attributes. Work items themselves can be of several different types, such as a Bug, a Task, a Quality of Service Assessment, a Scenario, and so forth. The framework chosen for any given project in a Team Foundation Server defines what types of work items are available and what attributes each type of work item contains. These items are internally stored in XML format, and their schema can be customized to add other attributes to different items, or create new items on a per-project basis. Each work item has associated control policies which control who is allowed to access and/or change the items. It also includes notification and logging capabilities to log all the creation, access or change events (controlled by policies) and optionally notify certain users when certain events occur.

Any given Team Foundation Server contains one or more Team Projects, which consists of Visual Studio solutions, configuration files for Team Build and Team Load Test Agents, and a single SharePoint repository containing the pertinent documents for the project. A team project contains the user defined work items, source branches, and reports that are to be managed by TFS. TFS provides capabilities for managing these projects. When creating a project, a software development framework must be chosen, and cannot be changed afterwards. TFS includes several templates for the most common ones, including agile and formal methodologies. Choosing the framework populates the project with predefined items such as project roles and permissions, as well as other documents like project roadmap, document templates, and report definitions. These items can be then linked to work items as well. The status of certain elements of the project can be set to automatically update as work items are updated. TFS can integrate with Microsoft Excel for the creation and tracking of project items. The status of the items can be created and edited in Excel and the resulting spreadsheet document can be submitted to TFS, which will import the data into its project management feature. It can also integrate with Microsoft Project as the project management front end. The project items can also be exported as Excel documents for further analysis of the data.

TFS does not natively include a UI for performing these tasks. The capabilities are exposed via web services, which are then used by client applications like Visual Studio Team System IDE. However, TFS does include a Team Foundation Client (TFC) application which can be used to perform these tasks outside of the VSTS IDE. TFC also operates by invoking the same web services. TFS exposes a client API that can be used by client applications to access the functionality; the API itself manages proxies to communicate with the web services as well as client side caching to reduce latency. The WSDL descriptions of the web services are also provided, in case an application wants to directly call the web services. Visual Studio Team System Web Access, available as an add-on, also addresses this.

[edit] Source control

Team Foundation Server provides a source control repository, called Team Foundation Version Control (TFVC). Unlike Microsoft's previous source control offering, Visual SourceSafe (VSS), which relied on a file-based storage mechanism, Team Foundation source control stores all code, as well as a record of all changes and current check-outs in a SQL Server database. It supports features such as multiple simultaneous check-outs, conflict resolution, shelving and unshelving (shelving is a way to save a set of pending changes without committing them to source control, while still making them available to other users), branching and merging, and the ability to set security levels on any level of a source tree, alongside the most visible features of document versioning, locking, rollback, and atomic commits. The source control mechanism integrates with Team System's work items as well; when a check-in (termed "changeset") occurs, a developer can choose to have their code associated with one or more specific work items, to indicate that the check-in works towards solving specific issues. TFS administrators can enforce check-in policies that require Code Analysis requirements to have passed, as well as to enforce the association of check-ins with work items, or update the state of associated work items (like flagging a bug as "fixed" when checking in code that has the bug fixed). Individual versions of files can be assigned labels, and all files with the same label forms a release group. Unlike VSS, TFS source control repository does not support linking to an item from multiple places in the source folder structure, nor does it allow an item to be "pinned" (allow different references to the same file from different directories to point to different versions in a way that cannot be further edited).

TFVC supports branching at entire source code level as well as individual files and directory levels as well, with each branch being maintained individually. Multiple branches can be merged together, with the built in conflict resolution algorithm merging the changes between two branches of the same file where it can automatically reconcile the differences or flagging them for manual inspection if it cannot. Merge can be performed at "changeset" level as well, instead of the branch level. A successful merge is automatically checked out in the source control repository.

TFVC is not limited to source code only, but using the Windows SharePoint Services infrastructure it is built on, it provides a version-controlled library for other documents in the project as well, including project plans, requirements and feature analysis documents among others. All documents in the source controlled repository can be linked with any work item, and access to them can be controlled by defining access policies.

[edit] Reporting

Reporting is another major component of Team Foundation Server. Using the combined data for work items, changesets, and information provided by Team Build and results from Test Agents (described below), a variety of reports can be created. For example, the rate of code change over time, lists of bugs that don't have test cases, regressions on previously passing tests, and so on. The reports are built using SQL Server Reporting Services, and can be exported in several different formats, including Excel, XML, PDF, and TIFF. Reports can be accessed both through Visual Studio, as well as through the web portal.

TFS uses its logging framework for automated data collection as well. The logging infrastructure monitors and logs information regarding access and use of the work items and source code, which can then be used by the analysis services to find trends. TFS includes a warehouse adapter in the data tier, which caches data from the underlying normalized database in a form suitable for analytics - in fact tables and dimension tables. SQL Server Analysis Services are then used to analyze this data, and reports created. Reports can span multiple work items including bug trends, code churning, build trends amongst others. Other analysis applications can also use the data directly pulled off the web services.

[edit] Project portal

On a per-project basis, TFS also creates a SharePoint site for the project, which can be used to track the progress of the project as well as to explore the work items and source controlled documents in the project, which are presented via the document library. It can also be used to view the reports generated. As a communication medium, the users associated with each other can use it to communicate amongst each other. The comments can be linked to various items as well. For each project, depending on the project properties, TFS uses a predefined template that defines the appearance of the site. These templates can be customized by the TFS administrators.

[edit] Shared services

TFS provides a handful of services that can be used for integration with other applications like IDEs and Project Management Systems. The linking service allows loosely coupled relationships to be created between items, for example a bug item and the source code revision(s) it applies to. The security services allows creation of security groups from users, to which access rights are then assigned. The classification service allows definition of policies to automatically classify items based on a multitude of criteria and the eventing service allows any component to raise an event and a notification action assigned to the event. The notification can be either using feed syndication or e-mail, or invoking other web service.

[edit] Team build

Team Build is a build server included with Team Foundation Server that can be installed on almost any machine that can support Visual Studio. Machines configured with Team Build can be used by developers to do a complete build of the most recent versions of the software contained in source control. Records of every build, whether it succeeds or fails, are kept so that developers and build administrators can keep track of the progress of the project. If a build succeeds, it analyses what changes have been made to in source control since the last successful build, and updates any work items to indicate that progress has been made. For example, if a tester filed a bug work-item against build #15, and a developer checked in a change just prior to build #18 being created, then the bug work-item would be updated to state that the bug has been fixed. A tester can then confirm or deny that the bug has been resolved.

[edit] References

[edit] See also

[edit] External links

Languages