Azure DevOps Server
Azure DevOps Server
Main page
A

Azure DevOps Server

logo
Community Hub0 subscribers
Read side by side
Azure DevOps Server
View on Wikipedia
from Wikipedia
Azure DevOps Server
DeveloperMicrosoft
Release2005; 21 years ago (2005)
Stable release
Azure DevOps Server / October 7, 2025; 9 months ago (2025-10-07)[1]
Operating systemMicrosoft Windows
TypeApplication lifecycle management
LicenseTrialware
Websiteazure.microsoft.com/en-us/services/devops/server/ Edit this on Wikidata

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. To support scalability, the application tier can be load balanced and the data tier can be clustered.[6]

The primary container is the project collection. A project collection is a database that contains a group of Team Projects. 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.[7] To support teams requiring enterprise project scheduling, Azure DevOps also integrates with Microsoft Project Server.

Extensibility

[edit]

Microsoft provides two standalone redistributed APIs for connecting to Azure DevOps: a Java SDK and 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.[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]

Clients

[edit]

Azure DevOps supports Visual Studio 2010 and later, Microsoft Test Manager (MTM) 2012, and 2013. Eclipse, older versions of Visual Studio, and other environments can be plugged into Azure DevOps using the Microsoft Source Code Control Integration Provider.[10]

Microsoft Excel and Microsoft Project are also supported to help manage work items which allows for bulk update, bulk entry and bulk export of work items. Microsoft Project can be used to schedule work when conforming to a waterfall software development methodology. Both Excel and Project support bi-directional updates of data. This allows, for example, project managers to put a schedule in Project, have that work imported into Azure DevOps where developers update the work and then the schedule can be updated.

With Team Foundation Server 2012, Microsoft PowerPoint was also integrated with Azure DevOps to enable rapid storyboard development to help with the requirements management process. The integration provides extensible storyboard shapes that can be used to build any type of interface mockup that can then be animated with PowerPoint's built-in functions. These storyboards can then be linked to work items.

In an effort to handle the growing geographic dispersion of teams and to involve stakeholders earlier and more often in the process, Microsoft added the Feedback Client.[11] This tool allows users to exercise an application, annotate what they are seeing with audio and video, capture screens and provide contextual feedback to the development team.

Work items

[edit]

At the heart of Azure DevOps is the "work item", which can be work that needs to be accomplished, a risk to track, a test case, a bug, etc. Work items are defined through the XML documents and are highly extensible.[12] Work items are combined into a Process Template that contains these and other pieces of information to provide a development framework. Azure DevOps includes Process Templates for the Microsoft Solutions Framework for Agile, Scrum and CMMI.[13]

Work items can be linked to each other using different relationships to create a hierarchical tree of work items or a flat relationship between work items. Work items can also be linked to external artifacts such as web pages, documents, source code, build results, test results and specific versions of items in source control.

The flexibility in the work item system allows Azure DevOps to play many roles from requirements management to bug tracking, risk and issue tracking, as well as recording the results of reviews. The extensible linking capabilities ensure that traceability from requirements to source code to test cases and results can be accomplished and reported on for auditing purposes as well as historical understanding of changes.

Source control

[edit]

Azure DevOps supports two different types of source control – its original source control engine called Team Foundation Version Control (TFVC) and with the release of TFS 2013, it supports Git as a core source control repository.

Team Foundation Version Control

[edit]

TFVC is a centralized version control system allowing teams to store any type of artifact within its repository.[14] TFVC supports two different types of workspaces when working with client tools – Server Workspaces and Local Workspaces.[15] Server workspaces allow developers to lock files for check-out and provide notification to other developers that files are being edited. A frequent complaint for this model is that files on the development machine are marked as read-only. It also requires developers to "go offline" when the server can't be contacted. Local workspaces were designed to avoid these problems. In a local workspace scenario files are not read-only and they do not have to be checked out before working on them. As long as the files are on the developer's local machine, it doesn't matter if the server is connected or not. Conflicts are dealt with at check-in time.

To improve performance for remote clients, Azure DevOps includes the ability to install Proxy Servers.[16] Proxy servers allow source control contents to be cached at a site closer to the developers to avoid long network trips and the associated latency. Check-ins are still performed directly against the Azure DevOps application tier so the Proxy Server is most beneficial in read scenarios.

As part of the source control engine, Azure DevOps supports a number of features to help developers ensure the code that is checked in follows configurable rules. Azure DevOps also supports a Code Analysis feature that when used independently is known as FxCop.

Git

[edit]

With the release of TFS 2013, Microsoft added native support for Git. This is not a Microsoft specific implementation but a standard implementation based on the libgit2[17] library. Because Microsoft took the approach of using a standard library, any Git client can now be used natively with Azure DevOps. This allows tools on any platform and any IDE that support Git to connect to Azure DevOps. In addition, if developers do not want to use Microsoft's Team Explorer Everywhere plug-in for Eclipse, they can choose to use eGit[18] to connect to Azure DevOps.

Reporting

[edit]

The reporting infrastructure consists of a data warehouse,[19] which is a relational database and a SQL Server Analysis Services data cube.[20] Both of these sources are available for reporting through SQL Server Reporting Services when this option is installed. Since these are standard database and cube structures, any tool which can point to these data sources can report from them. This includes tools such as Cognos, Tableau, Excel and other reporting tools. Included with each out of the box process template is a set of reports for reporting services which cover Build information, Test results and progress, project management, agile reports (Backlog Overview, Release Burndown, Sprint Burndown and Velocity), bug and issue data. New reports can be created using Report Builder for SSRS and any of the existing reports can be modified.

TFS 2013 introduced a new feature called "light-weight reporting" which provides for the ability to create real-time reports based on query results and which do not rely on the warehouse or cube.

Team Build

[edit]

Team Build (prior to TFS 2015) is a build server application included with Team Foundation Server. Two components make up Team Build – MSBuild and Windows Workflow Foundation. MSBuild is a declarative XML language similar to Apache Ant.

Windows Workflow controls the overall flow of the build process, and Azure DevOps includes many pre-built workflow activities for managing common tasks that are performed during a build.[21] The build system is extensible with users being able to create their own workflow activities, the ability to inject MSBuild into the process and to execute external processes.

The build process can be configured for various types of builds including scheduled builds, continuous integration, gated check-in and rolling builds.

The build process in Azure DevOps is also part of the traceability mechanism in that Team Build brings together many of the artifacts that are created and stored in Azure DevOps. Assuming developers associate source code with work items on check-in, Team Build has the ability to report on the changes in each build – both source code changes and work item changes as well as test results. As bugs and PBIs are resolved and integrated into builds, the work items which track these artifacts are automatically updated to indicate in which build they were successfully integrated. Combined with the testing tools, testers then get an integrated view of what code was changed in each build, but also which bugs, PBIs and other work changed from build to build.

Release management

[edit]

In mid-2013 Microsoft purchased a product called InRelease from InCycle Software.[22] InRelease was fully incorporated into Team Foundation Server 2013. This capability complemented the automated build and testing processes by allowing a true continuous deployment solution. The tools were re-branded "Release Management" for TFS 2013. The Release Management capabilities give teams the ability to perform a controlled, workflow (provided by Windows Workflow Foundation) driven release to development, test and production environments and provides dashboards for monitoring the progress of one or more releases.

History

[edit]

This first version of Team Foundation Server was released March 17, 2006.[23]

Product name Form Release year Version Number [24][25]
Team Foundation Server 2005 On-premises 2006 8
Team Foundation Server 2008 On-premises 2008 9
Team Foundation Server 2010[26] On-premises 2010 10
Team Foundation Service Preview Cloud 2012
Team Foundation Server 2012 On-premises 2012 11
Visual Studio Online[27] Cloud 2013
Team Foundation Server 2013 On-premises 2013 12
Team Foundation Server 2015 On-premises 2015 14
Visual Studio Team Services Cloud 2015
Team Foundation Server 2017 On-premises 2017 15
Team Foundation Server 2018 On-premises 2017 16
Azure DevOps Services[28] Cloud 2018
Azure DevOps Server 2019[29] On-premises 2019 17
Azure DevOps Server 2020 On-premises 2020 18
Azure DevOps Server 2022[30] On-premises 2022

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Azure DevOps Server

View on Grokipedia
from Grokipedia
Azure DevOps Server is a Microsoft-developed on-premises platform that enables teams to collaborate on software development through integrated tools for source control, work tracking, continuous integration, and delivery.[1] It serves as the self-hosted counterpart to the cloud-based Azure DevOps Services, allowing organizations to maintain full control over their data and infrastructure while leveraging modern DevOps practices.[2] Originally released in 2005–2006 as Visual Studio Team System, including Team Foundation Server (TFS) in 2006, and later rebranded as Team Foundation Server (TFS), the product underwent a significant evolution with the 2019 release, when Microsoft renamed it Azure DevOps Server to align with its cloud offerings and emphasize expanded capabilities for agile planning, version control, and CI/CD pipelines.[3] This rebranding introduced features like unlimited private Git repositories, multi-stage pipelines for any language or platform, and integration with third-party tools via REST APIs and OAuth 2.0.[1] As of November 2025, the latest version is Azure DevOps Server 2025 Release Candidate (RC), released on October 7, 2025, which includes updates for enhanced security, compliance with over 100 certifications, and support for direct upgrades from TFS 2015 or later.[4] Key components of Azure DevOps Server include Azure Boards for planning and tracking work items, Azure Repos for Git and TFVC version control, Azure Pipelines for building and deploying applications, Azure Test Plans for manual and exploratory testing, and Azure Artifacts for managing packages across feeds.[2] These services integrate seamlessly with IDEs like Visual Studio and support extensions from the Azure DevOps Marketplace, making it suitable for teams of all sizes seeking customizable, on-premises DevOps solutions.[1]

Overview

Description

Azure DevOps Server is Microsoft's on-premises platform for collaborative software development, providing integrated tools that support planning, coding, building, testing, and deploying applications.[1] It offers a comprehensive set of services to facilitate end-to-end DevOps workflows, including version control via Git or Team Foundation Version Control (TFVC), work item tracking for agile planning, and continuous integration and continuous delivery (CI/CD) pipelines.[2] The core purpose of Azure DevOps Server is to enable development teams to manage the full application lifecycle in a self-hosted environment, ensuring control over infrastructure and data while supporting collaboration among distributed teams.[5] This on-premises deployment allows organizations to maintain data sovereignty for compliance and security requirements, seamlessly integrate with existing on-premises tools and systems, and customize the platform to meet enterprise-specific needs.[1] Additionally, it provides scalability for large teams by handling high volumes of projects and users without relying on cloud connectivity, reducing latency and dependency on external services.[2] Azure DevOps Server supports multiple editions to accommodate different team sizes and requirements. The Express edition is free for individual developers or small teams of up to five users, offering full feature access with simple setup on client or server operating systems.[6] For larger deployments, the full server edition requires Client Access Licenses (CALs) per user, providing unlimited scalability and advanced capabilities.[7] As of November 2025, the latest release is Azure DevOps Server 2025 Release Candidate (RC), made available on October 7, 2025, which includes enhancements such as improved self-hosted agent performance with sparse checkout support for Azure Repos and better Docker Compose integration.[4]

Deployment Options

Azure DevOps Server is designed for on-premises deployment, allowing organizations to host the platform within their own infrastructure for greater control over data and customization.[5] Installation requires a supported operating system, such as Windows Server 2022 or Windows Server 2025, running on a 64-bit architecture.[8] Additionally, it necessitates SQL Server 2019 or SQL Server 2022 (Standard or Enterprise editions recommended for production), or Azure SQL Database/Managed Instance for the data tier, along with .NET Framework 4.8 or later.[8] Hardware specifications include a minimum of one octa-core processor and 16 GB RAM with a solid-state drive (SSD) for a single-server setup supporting up to 250 users, though smaller teams may start with scaled-down configurations like 8 GB RAM for evaluation.[8] The setup process typically involves running the Azure DevOps Server installer followed by the Configuration Wizard, which supports basic or advanced configurations.[9] For small teams, a single-server topology combines the application and data tiers on one machine, simplifying initial deployment but limiting scalability.[9] In contrast, multi-server deployments separate the application tier (handling web services and logic) from the data tier (SQL Server) to enable high availability and support for larger user bases, such as 500+ users requiring dedicated octa-core CPUs and 16 GB RAM per tier.[10] During configuration, administrators select options for service accounts, reporting, and features like code search, ensuring the server is joined to an Active Directory domain or workgroup for authentication.[9] Licensing for Azure DevOps Server requires a server license plus Client Access Licenses (CALs) for each user or device accessing the platform, with Visual Studio subscribers receiving free CALs equivalent to Basic access levels.[11] The free Azure DevOps Server Express edition supports up to five active users with all core features, including Boards and Pipelines, making it suitable for small teams or evaluations without additional costs.[6] Paid editions include a SQL Server Standard license, but organizations must handle ongoing maintenance and upgrades independently.[9] Compared to the cloud-based Azure DevOps Services, the on-premises Server option provides full administrative control, data sovereignty, and no recurring subscription fees beyond initial licensing, though it demands internal resources for hardware, backups, and patching.[5] Azure DevOps Services, conversely, offers automatic updates, elastic scalability, and a pay-as-you-go model integrated with Azure infrastructure, but stores data in Microsoft's cloud, potentially raising compliance concerns for regulated industries.[5] Both deployments support identical core services like work tracking and source control, but on-premises requires manual scaling and security management.[6] Migration between deployments is facilitated by tools such as the Azure DevOps Data Migration Tool for high-fidelity transfers from on-premises to Azure DevOps Services, preserving work items, repos, and pipelines.[12] For moving from cloud to on-premises or vice versa, the Database Import Service in Azure DevOps Services enables importing projects from Server databases, though full migrations may require additional steps like exporting Git repos separately.[13] Security for on-premises deployments emphasizes Active Directory integration, where servers must join a domain to leverage domain user accounts for authentication and service principals, enhancing centralized identity management.[8] Firewall configurations are critical, requiring open ports such as 80/443 for HTTP/HTTPS access, 8080 for the web application, and 1433 for SQL Server connectivity, with rules tailored to restrict traffic to trusted networks and enable HTTPS for encrypted communications.[14]

History

Early Development as TFS

Team Foundation Server (TFS) was introduced as part of the Visual Studio Team System suite, with its initial version, TFS 2005, shipping on March 17, 2006, following over three years of development that began before April 2003.[15] Designed primarily for .NET development teams, it provided centralized version control via Team Foundation Version Control (TFVC), work item tracking for managing bugs and tasks, and build automation through Team Foundation Build, aiming to streamline collaboration in software projects.[16] This launch marked Microsoft's shift toward integrated application lifecycle management (ALM) tools, replacing the file-based Visual SourceSafe with a more robust, database-driven system built on SQL Server 2005 for storing work items, test results, and other artifacts.[17] Subsequent releases built on this foundation with incremental enhancements. TFS 2008, released in November 2007, improved reporting capabilities by supporting SQL Server 2008 and allowing Reporting Services to run on any server or port, while introducing multi-threaded builds with MSBuild and better integration with SharePoint 2007 for project portals.[18] TFS 2010, launched in April 2010, added agile planning tools such as hierarchical work item backlogs and sprint planning capabilities, along with deeper SharePoint integration for document management and dashboards, and a complete rewrite of the setup process to address prior installation complexities.[19] By TFS 2012, released in 2012, Microsoft previewed support for Git repositories alongside TFVC, enabling distributed version control workflows within the server.[20] Further evolution continued in later versions. TFS 2013, shipping in October 2013, enhanced web access with a redesigned interface for version control exploration and work item management directly in browsers, improving usability for remote teams.[21] TFS 2015, released in 2015, elevated Git to first-class status with full native support, including branch visualization and pull request workflows, while introducing a web-based, cross-platform build system.[22] TFS 2017, launched in 2016, integrated the Visual Studio Marketplace for extensions, allowing administrators to install and manage custom tools like delivery plans directly from the server interface.[23] Finally, TFS 2018, released in 2018, expanded cross-platform agent support for builds and releases on Linux and macOS, alongside deprecation of legacy XAML builds in favor of the modern pipeline model.[24] Architecturally, TFS diverged from Visual SourceSafe's file-based storage by adopting a SQL Server-based data warehouse for reporting, comprising relational databases and an OLAP cube processed via SQL Server Analysis Services to enable analytics on project metrics like build success rates and work item trends.[25] This shift supported enterprise-scale data aggregation from operational stores, facilitating customizable reports through SQL Server Reporting Services.[26] TFS targeted enterprise software development by emphasizing ALM, serving as a central hub for planning, coding, testing, and deployment to reduce silos and improve traceability across the development lifecycle.[27] Early adoption was driven by its tight integration with Visual Studio, appealing to large organizations seeking comprehensive tooling for .NET-centric workflows. Despite these strengths, early TFS versions faced challenges, including criticism for being Windows-only, limiting accessibility for cross-platform teams, and notorious setup complexity that often required extensive configuration of SQL Server, IIS, and SharePoint components.[15] These issues contributed to a steep learning curve, though later releases mitigated them through simplified installations and broader compatibility.

Rebranding and Modern Versions

In 2019, Microsoft rebranded Team Foundation Server (TFS) to Azure DevOps Server, aligning the on-premises product with the cloud-based Azure DevOps Services (formerly Visual Studio Team Services) to provide a unified branding and experience across deployment options.[3][28] This rebranding emphasized a service-oriented model, introducing unified hubs such as Boards for work tracking, Repos for version control, and Pipelines for CI/CD, which mirrored the modular structure of the cloud service and promoted a Git-first approach to support open-source workflows.[29] The version progression of Azure DevOps Server continued to incorporate cloud innovations into the on-premises environment. Azure DevOps Server 2019 featured a preview of YAML-based pipelines, enabling declarative pipeline definitions stored alongside code in repositories, and general availability of Azure Artifacts for package management feeds.[30] In 2020, multi-stage pipelines became generally available, allowing more complex workflows with build, test, and deployment stages.[31] The 2022 release enhanced security through fixes for vulnerabilities like remote code execution (CVE-2023-33136) and elevation of privilege (CVE-2023-38155), along with pipeline controls such as restricted variable settings and support for Group Managed Service Accounts in self-hosted agents; it also improved Linux agent compatibility via .NET 6 runtime upgrades for cross-platform operations.[32] A major shift during this period was the adoption of a service-based architecture that closely mirrored cloud practices, prioritizing Git as the primary version control system and fostering open-source compatibility through features like enhanced repository permissions and fork policies.[33] SharePoint integration, previously used for dashboards and document management, was discontinued starting with Azure DevOps Server 2019 in favor of native web-based analytics and customizable dashboards within the platform.[34] Feature rollouts included backporting cloud capabilities, such as the Visual Studio Marketplace for extensions—expanded for on-premises use—and comprehensive REST APIs for programmatic access to services like work items and builds.[33] The release candidate (RC) for Azure DevOps Server 2025, issued on October 7, 2025, introduced improvements for self-hosted runners, including downloads for agent version 3.248.0 (or 4.248.0 on .NET 8) to support features like sparse checkout in YAML pipelines, and task enhancements such as TFX validation for Node runner end-of-life warnings and updated authentication in the PublishToAzureServiceBus task.[4] Regarding support lifecycle, mainstream support for TFS 2018 concluded on January 10, 2023, with extended security updates available until January 11, 2028; for Azure DevOps Server 2020 Update 2, mainstream support ends on October 14, 2025, followed by extended support until October 8, 2030.[35][36]

Architecture

Server Components

Azure DevOps Server utilizes a multi-tier architecture to separate concerns and enable scalable on-premises deployments. The application tier primarily consists of web services hosted on Internet Information Services (IIS), which provide APIs and manage background job agents for processing tasks such as builds and alerts. This tier can be deployed across multiple servers with network load balancing to distribute workload and support up to 2,000 users in large environments.[37][38] The data tier relies on Microsoft SQL Server as its core database platform, storing operational data in relational format. Key databases include the Tfs_Configuration database, which maintains server-wide configuration and resource catalogs, and individual project collection databases that house project-specific data such as work items and build artifacts. For reporting purposes, an optional reporting tier incorporates SQL Server Analysis Services, featuring the TFS_Analysis database for online analytical processing (OLAP) cubes that aggregate data from the TFS_Warehouse for multidimensional analysis. These relational databases handle core operational needs, while the Analysis Services component enables efficient querying of historical and summarized data.[37][39] Web services in Azure DevOps Server expose both SOAP and REST endpoints to facilitate interactions from clients and integrations, ensuring compatibility with various tools and protocols. A dedicated background job service operates within the application tier to handle asynchronous operations, including build orchestration, alert processing, and system maintenance tasks.[37] For scalability and high availability, Azure DevOps Server supports load-balanced multi-server configurations on the application tier using network load balancers, allowing horizontal scaling across domains. The data tier can implement failover clustering on SQL Server instances to provide fault tolerance and distribute project collection databases for improved performance and management. As of October 2025, a release candidate for the next version is available, maintaining the multi-tier architecture.[38][4] Azure DevOps Server requires deployment on supported Windows Server versions, such as Windows Server 2019 or 2022, and integrates with Active Directory for authentication and group synchronization, which updates identities every 24 hours by default. In hybrid environments, it can leverage Azure AD Connect to synchronize on-premises Active Directory with Microsoft Entra ID, enabling consistent identity management across cloud and on-premises resources.[8][37][40]

Extensibility

Azure DevOps Server supports extensibility through a variety of mechanisms that allow organizations to customize workflows, integrate with external systems, and extend core functionality without modifying the underlying platform code. Central to this is the Visual Studio Marketplace, which hosts extensions compatible with Azure DevOps Server, enabling on-premises installations of add-ons such as custom work item controls and build tasks.[41] These extensions can be shared privately within teams or publicly, providing flexibility for tailored deployments. Customization options include process templates, which define work item types, states, and workflows to align with organizational methodologies; server plugins for handling events like work item updates; and REST API extensions that allow creation of custom endpoints for data interactions.[41][42] Server plugins, often implemented via interfaces like ISubscriber, enable server-side logic execution in response to events, supporting automation in on-premises environments.[43] Integration capabilities facilitate connections with third-party tools through hooks, such as webhooks for bidirectional data flow with systems like Jenkins or Jira, and service hooks for triggering notifications or actions in external services upon events in Azure DevOps Server.[41] For instance, service hooks can notify Slack or email systems of build completions, enhancing cross-tool collaboration. Developers can build extensions using SDKs for .NET and Node.js, which provide libraries for interacting with Azure DevOps APIs and UI elements; extension versioning is managed through VSIX manifests, ensuring compatibility with specific server updates.[41] On-premises deployments of Azure DevOps Server require manual updates for extensions, unlike the automatic synchronization in Azure DevOps Services, and custom code undergoes security reviews including malware scans and sandboxing to mitigate risks.[41] No third-party code execution is permitted directly on the server to maintain security integrity.[41]

Client Applications

Users interact with Azure DevOps Server through a variety of client applications that provide access to its services, including web-based, desktop, and command-line interfaces. These clients enable developers, testers, and team members to manage source control, work items, builds, and more, while supporting both on-premises deployments and integration with development environments.[44] The primary interface is the web portal, a browser-based application accessible via HTTPS that offers a responsive design for cross-platform use on desktops, tablets, and mobile devices. It provides unified access to all Azure DevOps Server services, such as Boards for work tracking, Repositories for source control, Pipelines for CI/CD, Test Plans, and Artifacts, without requiring additional software installation. Supported browsers include the most recent versions of Microsoft Edge, Google Chrome, Mozilla Firefox, and Apple Safari (version 14.1 or later), ensuring compatibility with Azure DevOps Server 2019 and newer versions. For mobile access, the web portal renders a mobile-friendly view for viewing and updating work items, though no native mobile apps are provided by Microsoft.[45][46] For integrated development, Visual Studio serves as a full-featured IDE client with built-in support for Azure DevOps Server via the Team Explorer plug-in. This integration allows seamless management of Git or TFVC source control, work items, builds, and releases directly within the IDE, supporting Visual Studio 2022, 2019, 2017, and earlier versions with compatibility updates. Team Explorer can also be installed standalone for users without a full Visual Studio license, providing a lightweight desktop application for connecting to Azure DevOps Server, querying work items, and handling version control operations.[45][47] Visual Studio Code offers lightweight integration through extensions available in the Visual Studio Marketplace, such as Azure Repos for Git repository management and Azure Boards for work item tracking. These extensions enable cloning repositories, creating pull requests, debugging, and task integration, making it suitable for cross-platform development without the overhead of a full IDE. The extensions connect to Azure DevOps Server using the same REST APIs as other clients, supporting Git workflows over HTTPS or SSH.[48][44] Command-line tools provide scripted and automated access for advanced users. The Azure DevOps CLI extension for the Azure CLI allows management of work items, repositories, pipelines, and more via commands like az devops work item list or az repos pr create, authenticating with Personal Access Tokens (PATs) for on-premises servers. Additionally, standard Git CLI tools handle repository operations, supporting protocols like HTTPS for secure connections and SSH for key-based authentication. TFVC clients can use the tf.exe command-line utility for version control tasks. Authentication across clients relies on PATs as an alternative to passwords, OAuth 2.0 for API calls, or on-premises methods like NTLM and Kerberos, with Microsoft Entra ID integration for hybrid scenarios. These clients consume server REST APIs over HTTPS to ensure secure, standardized interactions.[49][50][51]

Services

Boards and Work Tracking

Azure Boards provides tools for planning, tracking, and collaborating on work items within Azure DevOps Server, enabling teams to manage software development processes using customizable Agile methodologies.[52] Work tracking supports the creation and organization of work items, visualization through boards and backlogs, and integration with other services for end-to-end traceability.[53] These features are available in the on-premises deployment of Azure DevOps Server, with process customization options via XML templates for self-hosted environments.[54] Work items serve as customizable entities to represent various aspects of development, such as tasks, bugs, user stories, epics, and features.[55] Each work item includes fields like state (e.g., New, Active, Resolved, Closed) to track progress through defined workflows, priority (an integer value indicating urgency), and tags (keywords for categorization).[56] These fields can be extended or modified to suit team needs, supporting hierarchical organization and detailed tracking of dependencies.[55] Boards in Azure DevOps Server offer visual representations of work items, including Kanban boards for continuous flow and sprint taskboards for time-boxed iterations.[57] Kanban boards display work items as cards across customizable columns that map to workflow states (e.g., To Do, In Progress, Done), with options to add swimlanes for prioritizing different classes of service.[58] Sprint boards focus on tasks within a specific iteration, providing views of capacity and burndown charts to monitor progress.[57] Both board types allow teams to visualize backlogs, limit work in progress, and update item states directly by dragging cards between columns.[58] Backlogs provide hierarchical views of work items, organizing them into levels such as epics (high-level initiatives), features (deliverables under epics), and user stories or tasks (detailed requirements).[59] Teams can prioritize and rank items within these portfolios, with mapping options to ensure visibility across levels.[59] For filtering and querying, Azure DevOps Server uses Work Item Query Language (WiQL), a SQL-like syntax to retrieve specific items based on criteria like state, tags, or assignments.[59] Process templates define the structure for work tracking in Azure DevOps Server, with built-in options including Agile (for flexible planning with user stories and bugs), Scrum (emphasizing product backlogs and sprints), and CMMI (for formal requirement management and change requests).[60] These templates specify work item types, workflows (states and transitions), and rules, while custom templates can be created or imported via XML for on-premises adaptations.[60] Administrators can inherit and customize these processes to enforce team-specific workflows without altering core system templates.[54] Collaboration features enhance team interaction on work items, including @mentions to notify assignees, threaded discussions for comments, and attachments for supporting documents.[55] Area paths classify work by team or functional scope, while iteration paths define time-based planning, enabling scoped views and queries for distributed teams.[60] These elements support real-time updates and notifications to foster efficient communication. For traceability, work items can link to repository elements like commits or branches and to builds using predefined link types such as "Integrated in build," providing a connected view of development artifacts.[61] This integration allows brief reference to work item metrics in reporting tools for progress analysis.[62]

Repositories and Source Control

Azure DevOps Server provides robust source control capabilities through Azure Repos, supporting both Git for distributed version control and Team Foundation Version Control (TFVC) for centralized management, allowing teams to choose the system that best fits their workflow.[63] Git is the default for new projects, offering flexibility for collaborative development, while TFVC remains available for legacy or specific needs like handling large binary files.[64] These systems enable version history tracking, branching, and merging to maintain code integrity across projects.[5] Git in Azure DevOps Server facilitates distributed version control, where developers can work offline with full repository history locally before syncing changes. Key features include lightweight, path-independent branching that allows easy creation and switching of branches without server intervention, supporting parallel development across teams.[64] Pull requests enable structured code reviews, where changes are proposed, discussed via inline comments, and merged only after approval, integrating seamlessly with branch policies for quality enforcement.[65] Merge policies can require a minimum number of reviewers, successful builds for validation, or status checks from external services before allowing merges to protected branches like main.[66] TFVC operates as a centralized model, where all changes are checked into the server via changesets that group related modifications, ensuring atomic commits and server-side conflict resolution.[64] It supports path-based branching created on the server for risk isolation, requiring separate workspaces for different branches, and uses labels to tag specific file versions for easy reference and rollback.[67] File-level check-ins allow granular control, including optional locking for exclusive edits, making it suitable for scenarios with large binaries or strict governance.[64] Repository management in Azure DevOps Server allows unlimited private Git repositories per project, with no enforced limits on storage or number for on-premises deployments.[1] Permissions are configurable at the repository or branch level, including Read (for cloning and viewing), Write (for pushing changes and creating branches), and Admin (for managing settings and permissions), assigned to users or groups like Contributors and Project Admins.[68] Forking creates an isolated copy of a repository for experimental work, with changes synced back via pull requests, while cloning enables local copies using Git clients or Visual Studio, supporting standard operations like fetch and push.[69] Branching policies in Git repositories enforce team standards by requiring minimum reviewers for pull requests, build validation to ensure code passes automated tests before merging, and status checks to verify external dependencies or quality gates.[66] These policies apply to specific branches, such as main, and can include options like automatic build triggers or vote resets on new commits, promoting consistent code quality without blocking development.[70] Migration tools support converting TFVC repositories to Git, preserving up to 180 days of history for smaller repos via the built-in import feature, or full history including branches using the open-source git-tfs tool.[71] This process involves checking out the latest version, removing binaries, and importing into a new Git repo within the same organization, with TFVC kept read-only post-migration for reference.[71] Planning is essential to address differences, such as revising ignore files and training on Git workflows.[72] The primary differences between Git and TFVC lie in their models: Git excels in open-source or parallel development with local operations and no file locking, ideal for distributed teams, while TFVC suits large-scale projects with binaries or legacy systems requiring centralized control and granular file permissions.[64] Git uses Git LFS for binaries, whereas TFVC leverages server workspaces for efficient handling of large files without local storage bloat.[64] Both can coexist in the same project, allowing gradual transitions.[73]

Pipelines

Azure Pipelines in Azure DevOps Server provides continuous integration and continuous delivery (CI/CD) capabilities to automate the building, testing, and deployment of applications across various languages and platforms, including Windows, Linux, and macOS.[74] This on-premises solution enables teams to define workflows that integrate with source control repositories, execute tasks on self-hosted agents, and manage deployments to multiple environments, ensuring reliable software delivery without relying on cloud-hosted infrastructure.[74] Build pipelines in Azure DevOps Server support both YAML-based definitions, which allow code-as-configuration for version-controlled pipelines, and classic editor-based definitions for visual setup. These pipelines include tasks for compiling code, running unit tests, and publishing artifacts, with multi-stage support enabling sequential execution of build, test, and deployment phases within a single YAML file.[75] For example, a multi-stage build might compile source code in one stage, execute tests in another, and package artifacts for later use, all configurable via predefined or custom tasks.[76] Release pipelines extend build automation by handling deployments through stages representing environments such as development, staging, and production, incorporating deployment gates to pause execution until conditions like manual approvals or external checks are met.[77] Approvals can be pre- or post-deployment, notifying designated approvers via email or integrations, while environments manage logical groupings of resources with role-based access controls.[78] Integration with deployment groups allows targeting specific servers or virtual machines for rolling out updates, dynamically assigning self-hosted agents to jobs across distributed targets. Agents in Azure DevOps Server are exclusively self-hosted, installed on user-managed machines running Windows, Linux, or macOS, and organized into agent pools to enable parallel job execution and load balancing.[79] Pools allow administrators to define capabilities like software versions or hardware specs, ensuring jobs route to suitable agents, while variable groups securely store secrets and configuration values, injectable into pipelines without exposing them in source code. For instance, a variable group linked to Azure Key Vault can provide encrypted access to credentials during runtime. Triggers automate pipeline execution, with continuous integration (CI) triggers firing on commits or pull requests to repositories like Azure Repos, and scheduled triggers running builds at defined intervals using cron-like syntax.[80] Artifact sources, such as build outputs from prior pipelines, can also trigger releases, enabling chained workflows where a successful build automatically initiates deployment.[81] Advanced features enhance efficiency, including matrix strategies for fan-out builds across multiple configurations (e.g., varying OS or runtime versions) in a single job definition, and built-in caching to reuse dependencies like npm packages or Docker layers between runs, reducing execution time. Container support allows jobs to run inside Docker images for isolated environments, with service containers providing sidecar dependencies like databases during testing.[82] Recent enhancements include manual queuing of stages to control execution flow, available since 2024 H2.[83] Monitoring pipelines involves detailed logs for each task and job, accessible via the run summary page, with timelines visualizing execution duration and status for quick diagnostics.[84] Retention policies automatically delete old runs, releases, and artifacts after configurable periods (e.g., 30 days for non-retained items), customizable per pipeline to balance storage needs and audit requirements.[85] Verbose logging can be enabled for deeper troubleshooting, and error analysis tools highlight failures with agent and task details.[84]

Test Plans

Azure DevOps Server provides a comprehensive test management solution through its Test Plans feature, which enables teams to organize, execute, and track testing activities in a hierarchical structure. Test plans serve as the top-level container, encompassing test suites that can be static (manually organized), requirement-based (automatically linked to work items like user stories), or query-based (dynamically populated via queries). Within these suites, individual test cases are defined and managed, supporting manual, exploratory, and automated testing workflows to ensure application quality across the development lifecycle.[86][87] Test cases in Azure DevOps Server are reusable artifacts that detail specific validation steps, including actions to perform and expected results for each step. They support parameters for data-driven testing, allowing the same case to be repeated with varying inputs, and shared steps to promote reusability across multiple cases without duplication. Attachments such as images or documents can be added to individual steps or the overall case for reference, and test cases are inherently linked to requirements through associated work items, providing end-to-end traceability from planning to execution.[88] Execution of tests occurs via the web-based Microsoft Test Runner, which allows testers to run manual tests directly in a browser for web applications or using a desktop client for broader compatibility. During runs, results are tracked in real-time, with each step marked as passed, failed, or blocked, contributing to overall pass/fail metrics for the test case and suite. Exploratory testing is facilitated through the Test & Feedback extension, enabling ad-hoc sessions with automatic capture of screenshots, action logs, and screen recordings to document findings without predefined scripts.[89][90] To accommodate diverse environments, Azure DevOps Server uses a configuration matrix that combines variables such as operating systems (e.g., Windows 10, Windows 11) and browsers (e.g., Chrome, Edge) into testable combinations assignable at the suite or case level. These configurations are managed centrally in the Configurations hub and can be shared across multiple test suites and plans, ensuring consistent testing across hardware and software variations without redundant setup.[91] Integration with Azure Pipelines allows automated tests associated with test cases to be triggered from within Test Plans, where results from pipeline executions are published back to the test hub for unified tracking. Failed automated tests provide diagnostic details like stack traces and logs, which can inform the creation of bug work items directly linked to the affected test case.[92] Reporting capabilities in Test Plans include progress reports that visualize test outcomes, execution trends, and completion rates through configurable charts, such as outcome trends over time showing decreasing unrun tests and increasing passed ones. Test coverage analytics link test results to requirements, highlighting gaps in validation, while dashboard widgets and the Runs hub offer trend charts for pass/fail rates and overall quality metrics to support data-driven decisions.[93][86]

Artifacts

Azure Artifacts in Azure DevOps Server provides package management capabilities for storing, managing, and sharing build outputs as packages across development teams. It enables organizations to host feeds that support multiple package formats, including NuGet for .NET dependencies, npm for JavaScript modules, Maven for Java artifacts, Python packages via PyPI, and universal packages for generic binaries. Feeds can be configured as public or private, with public feeds allowing internet-wide access when hosted in public projects, while private feeds restrict visibility to authenticated users within the organization or project.[94][95] Publishing to these feeds occurs primarily from Azure Pipelines using dedicated tasks, such as the NuGet pack and push tasks or npm publish commands integrated into build pipelines. Versioning follows standards like semantic versioning (e.g., MAJOR.MINOR.PATCH) or automatic incrementing based on build numbers, ensuring traceability and reproducibility of package versions. Once published, packages are immutable, preventing modifications to maintain integrity and compliance with regulatory requirements.[96][97] Consumption of packages involves connecting client tools to the feed via configuration files, such as nuget.config for NuGet or .npmrc for npm, allowing developers to restore dependencies during builds or development. Feeds support upstream sources that proxy requests to external registries like nuget.org, npmjs.com, or Maven Central, caching packages locally to reduce external dependencies and improve performance. Users can browse packages through feed views, which filter and organize versions for easier discovery and promotion of stable releases.[98][99] Retention policies automate the management of package versions by deleting older ones based on criteria such as age (e.g., retain only the last 30 days) or size limits, helping control storage growth while preserving recent or pinned versions. Deleted packages enter a recycle bin for up to 30 days, allowing recovery if needed, and immutability ensures that retained versions cannot be altered post-publication for audit trails.[100][101] Security features include granular feed permissions, where roles like Owner, Contributor, and Reader control who can publish, delete, or read packages, assignable to Azure DevOps groups or individual users. Support for signed packages, particularly for NuGet, verifies authenticity and tamper-proofing using digital signatures during publishing and consumption.[102] In on-premises deployments of Azure DevOps Server, feeds utilize local storage, with package metadata and binaries stored in the SQL Server database associated with the project collection or optionally offloaded to file shares for large artifacts to optimize performance; unlike the cloud version, there is no usage-based billing, as all storage is managed within the organization's infrastructure.[8]

Reporting and Analytics

Built-in Reporting Tools

Azure DevOps Server 2022 and later versions, including the 2025 release, provide reporting through the Analytics service as the primary built-in platform, replacing the deprecated data warehouse and SQL Server Reporting Services (SSRS) infrastructure. The Analytics service aggregates and analyzes data directly from operational databases across services like work tracking, version control, builds, and tests, enabling insights into metrics such as team velocity and sprint burndown without the need for separate warehousing. Legacy components like the Tfs_Warehouse relational database and Tfs_Analysis OLAP cubes, along with SSRS for paginated reports, were fully deprecated in 2022, and are no longer supported or installed in new deployments; existing setups require migration to Analytics.[103][104] The Analytics service uses an object-relational data model to expose aggregated historical and near-real-time data (with up to a 30-second delay) via OData endpoints, supporting queries for entities like work items, builds, and tests. Administrators enable Analytics during server configuration, with data collection handled automatically through background jobs that process changes incrementally, typically refreshing views every few minutes to hours based on load. This setup facilitates custom reporting and avoids impacting live operations, with retention governed by overall system cleanup policies; historical data is preserved for audit purposes unless manually purged via custom scripts.[105][106][107] For multidimensional analysis, Analytics provides predefined views (e.g., for iterations, teams, and measures like work item counts or build success rates) that support slicing and dicing data, similar to OLAP but optimized for modern tools. Queries use OData protocols to retrieve filtered results in JSON or CSV formats, enabling integration with external applications without direct database access. Work item queries leverage Work Item Query Language (WiQL) against operational data, while Excel and Power BI connect via OData for dynamic pivot tables, charts, and ad-hoc analysis of trends like code churn or test coverage.[108][109][110] A key advantage of the on-premises Analytics service is configurable processing intervals and security controls, though it requires manual intervention for high-load optimizations or post-configuration refreshes, unlike the fully automated cloud counterpart in Azure DevOps Services. For new reporting needs, Analytics OData views are the recommended approach, with migration guidance available for legacy SSRS reports.[111][104]

Dashboards and Widgets

Dashboards in Azure DevOps Server serve as customizable, interactive pages that allow teams to monitor project status, trends, and key metrics in real time. These dashboards aggregate information from various services, such as work tracking and pipelines, into a unified view, enabling stakeholders to gain insights without navigating multiple tools. Users can create shared team dashboards or personal ones, with support for up to 500 dashboards per project.[112] Widgets form the core building blocks of dashboards, providing visual representations like charts, lists, and summaries drawn from underlying data sources including the Analytics service. Out-of-the-box widget types include burndown and burnup charts for tracking sprint progress, cumulative flow diagrams for visualizing workflow bottlenecks, velocity charts for assessing team performance over iterations, and build summary widgets displaying success rates and history. Additional categories cover test results trends, pull request overviews, and code review metrics, all configurable to filter by team, project, or time period.[113][114] Customization options allow users to add, rearrange, resize, or delete widgets via an edit mode that opens a catalog of available options, including up to 200 widgets per dashboard. Analytics-based widgets, such as those for cycle time or lead time, leverage OData queries for deeper trend analysis. For advanced visualizations, dashboards integrate with Power BI through Analytics views, enabling the creation and embedding of custom reports with interactive elements like slicers and drill-downs. The Azure DevOps Marketplace further extends capabilities with third-party widgets, such as enhanced charting tools or integrations with external monitoring services, which can be installed and added directly to the catalog.[115][116] Dashboards support real-time updates through an auto-refresh mechanism, typically every five minutes, ensuring data remains current without manual intervention; some widgets, like those pinned from work item queries, provide immediate reflections of changes. Team-specific configurations include permissions for editing, where project administrators control access for shared dashboards and team members can contribute based on roles like Contributor or Reader. These features are accessible via web browsers, offering responsive layouts suitable for desktop and mobile viewing to facilitate on-the-go monitoring.[62][117]

References

  1. Azure DevOps Server
  2. Azure DevOps Server documentation - Microsoft Learn
  3. TFS rebrand to Azure DevOps Server - Microsoft Learn
  4. Azure DevOps Server 2022 Release Notes - Microsoft Learn
  5. What is Azure DevOps? - Azure DevOps - Microsoft Learn
  6. Azure DevOps Server Download - Microsoft Learn
  7. Azure DevOps Server Pricing
  8. Azure DevOps Server Release Notes - Microsoft Learn
  9. Setup & upgrade requirements - Azure DevOps Server
  10. Install Azure DevOps on-premises on a single server - Microsoft Learn
  11. Install & configure Azure DevOps on multiple servers - Microsoft Learn
  12. Manage paid access for users - Azure DevOps | Microsoft Learn
  13. Get started with Azure DevOps Data Migration Tool - Microsoft Learn
  14. Migration overview - Azure DevOps - Microsoft Learn
  15. Ports required for Azure DevOps Server - Microsoft Learn
  16. Tenth anniversary of Team Foundation Server - Buck Hodges
  17. Understanding Team Foundation Server - Azure DevOps Blog
  18. More about SQL and Team Foundation Server - Azure DevOps Blog
  19. Final TFS 2008 Feature List - Microsoft Developer Blogs
  20. Agile Development - Make Agile Work for You in TFS 2010
  21. Announcing Git Integration with TFS - Microsoft Developer Blogs
  22. Visual Studio 2013 Release Notes | Microsoft Learn
  23. Team Foundation Server 2015 Release Notes - Microsoft Learn
  24. Team Foundation Server 2017 - Azure DevOps - Microsoft Learn
  25. Team Foundation Server 2018 Release Notes - Microsoft Learn
  26. Understanding the Data Warehouse Architecture - Azure DevOps Blog
  27. Reporting Services Reports - Azure DevOps Server | Microsoft Learn
  28. Microsoft Visual Studio Team Foundation Server 2013 with Update 4
  29. Announcing Azure DevOps Server 2019 RTW
  30. Now available: Azure DevOps Server 2019 | Microsoft Azure Blog
  31. Azure DevOps Server 2019 Release Notes - Microsoft Learn
  32. Azure DevOps Server 2020 Release Notes - Microsoft Learn
  33. What's new for Azure DevOps Server - Microsoft Learn
  34. About SharePoint Integration - TFS - Microsoft Learn
  35. Visual Studio Team Foundation Server 2018 - Microsoft Lifecycle
  36. Azure DevOps Server 2020 - Microsoft Lifecycle
  37. Architecture overview for Azure DevOps Server - Microsoft Learn
  38. Examples of complex topology for Azure DevOps Server
  39. https://learn.microsoft.com/en-us/previous-versions/azure/devops/report/sql-reports/components-data-warehouse
  40. Microsoft Entra Connect: Prerequisites and hardware
  41. Azure DevOps Services Pricing
  42. Extensions overview - Azure DevOps | Microsoft Learn
  43. Azure DevOps Services REST API Reference
  44. Extensibility Points - Azure DevOps - Microsoft Learn
  45. Tools and Clients that Connect to Azure DevOps - Microsoft Learn
  46. Azure DevOps client compatibility - Microsoft Learn
  47. View and update work items via mobile browser - Azure DevOps
  48. Reintroducing the Team Explorer standalone installer
  49. https://marketplace.visualstudio.com/items?itemName=ms-vsts.vsts-vscode
  50. Get Started with Azure DevOps CLI - Microsoft Learn
  51. Authentication Methods for Azure DevOps - Microsoft Learn
  52. Use SSH key authentication - Azure Repos | Microsoft Learn
  53. Azure Boards documentation | Microsoft Learn
  54. Plan and track work in Azure Boards - Microsoft Learn
  55. Use Agile Process Template Artifacts - Azure Boards | Microsoft Learn
  56. About work items and work item types - Azure Boards - Microsoft Learn
  57. List work item fields and attributes in Azure Boards - Azure Boards
  58. About Kanban Boards - Azure Boards
  59. Use your board - Azure Boards | Microsoft Learn
  60. Use backlogs to manage projects - Azure Boards
  61. Default processes and process templates - Azure Boards
  62. End-to-end traceability - Azure DevOps | Microsoft Learn
  63. Understand dashboards, charts, reports, and widgets - Azure DevOps
  64. Azure Repos documentation - Azure DevOps - Microsoft Learn
  65. Git and TFVC version control - Azure Repos - Microsoft Learn
  66. About pull requests and permissions - Azure Repos - Microsoft Learn
  67. Git branch policies and settings - Azure Repos - Microsoft Learn
  68. https://learn.microsoft.com/en-us/azure/devops/repos/tfvc/what-is-tfvc?view=azure-devops
  69. Set Git repository permissions - Azure Repos - Microsoft Learn
  70. Fork your repository - Azure Repos
  71. Set Git branch security and permissions - Azure Repos
  72. Import and migrate repositories from TFVC to Git - Azure Repos
  73. https://learn.microsoft.com/en-us/devops/develop/git/migrate-from-tfvc-to-git?view=azure-devops
  74. Use Git and TFVC repos in the same project - Azure - Microsoft Learn
  75. What is Azure Pipelines? - Azure Pipelines
  76. Stages in Azure Pipelines - Microsoft Learn
  77. Tutorial: Create a multistage pipeline with Azure DevOps
  78. Create a multi-stage release pipeline - Azure - Microsoft Learn
  79. https://learn.microsoft.com/en-us/azure/devops/pipelines/release/approvals?view=azure-devops
  80. Azure Pipelines Agents - Microsoft Learn
  81. Triggers in Azure Pipelines - Microsoft Learn
  82. Classic release triggers - Azure Pipelines - Microsoft Learn
  83. Service containers - Azure Pipelines | Microsoft Learn
  84. Azure DevOps Roadmap - Microsoft Learn
  85. https://learn.microsoft.com/en-us/azure/devops/pipelines/troubleshooting/review-logs?view=azure-devops
  86. Retention policies for builds, releases, and test - Azure Pipelines
  87. What is Azure Test Plans? Manual, exploratory, and automated test tools. - Azure Test Plans
  88. https://learn.microsoft.com/en-us/azure/devops/test/create-a-test-plan?view=azure-devops-2022
  89. Create manual test cases - Azure Test Plans
  90. Run manual tests - Azure Test Plans
  91. https://learn.microsoft.com/en-us/azure/devops/test/perform-exploratory-tests?view=azure-devops-2022
  92. Test different configurations - Azure Test Plans
  93. Run automated tests from test plans - Azure Test Plans
  94. Progress report, test plans - Azure Test Plans
  95. What are Azure Artifacts feeds? - Microsoft Learn
  96. Azure Artifacts key concepts - Microsoft Learn
  97. Publish and download NuGet packages with Azure Artifacts
  98. Artifacts in Azure Pipelines - Microsoft Learn
  99. What are upstream sources? - Azure Artifacts - Microsoft Learn
  100. What are feed views? - Azure Artifacts | Microsoft Learn
  101. Azure Artifacts best practices - Microsoft Learn
  102. Delete and recover packages - Azure Artifacts | Microsoft Learn
  103. Manage permissions - Azure Artifacts | Microsoft Learn
  104. Azure DevOps Server 2022 Deprecation of Reporting Services
  105. Azure DevOps Server databases - Microsoft Learn
  106. Manage data warehouse and analysis services cube - Microsoft Learn
  107. Add and configure a report server - Azure DevOps Server
  108. Manually process data warehouse and analysis services cube
  109. MDX Query Fundamentals (Analysis Services) - Microsoft Learn
  110. Choose the source of data and authoring tool - Azure DevOps Server
  111. Bulk Modify Azure Boards Work Items with Excel - Microsoft Learn
  112. Clean up Azure DevOps Server data - Microsoft Learn
  113. Connect with Data by Using OData Queries - Azure DevOps
  114. Data model for Analytics - Azure DevOps - Microsoft Learn
  115. Add, Rename, Delete, and Manage Team Dashboards - Azure ...
  116. Catalog of Out Of Box widgets you can add to a dashboard - Azure ...
  117. Analytics widgets - Azure DevOps - Microsoft Learn
  118. Add widgets to a dashboard - Azure DevOps - Microsoft Learn
  119. Azure DevOps - About Power BI integration - Microsoft Learn
  120. https://learn.microsoft.com/en-us/azure/devops/report/dashboards/dashboard-permissions?view=azure-devops
User Avatar
No comments yet.