Azure DevOps Server: Difference between revisions

Revision as of 15:26, 20 December 2007

Revision as of 02:58, 3 January 2008

Line 7:

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 system]]s 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 an 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 Office Excel|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 any UI for performing these tasks, rather the capabilities are exposed via [[web service]]s, which are then used by client applications like [[Visual Studio Team System]] [[Integrated Development Environment|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.

===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_%28software%29Branching (software)|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 and rollback. 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 what 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_%28software%29Branching (software)|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 souce 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.

Line 24:

===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 administatorsadministrators.

===Shared services===

Line 41:

==External links==

*[http://msdn2.microsoft.com/en-us/library/bb668991.aspx patterns & practices Team Development with Visual Studio Team Foundation Server] (MSDN)

*[http://www.amazon.com/Development-Visual-Studio-Foundation-Server/dp/0735625719 patterns & practices Team Development with Visual Studio Team Foundation Server] (Book)

*[http://msdn2.microsoft.com/en-us/library/bb671361.aspx patterns & practices Team System Videos] (MSDN)

*[http://www.codeplex.com/VSTSGuidance patterns & practices Visual Studio Team System Guidance] (Online KB)