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).
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 user interface 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.
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 his 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.
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, 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.
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.
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.
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.
Currently there are two versions of
TeamBuild, each version matched to a TFS installation version. It is also
highly customizable.
TFSBuild.proj is the file which
drives a TeamBuild. The Team Build Language is synonymous with the msbuild language.
References
·
Team Foundation Server: At Work
·
Visual Studio 2005 Team System: Enterprise-Class Source
Control
·
Using Source Code Control in Team Foundation
·
Team Foundation Server Fundamentals: A Look at the
Capabilities and Architecture
·
Visual Studio Team System 2008 Web Access
See also
External links