Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
| Developer Community | System Requirements and Compatibility | License Terms | DevOps Blog | SHA-256 Hashes |
In this article, you will find information regarding the newest release for Azure DevOps Server.
To learn more about installing or upgrading an Azure DevOps Server deployment, see Azure DevOps Server Requirements.
To download Azure DevOps Server products, visit the Azure DevOps Server Downloads page.
Direct upgrade to Azure DevOps Server is supported from Azure DevOps Server 2019 or Team Foundation Server 2015 or newer. If your TFS deployment is on TFS 2013 or earlier, you need to perform some interim steps before upgrading to Azure DevOps Server 2022. Please see the Install page for more information.
Azure DevOps Server RC Release Date: October 7, 2025
Summary of What's New in Azure DevOps Server
Azure DevOps Server introduces features that we have previously released in our hosted version of the product. You can jump to individual sections to see all the new features for each service:
General
Copy code block to clipboard
In response to your feedback in the Developer Community, we’ve introduced a Copy to clipboard button for all code blocks in rendered markdown. This enhancement is available across Wiki pages, markdown file previews in Repos, pull request discussions and descriptions, and work item discussions.
Delivery Plans permission added
As part of our ongoing security enhancements, we’ve introduced a new Manage Delivery Plans project-level permission. This change was implemented to prevent unintentional read/write access for users in the Readers group.
Boards
AB# links on GitHub pull requests
As part of our ongoing enhancements to the Azure Boards + GitHub integration, we’re excited to introduce a new feature that streamlines how AB# links are displayed. With this update, AB# links now appear directly in the Development section of GitHub pull requests, making it easier to access linked work items without searching through descriptions or comments.
These links will only appear when AB# is included in the pull request description. If you link directly from a work item, they won’t be displayed in the Development section. Additionally, removing the AB# link from the description removes it from the Development control.
Connect to GitHub repository search improvements
We have improved process for connecting an Azure DevOps project to a GitHub organization, especially beneficial for those with thousands of repositories. Previously, you might have faced challenges like timeout errors and long wait times. This update optimizes the search and selection experience, eliminating the risk of timeout errors and making the connection process smoother and more efficient.
GitHub Integration: Show build status for YAML pipelines
We're committed to achieving feature parity between YAML and Classic Pipelines. One key missing feature was the ability to provide an "Integrated in build" link when your repository is hosted in GitHub. With our latest release, we've addressed this gap by adding an option in YAML pipeline settings for you to check:
Once the build is complete, the corresponding link will automatically appear on the associated work items, improving the overall traceability story.
REST API support for connecting GitHub repositories
We're introducing new REST API endpoints that enable you to automate the addition and removal of GitHub repositories in your Azure DevOps Projects. Additionally, we increased the repository limit per connection from 500 to 2,000 when using these endpoints.
These endpoints include:
We have also provided sample code to help you get started.
Change for deleting area and iteration paths
Deleting an area or iteration path can be disruptive. It can move work items to a new path and may cause teams to lose access to their boards and backlogs. Despite warnings and prompts, paths are sometimes deleted without fully understanding the consequences. To address this, we changed the behavior: Area and Iteration paths can now only be deleted if they are no longer used by any work items.
Enhanced tag management on work item form
Tag management in Azure Boards has been enhanced to provide a more streamlined experience. Deleted tags no longer appear in the suggested list on work item forms, ensuring that only active tags are displayed.
Improved image support in work item comments
We’ve improved our support for pasting images into work item comments. You can now paste images directly from sources like Microsoft Teams, emails, and Word documents into the discussion section of a work item
REST API limit on work item comments
To enhance security, a new limit has been set on the number of comments that can be added to work items through the REST API. Each work item now supports a maximum of 1,000 comments via the API. This restriction applies solely to the REST API, and users can still manually add comments through the web interface, even beyond the 1,000-comment threshold.
Delivery Plans limit increased
We have increased the maximum number of Delivery Plans per project from 1,000 to 1,500.
Repos
New setting to disable creation of TFVC repositories
In recent years, no new features were added to Team Foundation Version Control (TFVC) because Git has become the preferred version control system in Azure Repos. All recent improvements in security, performance, and accessibility have been made exclusively to Git repositories, leading to a continuous decline in TFVC usage. While some still rely on TFVC and we don't intend to remove this feature set, we plan to phase out TFVC gradually for new projects and project collections, as well as for projects that currently don't use TFVC.
As part of this transition, we're introducing a new setting to "Disable creation of TFVC repositories," which will only affect the creation of new TFVC repositories and won't impact existing ones.
UI support of Git submodules
Many teams actively use Git submodules to organize their codebase. We're excited to share that we've added support of Git submodules in the Files hub. Now you can instantly navigate to a submodule repository with just a single click, exactly to the specific commit referenced from your superproject. When used as a submodule, the following Git services are supported: Azure Repos, GitHub, GitLab and Bitbucket. Multiple URL formats specified in .gitmodules file are supported as well, including absolute HTTPS, SSH, and relative URLs.
New "Health and usage" panel in repo file hub
As Git repositories grow, they accumulate commits, blobs, and other data, which can increase the load on Azure DevOps infrastructure, impacting performance and user experience. Maintaining a healthy repository is key to ensuring consistent performance and reliability.
To support this, we now monitor several factors like repository size, commit frequency, contents, and structure. If your repository begins to strain the infrastructure, you may receive a notification with recommendations for corrective action. By managing your repository’s health, you can prevent disruptions and ensure smooth operations.
To check your repository’s health, go to Azure Repos, > Files and choose “Health and usage” from the ellipsis menu to access the Repository health and usage panel.
Configure target branches for pull requests
Managing multiple branches in a repository can be challenging, especially when creating new pull requests. With the new Configure Target Branches for Pull Requests feature, you can now specify a list of preferred target branches, ensuring that pull request suggestions are more accurate and relevant. This helps streamline your workflow and reduces the chances of targeting the wrong branch. To use this feature, create a .azuredevops/pull_request_targets.yml file in your repository's default branch. This YAML file should contain a list titled pull_request_targets with the branch names or prefixes that match the candidate branches. For example:
pull_request_targets:
- main
- release/*
- feature/*
In this configuration, the main branch is prioritized, but branches starting with release/ or feature/ will also be considered when appropriate. The configuration is applied in the following scenarios:
- Pull Request Suggestions: After pushing a branch to Azure DevOps, the Repos page may suggest creating a pull request from that branch, dynamically choosing the target branch.
- Pull Request URL: When navigating directly to the pull request creation page using a sourceRef parameter but omitting the targetRef parameter, Azure DevOps selects a target branch based on this dynamic choice.
It’s recommended to include only branches protected by pull request policies to ensure consistency in the first-parent history of the tip commit.
Support mermaid diagrams in markdown file
Markdown files containing mermaid syntax will now render as diagrams inside file previews in repos file browser and in pull requests. This can help you add richer documentation to your repositories.
Search pull requests by title on PR listing page
The pull requests listing page now includes a filter by PR title, making it easier to locate specific pull requests.
Sparse checkout for Azure Repos
The git sparse-checkout command is now supported in the YAML checkout task, alongside the partial clone filter, to improve repository checkout performance. You can use the properties sparseCheckoutDirectories and sparseCheckoutPatterns.
Setting sparseCheckoutDirectories enables cone mode, where the checkout process uses directory matching. Alternatively, you can set sparseCheckoutPatterns which triggers non-cone mode, allowing more complex pattern matching.
If both properties are set, the agent initializes cone mode with directory matching. If neither property is specified in the checkout task, the sparse checkout process is disabled. Any issues encountered during command execution results in the checkout task failing. YAML example for sparse checkout cone mode:
checkout: repo
sparseCheckoutDirectories: src
YAML example for sparse checkout non-cone mode:
YAMLCopy
checkout: repo
sparseCheckoutPatterns: /* !/img
Important
The sparse checkout feature requires agent v3.248.0 (v4.248.0 for .NET 8) or later versions.
You can find the agent on the releases page.
Make cross-repo policies case-sensitive
Previously, the branch candidate preview for cross-repo policies displayed results in a case-insensitive manner, despite branch matching being case-sensitive. This inconsistency created potential misalignment, as it could appear that certain branches were protected when they weren't. To resolve this issue, we have updated the branch pattern preview to align with the case-sensitive behavior of policy application.
Previously:
After:
TFVC check-in policies changes
New version (19.254) of Microsoft.TeamFoundationServer.ExtendedClient NuGet package
NuGet Microsoft.TeamFoundationServer.ExtendedClient package was updated with new TFVC policy classes and methods.
Policy changes
We're making changes to how TFVC check-in policies are stored in Azure DevOps, which also means updates to how the NuGet Microsoft.TeamFoundationServer.ExtendedClient communicates with the service. If your TFVC project uses check-in policies, migrate those policies to the new format. There are two ways to do this:
- Using Visual Studio.
Warning
Dangerous certain consequences of an action.: Ensure you updated Visual Studio to the latest version before proceeding (VS 2022, VS 2019, and VS 2017 with minimal versions 17.14 Preview 3, 17.13.6, 17.12.7, 17.10.13, 17.8.20, 16.11.46, 15.9.72 are supporting the new policies).
To create new policies using Visual Studio project administrator should open Settings -> Team Project -> Source Control -> Check-in Policy and add new policy (without "Obsolete" mark) with the same parameters as old one:
- If you're using custom implementation of Microsoft.TeamFoundationServer.ExtendedClient to communicate with server, please follow the migration guide. The migration is required for keeping TFVC check-in compatible with the future Azure DevOps versions. For the time being, both old (Obsolete) and new policies remain valid and functional. For information on the Future Plans, see our blog post.
Enhancement to GetRepository API
We have added creationDate property to the response of Repositories - Get Repository API returning repository creation date. The property is available on the API versions 7.2-preview and higher.
Enhancement to Pull Requests Query API
We have introduced a new Label property in the response of Pull Request Query - Get API. You can now specify whether to include labels (tags) for related pull requests in every query. A new Include property is available - if set to Labels, the response includes labels for the specified PRs. If left as null, labels won't be included. To prevent unintended errors, ensure that NotSet isn't explicitly assigned - this will result in Bad Request.
Note
Label enrichment resource utilization depends on the number of assigned labels and their length. Requesting labels can impact throttling and increase network load. To optimize the performance, we recommend avoiding unnecessary label requests.
Request payload example :
{
"queries": [
{
"type": "lastMergeCommit",
"include": "Labels",
"items": [
"0d6c9b2b524113113fced41aecbf8631a4649dec"
]
},
{
"type": "lastMergeCommit",
"items": [
"b524113113f0dd41aecbf8631a4649dec6c9b2ce"
]
}
]
}
Pipelines
TFX validates whether a task is using an End of Life Node runner
Task authors use TFX to publish extensions. TFX has been updated to perform validations on other Node runner versions.
Extensions that contain tasks using a Node runner version that is end of life (EOL) (up to and including Node 16) will see this warning:
Task < TaskName > is dependent on a task runner that is end-of-life and are removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance
Access Azure Service Bus from Pipelines using Microsoft Entra ID authentication
You can now use Microsoft Entra ID authentication to access Azure Service Bus from Azure Pipelines. This allows you to take advantage of Azure RBAC for fine grained access control.
Identities accessing Azure Service Bus need to be granted one of the Azure built-in roles for Azure Service Bus on the Service Bus accessed.
PublishToAzureServiceBus@2 task
The new PublishToAzureServiceBus@2 tasks can be configured using an Azure service connection. Create an Azure service connection and populate the serviceBusQueueName and serviceBusNamespace properties of the new task:
- task: PublishToAzureServiceBus@2
inputs:
azureSubscription: my-azure-service-connection
serviceBusQueueName: my-service-bus-queue
serviceBusNamespace: my-service-bus-namespace
useDataContractSerializer: false
messageBody: |
{
"foo": "bar"
}
Server tasks
Custom server (agent-less) tasks that use ServiceBus execution can specify an Azure Service Connection as EndpointId and omit ConnectionString. See Server task authoring.
TFX validates whether a task is using an End of Life Node runner
Task authors use TFX to publish extensions. TFX has been updated to perform validations on other Node runner versions.
Extensions that contain tasks using a Node runner version that is end of life (EOL) (up to and including Node 16) will see this warning:
Task < TaskName > is dependent on a task runner that is end-of-life and are removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance
Tasks that use an end-of-life Node runner version to execute emit warnings
Pipeline tasks that rely on a Node version no longer maintained will start receiving warnings: Task TaskName version is dependent on a Node version (10) that is end-of-life. Contact the extension owner for an updated version of the task. Task maintainers should review Node upgrade guidance: https://aka.ms/node-runner-guidance To suppress these warnings, you can set an environment or pipeline variable at either the pipeline (job) or task level. For example:
variables:
AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false
DockerCompose@0 uses Docker Compose v2 in v1 compatibility mode
Docker Compose v1 will reach its end-of-life and will be removed from Hosted Agents July 24 2024. We have updated the DockerCompose@0 task to use Docker Compose v2 in v1 compatibility mode if Docker Compose v1 is not available on the agent.
However, compatibility mode does not address all compatibility issues. See Migrate to Compose V2. Some users will need more time to update their Docker Compose projects for Docker Compose v2 compatibility. In those cases, follow these instructions to use the DockerComposeV0 task with docker-compose v1. NOTE: This guide is based on Install Compose standalone documentation Use docker-compose v1 on Windows Add the powershell step to your pipeline to download the docker-Compose v1.29.2 and use it with the DockerComposeV0 task on Windows:
variables:
dockerComposePath: C:\docker-compose
steps:
- powershell: |
mkdir -f $(dockerComposePath)
# GitHub now requires TLS1.2. In PowerShell, run the following
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-windows-x86_64.exe" -Destination $(dockerComposePath)\docker-compose.exe
displayName: Download docker-compose
- task: DockerCompose@0
inputs:
containerregistrytype: 'Azure Container Registry'
dockerComposeFile: '**/docker-compose.yml'
action: 'Run a Docker Compose command'
dockerComposeCommand: 'run'
dockerComposePath: $(dockerComposePath)\docker-compose.exe
Use docker-compose v1 on Linux
Add the bash step to your pipeline to download Docker-Compose v1.29.2 and use it with the DockerComposeV0 task on Linux:
YAMLCopy
variables:
dockerComposePath: /tmp/docker-compose
steps:
- bash: |
sudo mkdir $(dockerComposePath)
sudo curl -SL https://github.com/docker/compose/releases/download/1.29.2/docker-compose-linux-x86_64 -o $(dockerComposePath)/docker-compose
sudo chmod 755 $(dockerComposePath)/docker-compose
displayName: Download docker-compose
- task: DockerCompose@0
inputs:
containerregistrytype: 'Azure Container Registry'
dockerComposeFile: $(Build.SourcesDirectory)/DockerComposeV0/docker-compose.yml
action: 'Run a Docker Compose command'
dockerComposeCommand: 'run'
dockerComposePath: $(dockerComposePath)/docker-compose
Test Plans
Test and Feedback extension in Manifest V3
We're excited to announce a new update to the Azure DevOps Test and Feedback extension for both Chrome and Edge. This update transitions our implementation from Manifest V2 to V3, in line with Google's deprecation schedule for Manifest V2. While the core features of the extension remain unchanged, the update enhances both security and performance.
For more details, check out our recent blog post about this update. Test & Feedback Extension in Manifest V3
Azure Test Runner version 1.2.2
Azure Test Plans released a fix in 1.2.2 for a recent issue in Test Plans where Azure Test Runner(ATR) experienced launch failures in Chrome version 130. This issue arose due to Chrome’s added support for non-special scheme URLs, which impacted the ATR user flow. With this update, the regression bug is resolved, and ATR functionality is restored. For more details about this regression bug, visit this issue tracker in Chromium.
We encourage you to use web application for enhanced features. If you find any missing features in web application, we would love to hear from you. Share your feedback with us!
Seamless build Pipeline integration for test case execution
We’ve simplified the test case execution process by seamlessly integrating build pipeline configurations. Build definitions and IDs set at the test plan level now automatically propagate to the Web Runner, eliminating the need for manual configuration each time. This improvement saves time and enhances efficiency, allowing you to focus on more critical tasks.
Restore deleted test plans and test suites using REST API
Easily restore deleted test plans and test suites with new self-service APIs. We are introducing GET and PATCH APIs that allow you to look up deleted test plans or suites and restore them along with their child items—all without needing customer support. With these APIs, you can quickly recover accidentally deleted test work items, reducing downtime and improving productivity. While run artifacts won’t be restored, all related test plans, suites, and test cases can be brought back to your workspace with ease. This self-service feature gives you greater control over test management and streamlines the restoration process, making it faster and more efficient to recover critical test assets.
Export test cases with custom columns in XLSX
You can now export test cases with custom columns in XLSX. Based on your feedback, Test Plans supports exporting test cases with custom columns, giving you greater flexibility and control over the data you share and analyze. This enhancement helps you tailor exports to your needs, ensuring the information you export is relevant and actionable.
New sorting capabilities in Test Plans directory
The Test Plans directory now offers enhanced sorting options! With this update, you can quickly organize each column alphanumerically, providing a streamlined way to find and access your data.
Undo test step in web and desktop runner
Take control of your test case run with the new "Undo" option. You can easily revert test step statuses with a simple double-click, giving you more flexibility and control during test runs. No more restarting test cases to fix accidental clicks—just undo and continue your workflow without interruption.
We're also introducing keyboard-friendly navigation and accessibility improvements to ensure this feature works seamlessly for all users, including those who rely on assistive technologies. This enhancement helps you save time, reduce frustration, and stay focused on running tests efficiently.
Publish code coverage results v2 task improvements
With this release we're including several improvements to the v2 task:
Expanded support for various code coverage formats, including: .coverage,.covx,.covb,.cjson,.xml,.lcov, and pycov1.
Generation of a comprehensive cjson file (and a Code Coverage report) that contains detailed code coverage information such as file names, lines covered/not covered, etc.
Support for diff coverage (PR coverage): v2 can generate diff coverage PR comments for multiple languages within the same pipeline.
v2 task now supports the Build Quality Check task, which wasn't supported in v1 task.
Support for YAML pipelines in Test Plans
In addition to Classic pipelines, you can now use your YAML pipelines when configuring your Test Plans or executing automated tests from Test Plans.
This request was prioritized based on the following Developer Community suggestion tickets.
Reporting
Rollup columns data available in backlog
We’ve updated rollup columns to show the most recent available data. Previously, these columns could appear blank for frequently updated work items, causing confusion. You’ll also see a timestamp indicating when the data was last refreshed. While some delay in Analytics processing is normal, these improvements aim to provide transparency and a smoother experience when working with rollup columns.
Wiki
Improve pasting of HTML based content into Wikis
We’ve made it easier to paste HTML-based content into Wikis. Now, HTML elements like links, lists, tables, images, Excel sheets, Microsoft Teams messages, emails, and Azure Data Explorer queries are automatically converted to Markdown syntax for smoother editing.