Azure DevOps service updates and integration improvements

To help ensure your Azure DevOps environment remains secure, we're making key service updates. This includes ending support for new OAuth app registrations starting April 2025, though existing apps will continue working until full retirement in 2026. Additionally, Server Name Indication (SNI) will be required for all HTTPS connections beginning April 23, 2025, along with updates to TFVC check-in policies in Azure Repos.

Alongside these updates, we’re excited to announce the latest improvements in our Azure Boards + GitHub integration, making it easier to link branches, pull requests, and commits to work items. In addition, Pipelines now provides greater visibility into YAML stage dependencies, helping teams manage more complex workflows with improved efficiency.

Check out the release notes for details.

General

• No new Azure DevOps OAuth apps beginning April 2025
• Server Name Indication (SNI) now mandatory for Azure DevOps Services

Azure Boards:

• GitHub Integration: Improvements linking to commits, branches and pull requests
• GitHub Integration: Show build status for YAML pipelines
• Delivery Plans limit increased

Azure Repos

• TFVC check-in policies changes
• Enhancement to GetRepository API
• Enhancement to Pull Requests Query API

Azure Pipelines

• Improved visibility into YAML pipeline stage dependencies
• New Agent CDN
• Node 16 will be removed from pipelines-* Pipeline agent packages

Azure Test Plans:

• Retirement of action logging and switch to screen recording
• Auto-pause manual test run

General

No new Azure DevOps OAuth apps beginning April 2025

Starting in April 2025, we're no longer supporting new registrations of Azure DevOps OAuth apps. This is a first step towards our longer-term vision of retiring the Azure DevOps OAuth platform. We reccomend that all developers building applications on top of Azure DevOps REST APIs explore the Microsoft identity platform and registering a new Entra application instead.

All existing Azure DevOps OAuth apps will continue working until the platform’s official retirement in 2026. Learn more in our blog post here.

Server Name Indication (SNI) now mandatory for Azure DevOps Services

Beginning April 23, 2025, we'll require Server Name Indication (SNI) on all incoming HTTPS connections to Azure DevOps Services.

SNI is an extension to the TLS protocol that allows clients to specify the hostname they're connecting to. All modern browsers and client software support SNI and use it by default, ensuring a seamless transition for most users. In fact, more than 99.995% of the customer traffic reaching our servers is SNI-ready.

However, some client software may be incompatible with SNI due to various factors, such as being outdated, misconfigured networking libraries, runtimes, or operating systems. Issues may also arise from proxies or NGFW firewalls. The following tools used with Azure DevOps may be impacted by SNI issues:

• Git clients
• IDE plugins and extensions (Team Explorer Everywhere)
• Software running on older Java versions which don't support SNI (Java 6 and earlier) or don't have SNI enabled by default (some versions of Java 7 and 8)
• Old browser versions (see https://caniuse.com/sni)

SNI issues usually manifest by connection errors, such as:

• ERR_SSL_PROTOCOL_ERROR , ERR_CERT_COMMON_NAME_INVALID
• javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLException
• Couldn't establish trust relationship for the SSL/TLS secure channel

You can validate the SNI-compatibility of your system by calling the status endpoint of Azure DevOps, which we have configured to require SNI. If this call is successful, it indicates that the host, including its operating system and networking environment, is SNI-compatible. For detailed instructions on how to test, visit our blog post.

Azure Boards

GitHub Integration: Improvements linking to commits, branches and pull requests

We're continuously improving the Boards + GitHub integration to close usability gaps and align with the experience you're familiar with in Azure Repos.

With this update, we've introduced several improvements to streamline how branches, pull requests, and commits are linked to work items:

• When a GitHub branch is linked to a work item, any associated pull requests will now be automatically linked. No need to manually use AB#.

• Once a pull request is merged, the merge commit will be automatically linked to the work item.

• If the branch is deleted after the pull request is merged, the branch link will be automatically removed from the work item.

These improvements make it easier to track your development progress and maintain clean, up-to-date work item associations.

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.

Delivery Plans limit increased

Previously, we limited the Delivery Plans per project to 1,000. With this update, we have increased the maximum Delivery Plans per project to 1,500. You can learn more about adding and editing Delivery Plans in the documentation here.

Azure Repos

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:

1. Using Visual Studio.

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:

2. 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.

Request payload example :

{
    "queries": [
        {
            "type": "lastMergeCommit",
            "include": "Labels",
            "items": [ 
                "0d6c9b2b524113113fced41aecbf8631a4649dec"
            ]
        },
        {
            "type": "lastMergeCommit",
            "items": [
                "b524113113f0dd41aecbf8631a4649dec6c9b2ce"
            ]
        }
    ]
}

Azure Pipelines

Improved visibility into YAML pipeline stage dependencies

YAML pipelines provide flexibility for managing complex workflows, but visualizing stage dependencies has been a challenge—especially in multi-region deployments.

It hasn't always been clear how stages are connected. For example, determining whether CUS3 depends on WUS1 in addition to WUS2 and WUS3 has required reviewing the YAML directly.

With this sprint, stage dependencies are now displayed when a stage is expanded, providing immediate insight into execution order and upstream requirements.

New Agent CDN

As Edgio CDN is being retired, the domain URL owned by Edgio https://vstsagentpackage.azureedge.net will also be retired. We're adding a new domain URL https://download.agent.dev.azure.com  supported by the new CDN. Be sure to add this new domain URL to your firewall allowlist. Agent package downloads for self-hosted agents will fail once the old domain URL is removed. Refer to the post for more details.

Node 16 will be removed from pipelines-* Pipeline agent packages

Agent tasks can be implemented in PowerShell or Node. The agent ships with multiple versions of Node that tasks can target.

As new Node versions are released, tasks are updated to use new Node versions. The runtimes are included with the agent.

As Node versions exit out of the upstream maintenance window, some Pipelines tasks still depend on it. Azure DevOps updates supported tasks to a supported Node version. Third party tasks may still need older Node versions to run.

To accommodate this, we have two types of Pipeline agent packages:

If you want to run a task that requires the Node 16 execution handler on an agent that doesn't have Node 16 bundled, you can install the execution handler by inserting the NodeTaskRunnerInstaller@0 task in your pipeline:

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 16

Azure Test Plans

Retirement of action logging and switch to screen recording

Our desktop Azure Test Runner client relies on Problem Steps Recorder (PSR), a tool introduced in Windows 7 that is now being deprecated in newer Windows versions. As a result, the action log functionality in our desktop test runner may no longer work in future updates.

To ensure uninterrupted test tracking, we recommend switching to screen recording in our web runner, Test & Feedback Extension, which provides a modern, reliable way to capture and manage test steps. If you need assistance transitioning to the Test & Feedback Extension, please reach out to our support team.

Auto-pause manual test run

Never lose progress on your test runs with auto-pause test case run. This new feature automatically pauses your test case run if your work is interrupted, ensuring that partial progress is saved without needing a manual pause. Whether you step away or close the session, you can easily resume your test case right where you left off, reducing the risk of data loss and improving your workflow. By simplifying the pause and resume process, auto-pause helps you stay focused on testing without worrying about losing your progress. Give it a try, and let us know via email what you think!

Next steps

Head over to Azure DevOps and take a look.

How to provide feedback

We would love to hear what you think about these features. Use the help menu to report a problem or provide a suggestion.

You can also get advice and your questions answered by the community on Stack Overflow.

Thanks,

Silviu Andrica