Azure Devops

Azure DevOps Server, formerly known as Team Foundation Server (TFS) and Visual Studio Team System (VSTS), is a Microsoft product that provides version control (either with Team Foundation Version Control (TFVC) or Git), reporting, requirements management, project management (for both agile software development and waterfall teams), automated builds, testing and release management capabilities. It covers the entire application lifecycle and enables DevOps capabilities.[2] Azure DevOps can be used as a back-end to numerous integrated development environments (IDEs) but is tailored for Microsoft Visual Studio and Eclipse on all platforms.[3]

On-premises vs. online[edit]

Azure DevOps is available in two different forms: on-premises ("Server") and online ("Services").[4] The latter form is called Azure DevOps Services (formerly Visual Studio Online before it was renamed to Visual Studio Team Services in 2015). The cloud service is backed by the Microsoft Azure cloud platform. It uses the same code as the on-premises version of Azure DevOps, with minor modifications, and implements the most recent features. A user signs in using a Microsoft account to set up an environment, creating projects and adding team members. New features developed in short development cycles are added to the cloud version first. These features migrate to the on-premises version as updates, at approximately three-month intervals.[5]

Architecture[edit]

Server architecture[edit]

Azure DevOps is built on multi-tier, scalable architecture. The primary structure consists of an application tier responsible for processing logic and maintaining the web application portal (referred to as Team Web Access or TWA). Azure DevOps is built using Windows Communication Foundation web services. These may be consumed by any client, although the client object model is recommended. The data tier and application tier can exist on the same machine.

To support scalability, the application tier can be load balanced and the data tier can be clustered. If using Microsoft SQL Server 2012 or later, AlwaysOn SQL Server Failover Clusters and Availability Groups are supported which allows for geographic replication of data.[6] The primary container is the project collection. A project collection is a database that contains a group of Team Projects. The Project Collection is another scalability mechanism, in that each collection can be placed on different SQL Servers or SQL Server instances. 'Oe' configuration database per Azure DevOps instance stores project collection metadata. Data from the project collection databases is aggregated into the warehouse database, which denormalizes the data in preparation for loading into an Analysis Services cube. The warehouse and the cube allow complex trend reporting and data analysis.

Azure DevOps can integrate with an existing SharePoint farm. SQL Server Reporting Services are supported for more advanced reporting against the data warehouse or the Analysis Services data cube. These installations can be on the same system or on different systems. Build servers, lab management servers, release management servers and proxy servers (to reduce some of the load on the application tier), test machines and load test machines can also be added to the infrastructure.[7] To support teams requiring enterprise project scheduling, Azure DevOps also integrates with Microsoft Project Server, which allows enterprise level portfolio management, resource management and project tracking.

Extensibility[edit]

Microsoft provides two standalone redistributed APIs for connecting to Azure DevOps. One is a Java SDK, the other is a .NET Framework SDK. These APIs allow for client connectivity to Azure DevOps. Because Azure DevOps is written on a service-oriented architecture, it can communicate with virtually any tool that can call a web service. Another extensible mechanism is subscribing to system alerts: for example, alerts that a work item was changed, or a build completed. There are approximately 20 preconfigured alerts, and teams can configure as many additional alerts as needed.[8] When used in an extensible scenario, these alerts can be sent to a web service, triggering actions to alter or update work items (such as implementing advanced business rules or generating work items programmatically based on a given scenario).

The data warehouse can also be extended through the creation of custom data warehouse adapters.[9] With the introduction of TFS 2012, custom add-ins can also be created for Team Web Access, called Web Access Extensions.