Share via

Azure DevOps Server 2022 Update 2 Release Notes

  • Article

| 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 2022 Update 2 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 2022.2 RTW Release Date: July 9, 2024

Summary of What's New in Azure DevOps Server 2022.2 RTW

Note

We have re-released Azure DevOps Server 2022.2 to fix an issue with loading Teams names. The issue was reported in the Azure DevOps Server 2022.2 RTW now available blog post. If you have installed the version of Azure DevOps Server 2022.2 released on July 9, you can install Patch 1 for Azure DevOps Server 2022.2 to fix the issue. Patch 1 is not required if you are installing Azure DevOps Server 2022.2 for the first time since the download links have been updated to include the fix.

Azure DevOps Server 2022.2 RTW is a roll up of bug fixes. It includes all features in the Azure DevOps Server 2022.2 RC previously released. You can directly install Azure DevOps Server 2022.2 or upgrade from Azure DevOps Server 2020, 2019 or Team Foundation Server 2015 or newer. The following issues and vulnerabilities have been addressed with this release:

Azure DevOps Server 2022 Update 2 RC Release Date: May 7, 2024

Azure DevOps Server 2022.2 RC includes many new features. Some of the highlights include:

You can also jump to individual sections to see all the new features for each service:

General

Publish Test Results task

The Publish Test Results task now supports test run attachments for the JUnit report format.

New version of the Azure DevOps Web Extension SDK

With this update we are releasing a new version of the Azure DevOps Web Extension SDK. The client SDK enables web extensions to communicate to the host frame. It can be used to:

  • Notify the host that the extension is loaded or has errors
  • Get basic contextual information about the current page (current user, host and extension information)
  • Get theme information
  • Obtain an authorization token to use in REST calls back to Azure DevOps
  • Get remote services offered by the host frame

You can find a full API reference in the azure-devops-extension-sdk package documentation. This new version provides support for the following modules:

  • ES Module Support: SDK now supports ES (ECMAScript) modules in addition to the existing AMD (Asynchronous Module Definition) modules. You can now import SDK using the ES module syntax, which provides performance improvements and reduces the application size.

  • Backward Compatibility for AMD Modules: Existing support for AMD modules remains intact. If your project is using AMD modules, you can continue to use them as before without any changes.

How to use:

For ES modules, you can import our modules using the import statement:

import * as SDK from 'azure-devops-extension-sdk';
// Use the module here

If you're using AMD modules, you can continue to import SDK using the require function:

require(['azure-devops-extension-sdk'], function(SDK) {

  // Use the module here
});

Boards

Limits for area and iteration paths

Limits play an important part in maintaining the health and efficiency of a large, global service. With this release, we are introducing hard limits of 10,000 per project for both area and iteration paths. Visit the Work tracking, process, and project limits page to learn more about different limits in the service.

Screenshots of Area and Iteration Paths.

Development and Deployment Controls

We now remove the Development and/or Deployment controls from the work item, depending on how your project is configured. For example, you might configure your project settings to turn off Repos and/or Pipelines.

Screenshots of DevOps services.

When you go to the work item, the corresponding Development and Deployment controls will be hidden from the form.

Screenshots of related work.

If you decide to connect a GitHub repo to Azure Boards, the Development control for GitHub repos will be displayed.

Screenshots of development control .

Repos

New "Branch policy" preventing users to approve their own changes

To improve the control around what changes user approves and match stricter regulatory/compliance requirements, we do provide an option to prevent user approving his own changes unless explicitly allowed.

User with ability to manage the branch policies can now switch newly added option "Require at least one approval on every iteration" under the "When new changes are pushed". When this option is selected, then at least one approval vote for the last source branch change is required. The user's approval is not counted against any previous unapproved iteration pushed by that user. As a result, additional approval on the last iteration is required to be done by another user.

Following image shows pull request created by user A and additional 4 commits (iterations) made to that pull request by users B, C, A again and C. After the second iteration (commit done by user B) was done, user C approved that. At that time, it implied approval of first commit of user A (when the pull request was created) and the newly introduced policy will succeed. After the fifth iteration (last commit of user C), the approval was done by user A. This implied approval for earlier commit done by user C, but was not implying approval for the second commit done by user A in the fourth iteration. To make the newly introduced policy to succeed, the unapproved iteration four must be approved either by approval from user B, C or any other user who has not made any change to the pull request.

Permission management image.

Note

There is a known issue where branch policies will take a group, that is configured as a reviewer, as approving entity. Let's imagine there's a required approval done by any user of Group G. User A is member of that Group G. After User A provides approval as in the image above (after fifth iteration), then the Group G approval approves the change done by User A. This is not expected and will be resolved in the RTW release.

Blobless and treeless filter support

Important

The feature is disabled by default. To enable the feature, please execute the following query on Config DB:

exec prc_SetRegistryValue 1,'#\FeatureAvailability\Entries\Git.EnablePartialClone\AvailabilityState\', 1

Azure DevOps now supports two additional filtering while cloning/fetching. These are: --filter=blob:none and --filter=tree:0 The first option (blobless clone) is best used for regular development while the second option (treeless clone) fits better for those cases where you discard of the clone after, for example running a build.

SSH-RSA deprecation

Azure Repos provides two methods for users to access a git repository in Azure Repos – HTTPS and SSH. To use SSH, you need to create a key pair using one of the supported encryption methods. In the past, we’ve been supporting only SSH-RSA and we’ve asked users to enable the SSH-RSA here.

With this update, we're announcing the deprecation of SSH-RSA as a supported encryption method for connecting to Azure Repos using SSH. You can see more details in the End of SSH-RSA support for Azure Repos blog post.

Pipelines

Prevent unintended pipeline runs

Today, if your YAML pipeline doesn't specify a trigger section, it runs for any changes pushed to its repository. This can create confusion as to why a pipeline ran and lead to many unintended runs.

We added a project collection- and project-level Pipelines setting named Disable implied YAML CI trigger that lets you change this behavior. You can choose to not trigger pipelines if their trigger section is missing.

Screenshot of YAML CI trigger.

Retry a stage when approvals and checks time out

When approvals and checks time out, the stage they belong to is skipped. Stages that have a dependency on the skipped stage are also skipped.

Now you can retry a stage when approvals and checks time-out. Previously, this was possible only when an approval timed out.

Screenshot of stage retry.

Bypass Approvals and Checks

Approvals and checks help protect access to important resources, such as service connections, repos, or agent pools. A common use case is to use Approvals and Checks when deploying to production, and you wish to protect the ARM service connection.

Say you added the following checks on the service connection: an Approval, a Business Hours check, and an Invoke Azure Function check (to enforce a delay between different regions).

Now, imagine you have to do a hotfix deployment. You start a pipeline run, but it doesn't proceed,it waits for most of the checks to complete. You cannot afford to wait for the approvals and checks to complete.

With this release we've made it possible to bypass running approvals and checks, so you can complete your hotfix.

You can bypass running Approvals, Business Hours, Invoke Azure Function, and Invoke REST API checks.

Bypass an Approval.

Screenshot of Bypass an Approval.

Bypass Business Hours check.

Screenshot of Bypass Business Hours check.

Bypass Invoke Azure Function check. Bypass Business Hours check.

Screenshot of Bypass Invoke Azure Function check.

When a check is bypassed, you can see it in the checks panel.

Screenshot of check bypassed.

You can bypass a check only if you're an Administrator of the resource on which the checks were defined.

Screenshot of required YAML template.

Rerun invoke Azure function checks

Imagine that you deploy your system in multiple stages. Before deploying the second stage, there's an Approval and an Invoke Azure Function check that runs a sanity check on the already-deployed part of the system.

When reviewing the Approval request, you notice the sanity check ran two days earlier. In this scenario, you may be aware of another deployment that affected the result of the sanity check.

With this update, you can rerun Invoke Azure Function and Invoke REST API checks. This functionality is available only for checks that succeeded and have no retries.

Screenshot of dynamic check.

Note

You can rerun a check only if you are an Administrator of the resource on which the checks were defined.

Support for GitHub enterprise server in required template check

Templates are a security mechanism that enables you to control the stages, jobs, and steps of pipelines in your project collection.

The Require template check enables you to enforce that a pipeline extends from a set of approved templates before accessing a protected resource, such as an agent pool or service connection.

You can now specify templates located in GitHub Enterprise Server repos.

Administrator role for all Environments

Environments in YAML pipelines represent a compute resource to which you deploy your application, for example an AKS cluster or a set of VMs. They provide you with security controls and traceability for your deployments.

Managing environments can be quite challenging. This is because, when an environment is created, the person creating it automatically becomes the sole administrator. For example, if you want to manage the approvals and checks of all environments in a centralized fashion, you had to ask every environment administrator to add a specific user or group as administrator, and then use REST API to configure the checks. This approach is tedious, error-prone, and doesn't scale when new environments are added.

With this release, we added an Administrator role at the environments-hub level. This brings environments up to par with service connections or agent pools. To assign the Administrator role to a user or group, you need to already be an environments-hub administrator or project collection-owner.

Screenshot of Administrator role.

A user with this Administrator role can administer permissions, manage, view and use any environment. This includes opening up environments to all pipelines.

When you grant a user Administrator role at environments-hub level, they become administrators for all existing environments and for any future environments.

Improved YAML validation

To verify your YAML syntax is correct, you can use the Azure Pipelines web editor's Validate functionality. Thus, it's important that this functionality catch as many YAML issues as possible.

Screenshot of YAML validation.

YAML validation is now more thorough when it comes to expressions.

When writing YAML pipelines, you can use functions to define variable values.

Imagine you define the following variables:

variables:
  Major: '1'
  Minor: '0'
  Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]

The Patch variable is defined using the counter function and the other two variables. In the YAML code above, the word format is misspelt. Previously, this error went undetected. Now, the Validate functionality will detect this and surface an error message.

Screenshot of incorrect variable definitions detected .

Azure Pipelines will detect incorrect variable definitions at pipeline / stage / job level.

In YAML pipelines, you can skip the execution of stage using conditions. Typos can show up here as well, like in the following example.

steps:
- task: NuGetCommand@2
  condition: eq(variable.Patch, 0)
  inputs:
    command: pack
    versioningScheme: byPrereleaseNumber
    majorVersion: '$(Major)'
    minorVersion: '$(Minor)'
    patchVersion: '$(Patch)'

The NuGetCommand task executes only if the value of the Patch variable is 0. Again, there's a typo in the condition, and the Validate functionality will display it.

Screenshot of Patch variable.

Azure Pipelines will detect incorrect YAML conditions defined at pipeline / stage / job level.

REST APIs for Environments

An Environment is a collection of resources that you can target with deployments from a pipeline. Environments provide you with deployment history, traceability for work items and commits, and access control mechanisms.

We know you want to create environments programmatically, so we published documentation for their REST API.

Improvements to Approvals REST API

We improved locating approvals assigned to a user by including the groups the user belongs to in the search results.

Approvals now contain information about the pipeline run they belong to.

For example, the following GET REST API call https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending returns

{
    "count": 1,
    "value":
    [
        {
            "id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
            "steps":
            [],
            "status": "pending",
            "createdOn": "2023-11-09T10:54:37.977Z",
            "lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers":
            [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
                }
            },
            "pipeline":
            {
                "owner":
                {
                    "_links":
                    {
                        "web":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
                        },
                        "self":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
                        }
                    },
                    "id": 73222930,
                    "name": "20231109.1"
                },
                "id": "4597",
                "name": "FabrikamFiber"
            }
        }
    ]
}

Pipeline logs now contain resource utilization

Azure pipeline logs can now capture resource utilization metrics such as memory, CPU usage and available disk space. The logs also include resources used by the pipeline agent and child processes including tasks run in a job.

Screenshot of logs including resources used by the pipeline.

If you suspect your pipeline job may run into resource constraints, enable verbose logs to have resource utilization information injected into pipeline logs. This works on any agent, independent from hosting model.

Azure Pipelines agent now supports Alpine Linux

The Pipeline agent v3.227 now supports Alpine Linux versions 3.13 and above. Alpine Linux is a popular for container (base) image. You can find the agent on the releases page. Alpine Linux versions of the agent have a prefix vsts-agent-linux-musl e.g. vsts-agent-linux-musl-x64-3.227.1.tar.gz.

Azure Pipelines tasks use Node 16

Tasks in the pipeline are executed using a runner, with Node.js used in most cases. Azure Pipelines tasks that utilize a Node as a runner now all use Node 16. As Node 16 is the first Node version to natively support Apple silicon, this also completes full task support for macOS on Apple silicon. Agents running on Apple silicon do not need Rosetta to run.

As the Node 16 end-of-life date has moved forward, we have started the work to run tasks with Node 20.

Increased Azure Pipeline limits to align with the 4 MB maximum Azure Resource Manager (ARM) template size.

You can use the Azure Resource Manager Template Deployment task to create Azure infrastructure. In response to your feedback, we have increased the Azure Pipelines integration limit of 2 MB to 4 MB. This will align with the ARM Templates maximum size of 4 MB resolving size constraints during integration of large templates.

AzureRmWebAppDeployment task supports Microsoft Entra ID authentication

The AzureRmWebAppDeploymentV3 and AzureRmWebAppDeployment@4 tasks have been updated to support App Service with basic authentication disabled. If basic authentication is disabled on the App Service, the AzureRmWebAppDeploymentV3/4 tasks use Microsoft Entra ID authentication to perform deployments to the App Service Kudu endpoint. This requires a recent version of msdeploy.exe installed on the agent, which is the case on the windows-2022/windows-latest Hosted agents (see task reference).

Disabled override of code coverage policy status to Failed when build is failing

Previously in, the code coverage policy status was overridden to 'Failed' if your build in PR was failing. This was a blocker for some of you who had the build as an optional check and the code coverage policy as a required check for PRs resulting in PRs being blocked.

Screenshot of PRs blocked.

Now, the code coverage policy won't be overridden to 'Failed' if the build fails. This feature will be enabled for all customers.

Screenshot of results after change.

Artifacts

Introducing Azure Artifacts support for Cargo Crates

We're excited to announce that Azure Artifacts now offer native support for Cargo crates. This support includes feature parity with respect to our existing protocols, in addition to crates.io being available as an upstream source. Rust developers and teams can now consume, publish, manage, and share their Cargo crates seamlessly, all while using Azure's robust infrastructure and staying in the familiar Azure DevOps environment.

Deprecation announcement for NuGet Restore v1 and NuGet Installer v0 pipeline tasks

If you're using the NuGet Restore v1 and NuGet Installer v0 pipeline tasks, promptly transition to the NuGetCommand@2 pipeline task. You'll begin receiving alerts in your pipelines soon if the transition hasn't been made. If no action is taken, starting November 27, 2023, your builds will result in failure.

Azure Artifacts support for npm audit

Azure Artifacts now supports npm audit and npm audit fix commands. This feature enables users to analyze and fix their project's vulnerabilities by automatically updating insecure package versions. To learn more visit, Use npm audit to detect and fix package vulnerabilities.

Reporting

New Dashboard directory experience

We've listened to your feedback and are thrilled to introduce the new Dashboard directory experience. It not only features a modern UI design but also enables you to sort by each column, with the addition of the Last Configured column. This column will provide you with better insights into overall dashboard usage within your project collection. Additionally, you can now filter by team or project-level dashboards, allowing you to access only the list of what you need to see while hiding the dashboards you don’t want to view.

Gif to demo new Dashboard directory.

Try it now and let us know what you think in our Azure DevOps community

Work item filtering

We are happy to announce work item chart filtering. This feature will let you hover over your work item chart for a quick overview and drill down into specific chart segments for detailed insights. You no longer need to create custom queries to access the exact piece of data you need. You can now dive into your work items in work item charts in a few clicks.

Gif to demo work item filtering.

Your feedback is invaluable in shaping the future of this feature. Try it now and let us know what you think in our Azure DevOps community.

Code Coverage results for folders

Results for code coverage are now available for every individual file and folder rather than only as a top-level number. The code coverage view appears when the Folder view mode button is toggled. In this mode you can drill down and see the code coverage for that selected subtree. Use the toggle button to switch between the new and old views.

Multiple repository widget to GA

Test Plans

Quick Copy and Import with Test Plan or Suite ID

You can now handle multiple test plans in Azure Test Plans with ease! Recognizing the challenges previously faced with long dropdown menus for importing, copying, or cloning test cases—especially for extensive plans or suites—we've taken steps to streamline your workflow.

We're excited to announce the Test Plan and Suite ID Search feature. Enter your Test Plan or Suite ID for swift importing or copying of Test Cases without any delays. This update is part of our ongoing commitment to improve your test management experience, making it more intuitive and less time-consuming.

Gif to demo Test Plan, Suite ID search details.

Update for Azure Test Runner

We're excited to share that Azure Test Runner has been updated to a newer version. This update improves stability and performance, allowing you to run your tests without interruptions or delays. The older version of Azure Test Runner is no longer supported. For the best performance and dependability of your testing operations, we recommend that you update to the newest version as soon as possible.

What's New?

  • Enhanced Stability and Performance: We've made significant improvements to the Test Runner, addressing issues some users experienced. This upgrade ensures a more reliable testing process, minimizing disruptions to your work.
  • Upgrade Prompt: To make the transition to the new version seamless, you'll encounter a prompt to upgrade. This ensures everyone can easily move to the improved version at your convenience, enhancing compatibility and performance.

Screenshots of upgrade prompt.

Feedback

We would love to hear from you! You can report a problem or provide an idea and track it through Developer Community and get advice on Stack Overflow.

Top of Page