Jump to content

Azure DevOps Server

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Soumyasch (talk | contribs) at 09:33, 19 June 2007 (forked off from VSTS, content moved, adaptation going on). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

The server-side component is Team Foundation Server (commonly abbreviated TFS), which comprises two components: The application tier and the data tier. The application tier is a set of web services that provide access to TFS functionality, and a web portal and document repository facilitated by Windows SharePoint Services, whereas the data tier is essentially a Microsoft SQL Server 2005 Standard installation that warehouses all the information for TFS. Both tiers are required, but can be installed on the same or separate servers.

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. When creating a project, a software development framework must be chosen, and cannot be changed afterwards.

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 Requirement, 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.

Team Foundation Server provides a source control repository. Unlike Microsoft's previous source control offering, Visual SourceSafe, 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.), branching and merging, and the ability to set security levels on any level of a source tree. 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.

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.

Team Build is a build server included with Team Foundation Server that can be installed on most 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 bits contained in source control. Visual Studio's Code Analysis, Test Tools and Code Coverage can be enabled to further validate a build before it is deemed to be "good". Whether a build succeeds or fails, a record of every build is 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.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Azure_DevOps_Server&oldid=139166804"