Azure DevOps Server
 | This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. (October 2011) |
| Developer(s) | Microsoft |
|---|---|
| Operating system | Microsoft Windows |
| Type | Revision control |
| License | Microsoft EULA |
| Website | azure |
Team Foundation Server (commonly abbreviated to TFS) is a Microsoft product offering source control, data collection, reporting, and project tracking, and is intended for collaborative software development projects.[1] 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 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 an 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 later. 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". A work item is a single unit of work which needs to be completed. In many respects it is similar to a "bug" item in bug tracking systems such as Bugzilla, in that it 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.
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.
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 the invocation of another web service.
Team Build
Team Build is a build server application included with Team Foundation Server, which is installed alongside Visual Studio. Developers use Team Build to perform complete builds of the most recent versions of 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 analyzes what changes have been made 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.
Team Foundation Server Express
Microsoft released a free version of TFS in beta that can be used by five or less people. It was released along with Visual Studio 11 Beta on February 29, 2012.
See also
- List of revision control software
- Comparison of revision control software
- Comparison of issue tracking systems
- Microsoft Visual SourceSafe
- SVNBridge a client or server side extension to TFS that allows access to TFS revision controlled items from Subversion client applications.
References
- ^ "Overview of Visual Studio Team Foundation Server 2010". Microsoft. 2010. Retrieved 2011-10-17.
External links
- 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
- Visual Studio Application Lifecycle Management
Years, where available, indicate the date of first stable release. Systems with names in italics are no longer maintained or have planned end-of-life dates. | ||||||
| Local only |
|  | ||||
| Client–server |
| |||||
| Distributed |
| |||||
| Concepts | ||||||
