Azure DevOps Server 2022 Update 2 发行说明


| 开发人员社区 | 系统要求和兼容性 | 许可条款 | DevOps 博客 | SHA-256 哈希 |


在本文中,你将找到有关 Azure DevOps Server 最新版本的信息。

若要详细了解如何安装或升级 Azure DevOps Server 部署,请参阅

若要下载 Azure DevOps Server 产品,请访问 Azure DevOps Server 下载页

Azure DevOps Server 2019 或 Team Foundation Server 2015 或更高版本支持直接升级到 Azure DevOps Server 2022 Update 2。 如果 TFS 部署在 TFS 2013 或更早版本上,则需要在升级到 Azure DevOps Server 2022 之前执行一些临时步骤。 有关详细信息,请参阅 “安装”页


Azure DevOps Server 2022 Update 2 Patch 6 发布日期:2025 年 6 月 10 日

文件 SHA-256 哈希
devops 2022.2 补丁 6 B0B42C0085045C0B8B8B60C1ECB6D157734758AA24D6A3040A9B57770401A55D

我们发布了 补丁 6,适用于 Azure DevOps Server 2022 更新2,包含以下测试计划的增强功能:

  • 在 XLSX 中使用自定义列导出测试用例

通过此修补程序,测试计划支持使用自定义列导出测试用例,从而更灵活地控制共享和分析的数据。 此增强功能可帮助你根据需要定制导出,确保导出的信息相关且可作。

  • 仅在搜索中使用计划 ID 和套件 ID 导入套件并复制测试用例。

Azure DevOps Server 2022 Update 2 Patch 5 发布日期:2025 年 4 月 8 日

文件 SHA-256 哈希
devops2022.2patch5 299AC29F15BC254167C2987450EF722B083594AFA885A8DAB46625C92D982C1C

我们发布了 Azure DevOps Server 2022 Update 2 的修补程序 5,其中包括:

重要

在 Pipelines 博客中,关于代理的 CDN 域 URL 变更提供了在安装此修补程序之前需要遵循的步骤。

  • 以前,Azure DevOps 代理使用了带有终结点 vstsagentpackage.azureedge.net 的 Edgio CDN。 作为 Edgio 停用的一部分,该 *.azureedge.net 域即将停用。 为了确保持续的可用性,我们已使用新的终结点 download.agent.dev.azure.com迁移到 Akamai 支持的 CDN。 此修补程序包括从新的 CDN 终结点提取代理二进制文件所需的更改,从而逐步迁移离以前的 CDN 终结点。

Azure DevOps Server 2022 Update 2 修补程序 4 发布日期:2025 年 3 月 11 日

文件 SHA-256 哈希
devops2022.2patch4 975B0FC28737C15BA40D6E084663D1A735A66FA821EB40C7A377AE3D58F0C7DA

我们发布了 Azure DevOps Server 2022 Update 2 的修补程序 4,其中包括:

Azure DevOps Server 2022 Update 2 修补程序 3 发布日期:2025 年 2 月 11 日

注意

在 2025 年 2 月 24 日星期一,我们重新发布了 Azure DevOps Server 2022.2 的修补程序 3。 如果以前安装了此修补程序的早期版本,请使用提供的链接更新它。 此重新发布解决了导致 YAML 管道失败的问题。 有关此问题的更多详细信息,请参阅 开发人员社区

文件 SHA-256 哈希
devops2022.2patch3 F5C2DA846B8A38A1FB55D1EB555FB2FD6B974B0436F573CC01A0FEBAF3D67521

我们发布了 Azure DevOps Server 2022 Update 2 的修补程序 3,其中包括:

Azure DevOps Server 2022 Update 2 补丁 2 发布日期:2024 年 11 月 12 日

文件 SHA-256 哈希
devops2022.2patch2.exe 70930BE091607B490890A48C250DAB6C2087F7F610CC695C9C632C679A491D23

我们已为 Azure DevOps Server 2022 Update 2 发布了 修补程序 2,旨在升级一个存在安全漏洞的依赖项。

Azure DevOps Server 2022.2 RTW 发布日期:2024 年 7 月 9 日

Azure DevOps Server 2022.2 RTW 中的新增功能摘要

注意

我们重新发布了 Azure DevOps Server 2022.2,以解决加载 Teams 名称的问题。 此问题已在 Azure DevOps Server 2022.2 RTW 中报告,现已提供博客文章。 如果已安装 7 月 9 日发布的 Azure DevOps Server 2022.2 版本,则可以 安装 Azure DevOps Server 2022.2 的修补程序 1 来解决此问题。 如果要首次安装 Azure DevOps Server 2022.2,则不需要修补程序 1,因为下载链接已更新为包含修补程序。

Azure DevOps Server 2022.2 RTW 是一个包含 bug 修复的汇总更新。 它包括以前发布的 Azure DevOps Server 2022.2 RC 中的所有功能。 可以直接安装 Azure DevOps Server 2022.2 或从 Azure DevOps Server 2020、2019 或 Team Foundation Server 2015 或更高版本升级。 此版本解决了以下问题和漏洞:

Azure DevOps Server 2022 Update 2 RC 发布日期:2024 年 5 月 7 日

Azure DevOps Server 2022.2 RC 包含许多新功能。 其中一些重要内容包括:

还可以跳转到各个部分,查看每个服务的所有新功能:


一般

发布测试结果任务

现在,“发布测试结果”任务支持 JUnit 报告格式的测试运行附件。

Azure DevOps Web 扩展 SDK 的新版本

通过此更新,我们将发布新版本的 Azure DevOps Web 扩展 SDK。 客户端 SDK 使 Web 扩展能够与主机帧通信。 它可用于:

  • 通知主机扩展已加载或出错
  • 获取有关当前页的基本上下文信息(当前用户、主机和扩展信息)
  • 获取主题信息
  • 获取用于在 REST 调用中对 Azure DevOps 进行操作的授权令牌
  • 获取由主机框架提供的远程服务

可以在 azure-devops-extension-sdk 包文档中找到完整的 API 参考。 此新版本提供对以下模块的支持:

  • ES 模块支持: SDK 现在除了现有的 AMD(异步模块定义)模块外,还支持 ES (ECMAScript) 模块。 现在,可以使用 ES 模块语法导入 SDK,该语法提供性能改进并减少应用程序大小。

  • AMD 模块的向后兼容性: 对 AMD 模块的现有支持保持不变。 如果项目使用的是 AMD 模块,可以像以前一样继续使用它们,而无需进行任何更改。

如何使用:

对于 ES 模块,您可以使用 import 语句导入我们的模块:

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

如果使用 AMD 模块,可以使用函数 require 继续导入 SDK:

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

  // Use the module here
});

板块

区域和迭代路径的限制

限制在维护大型全球服务的运行状况和效率方面起着重要作用。 在此版本中,我们将针对区域和迭代路径引入每个项目的 10,000 个硬性限制。 访问 “工作跟踪”、“流程”和“项目限制 ”页,详细了解服务中的不同限制。

区域和迭代路径的屏幕截图。

开发和部署控制

现在,根据项目的配置方式,从工作项中删除开发和/或部署控件。 例如,可以将项目设置配置为关闭 Repos 和/或 Pipelines。

DevOps 服务的屏幕截图。

当您打开该工作项时,相应的开发和部署控件将在窗体中被隐藏。

相关工作的屏幕截图。

如果决定 将 GitHub 存储库连接到 Azure Boards,则会显示 GitHub 存储库的开发控件。

开发控件的屏幕截图。

Repos

新的“分支策略”阻止用户批准自己的更改

为了改进对用户批准和符合更严格法规/合规要求的更改的控制,我们提供了一个选项,除非明确允许,否则用户不能批准自己的更改。

拥有管理分支策略权限的用户现在可以在“推送新更改时”选项下,切换新添加的选项“每次迭代至少需要一次批准”。 选择此选项后,至少需要对最后一个源分支更改进行审批投票。 用户的批准不会计入该用户推送的任何先前未经批准的迭代。 因此,另一个用户需要对上次迭代进行额外的批准。

下图显示了用户 A 创建的拉取请求,以及用户 B、C、A 和 C 对该拉取请求进行的其他 4 次提交(迭代)。第二次迭代(用户 B 完成提交)完成后,用户 C 批准了该迭代。 当时,这意味着用户 A 的首次提交(在创建拉取请求时)被认可,并且新引入的策略将会成功。 在第五次迭代(用户 C 的最后一次提交)之后,用户 A 完成了审批。这意味着对用户 C 之前的提交进行了批准,但不表示对用户 A 在第四次迭代中完成的第二次提交的批准。 若要使新引入的策略成功,未经批准的迭代四必须通过用户 B、C 或任何其他尚未对拉取请求进行任何更改的用户批准。

权限管理图片。

注意

存在一个已知问题,即分支策略将一个配置为审阅者的组视为批准实体。 假设 G 组的任何用户都需要批准。用户 A 是该组 G 的成员。在用户 A 如上图中所示(第五次迭代后)提供审批后,组 G 审批将批准用户 A 完成的更改。这并非预期,将在 RTW 版本中解决。

不支持 Blob 和树形结构的筛选器

重要

默认情况下禁用此功能。 若要启用该功能,请在 Config DB 上执行以下查询:

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

Azure DevOps 现在支持克隆/提取时另外两个筛选。 以下是: --filter=blob:none--filter=tree:0 第一个选项(无 Blob 克隆)最适合常规开发,而第二个选项(无树克隆)则更适合于使用后立即丢弃克隆的情况,例如进行构建时。

SSH-RSA 弃用

Azure Repos 为用户访问 Azure Repos 中的 git 存储库提供了两种方法 - HTTPS 和 SSH。 若要使用 SSH,需要使用受支持的加密方法之一创建密钥对。 过去,我们仅支持 SSH-RSA,并要求用户 在此处启用 SSH-RSA。

通过此更新,我们将宣布弃用 SSH-RSA 作为支持使用 SSH 连接到 Azure Repos 的加密方法。 您可以在博客文章《Azure Repos SSH-RSA 支持终止》中查看更多详细信息。

管道

防止意外的管道运行

现在,如果 YAML 管道未指定 trigger 部分,则会针对推送到其存储库的任何更改来运行。 这可能会让人对管道为何运行感到困惑,并导致许多意料之外的运行。

我们添加了一个名为 “禁用隐含 YAML CI 触发器 ”的项目集合和项目级管道设置,可用于更改此行为。 如果缺少管道的触发器部分,可以选择不触发管道。

 YAML CI 触发器的屏幕截图。

审批和检查超时时重新尝试阶段

审批和检查发生超时时,其所属阶段将被跳过。 依赖于已跳过阶段的其他阶段也将被跳过。

现在可以在审批和检查过程超时时重试流程阶段。以前仅在审批超时时,这才可行。

阶段重试的屏幕截图。

跳过审批流程和检查程序

审批和检查 有助于保护对重要资源(例如服务连接、存储库或代理池)的访问。 常见用例是在部署到生产环境时使用审批和检查,并希望保护 ARM 服务连接。

假设你在服务连接上添加了以下检查:审批、工作时间检查和调用 Azure 函数检查(用于在不同区域之间强制实施延迟)。

现在,假设你必须执行一次热修复部署。 启动管道运行后,它不会继续,而是会等待大部分检查完成。 你负担不起等待审批和检查完成。

通过这个版本更新,我们使得绕过正在运行的审批和检查成为可能,这样您就可以完成紧急修补程序。

可以绕过运行审批、工作时间、调用 Azure 函数和调用 REST API 检查。

绕过审批。

绕过审批的屏幕截图。

绕过营业时间检查。

“绕过营业时间”检查的屏幕截图。

绕过对 Azure 函数的调用检查。 绕过营业时间检查。

绕过调用 Azure 函数检查的屏幕截图。

当检查被绕过时,可以在检查面板中看到它。

已绕过检查的屏幕截图。

只有当你是定义检查的资源的管理员时,才能绕过检查。

所需 YAML 模板的屏幕截图。

重新运行 Azure 函数调用检查

假设你在多个阶段部署系统。 在部署第二个阶段之前,会进行审批和调用 Azure 函数的检查,以在已部署的系统部分上运行合理性检查。

查看审批请求时,你会注意到完整性检查在两天前进行。 在这种情况下,你可能知道另一个部署影响了健全性检查的结果。

通过此更新,您可以重新运行对 Azure 函数的调用以及对 REST API 检查功能的调用。 此功能仅适用于成功且没有重试的检查。

动态检查的屏幕截图。

注意

只有当您是定义检查的资源的管理员时,才能重新运行检查。

在必需的模板检查中支持 GitHub 企业服务器

模板 是一种安全机制,可用于控制项目集合中管道的阶段、作业和步骤。

“需要模板检查”功能允许您强制要求管道在访问受保护的资源(例如代理池或服务连接)之前必须扩展自一组已批准的模板。

现在可以指定位于 GitHub Enterprise Server 存储库中的模板。

所有环境的管理员职能

YAML 管道中的环境表示将应用程序部署到的计算资源,例如 AKS 群集或一组 VM。 它们为部署提供安全控制和可跟踪性。

管理环境可能非常具有挑战性。 这是因为,创建环境时,创建环境的人员会自动成为唯一的管理员。 例如,如果要以集中方式管理所有环境的审批和检查,则必须要求每个环境管理员以管理员身份添加特定用户或组,然后使用 REST API 配置检查。 此方法很繁琐,容易出错,并且在添加新环境时无法扩展。

在此版本中,我们在环境中心级别添加了 管理员角色 。 这使环境达到与服务连接或代理池相当的水平。 若要将管理员角色分配给用户或组,需要已是环境中心管理员或项目集合所有者。

管理员角色的屏幕截图。

具有此管理员角色的用户可以管理权限、管理、查看和使用任何环境。 这包括向所有管道开放环境。

在环境中心级别授予用户管理员角色时,它们将成为所有现有环境和任何未来环境的管理员。

改进了 YAML 验证

若要验证 YAML 语法是否正确,可以使用 Azure Pipelines Web 编辑器的 Validate 功能。 因此,此功能必须尽可能多地捕获 YAML 问题。

YAML 验证的屏幕截图。

在表达式方面,YAML 验证现在更为彻底。

编写 YAML 管道时,可以使用 函数 来定义变量值。

假设你定义了以下变量:

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

变量 Patch 是使用 counter 函数和另外两个变量定义的。 在上面的 YAML 代码中,单词 format 拼写错误。 以前,此错误未检测到。 现在, 验证 功能将检测此情况并显示错误消息。

检测到错误的变量定义的屏幕截图。

Azure Pipelines 将在管道/阶段/作业级别检测不正确的变量定义。

在 YAML 管道中,可以使用条件跳过阶段的执行过程。 拼写错误也可以在此处显示,如以下示例所示。

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

仅当变量的值NuGetCommand为 0 时,任务Patch才会执行。 同样,条件中有拼写错误,并且 “验证” 功能将显示它。

Patch 变量的屏幕截图。

Azure Pipelines 将检测管道/阶段/作业级别定义的不正确的 YAML 条件。

适用于环境的 REST API

环境是一个资源集合,您可以将管道中的部署定位于此。 环境提供部署历史记录、工作项和提交的可追踪性,以及访问控制机制。

我们知道你想要 以编程方式创建环境,因此我们发布了其 REST API 的文档。

对审批 REST API 的改进

我们通过在搜索结果中包含用户所属的组,改进了定位分配给用户的审批。

审批现在包含有关其所属管道运行过程的信息。

例如,以下 GET REST API 调用 https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending 返回

{
    "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"
            }
        }
    ]
}

管道日志现在包含资源利用率

Azure 管道日志现在可以捕获资源利用率指标,例如内存、CPU 使用率和可用磁盘空间。 这些日志也包括管道代理和子进程使用的资源信息,其中还包括在作业中运行的任务。

日志的屏幕截图,包括管道使用的资源。

如果怀疑管道作业可能遇到资源约束,请启用 详细日志 以将资源利用率信息注入管道日志。 这适用于独立于托管模型的任何代理。

Azure Pipelines 代理现在支持 Alpine Linux

Pipeline 代理 v3.227 现在支持 Alpine Linux 3.13 及更高版本。 Alpine Linux 是容器基础镜像的流行选择。 可以在 发布 页上找到代理。 Alpine Linux 版本的代理具有前缀 vsts-agent-linux-musl ,例如 vsts-agent-linux-musl-x64-3.227.1.tar.gz

Azure Pipelines 任务使用 Node 16

管道中的任务使用运行器执行,主要情况下使用Node.js。 利用 Node 作为运行程序的 Azure Pipelines 任务现在都使用 Node 16。 由于 Node.js 16 是第一个原生支持 Apple silicon 的 Node.js 版本,它还完成了对 macOS 的完整任务支持。 在 Apple 硅上运行的代理不需要 Rosetta 运行。

考虑到 Node 16 的生命周期结束日期已提前,我们已开始使用 Node 20 运行任务。

增加了 Azure Pipeline 限制,使其与 4 MB 最大 Azure 资源管理器 (ARM) 模板大小保持一致。

可以使用 Azure 资源管理器模板部署 任务创建 Azure 基础结构。 为了响应你的反馈,我们已将 Azure Pipelines 集成限制提高了 2 MB 到 4 MB。 在集成大型模板期间,这将与 ARM 模板的 最大大小为 4 MB 保持一致,从而解决大小限制问题。

AzureRmWebAppDeployment 任务支持Microsoft Entra ID 身份验证

AzureRmWebAppDeploymentV3 和 AzureRmWebAppDeployment@4 任务已更新,以支持 禁用基本身份验证的应用服务。 如果在App 服务上禁用基本身份验证,AzureRmWebAppDeploymentV3/4 任务将使用 Microsoft Entra ID 身份验证来执行到 App 服务 Kudu 终结点的部署。 这需要在代理上安装最近版本的 msdeploy.exe,它在 windows-2022 和最新的 托管代理 上是已满足的条件(请参阅 任务参考)。

禁用了在生成失败时将代码覆盖率策略状态覆盖为“失败”

之前,如果 PR 中的构建失败,则代码覆盖率策略状态将被重写为“失败”。 对于一些将构建设置为可选检查并将代码覆盖率策略设置为必需检查的用户,这成为了一个阻碍因素,导致他们的 PR 被阻止。

被阻止的 PR 的截图。

现在,如果生成失败,代码覆盖率策略不会被设定为“失败”状态。 将为所有客户启用此功能。

更改后的结果的屏幕截图。

文物

引入 Azure Artifacts 对 Cargo Crates 的支持

我们很高兴地宣布,Azure Artifacts 现在为 Cargo 包提供本地支持。 除了 crates.io 作为上游源之外,此支持还包括与我们现有协议的功能对等性。 Rust 开发人员和团队现在可以无缝地使用、发布、管理和共享其 Cargo 箱,同时使用 Azure 的可靠基础结构并保持熟悉的 Azure DevOps 环境。

NuGet 还原 v1 和 NuGet 安装程序 v0 管道任务的弃用公告

如果使用 NuGet 还原 v1 和 NuGet Installer v0 管道任务,请立即转换为 NuGetCommand@2 管道任务。 如果尚未进行转换,那么您很快会在流水线中收到警报。 如果未采取任何措施,从 2023 年 11 月 27 日开始,您的构建将会失败。

Azure Artifacts 对 npm 审核的支持

Azure Artifacts 现在支持 npm auditnpm audit fix 命令。 此功能使用户能够通过自动更新不安全的包版本来分析和修复其项目的漏洞。 若要了解详细信息, 请使用 npm 审核来检测和修复包漏洞

报告

新的控制面板目录体验

我们已听取你的反馈,并很高兴推出新的仪表板目录体验。 它不仅具有新式 UI 设计,而且还使你可以按每列进行排序,同时添加 “上次配置 ”列。 此列将为你提供对项目集合中整体仪表板使用情况的更深入的见解。 此外,现在可以按团队或项目级仪表板进行筛选,这样您可以访问仅需查看的内容列表,同时隐藏不想查看的仪表板。

GIF 用于演示新的仪表板目录。

立即试用,让我们了解你在 Azure DevOps 社区中的想法

工作项筛选

我们很高兴地宣布 工作项图表筛选。 此功能可让你将鼠标悬停在工作项图表上,以便快速概述并向下钻取到特定图表段以获取详细见解。 不再需要创建自定义查询来访问所需的确切数据片段。 现在,只需单击几下鼠标即可深入了解工作项图表中的工作项。

用于演示工作项筛选的 Gif。

你的反馈对于塑造此功能的未来非常有用。 立即试用,让我们了解 你在 Azure DevOps 社区中的想法。

文件夹的代码覆盖率结果

代码覆盖率的结果现在可用于每个单独的文件和文件夹,而不仅仅是顶级数字。 切换 文件夹视图模式 按钮时,将显示代码覆盖率视图。 在此模式下,可以向下钻取并查看所选子树的代码覆盖率。 使用切换按钮在新视图和旧视图之间切换。

多个存储库控件到 GA

测试计划

使用测试计划或测试套件 ID 快速复制和导入

现在可以轻松处理 Azure 测试计划中的多个测试计划! 认识到以前在导入、复制或克隆测试用例(尤其是对于大量计划或套件)时遇到的长下拉菜单面临的挑战,我们已采取措施简化工作流。

我们很高兴地宣布推出“测试计划”和“套件 ID”的搜索功能。 输入测试计划或套件 ID 以快速导入或复制测试用例,而不会有任何延迟。 此更新是我们持续致力于改进测试管理体验的一部分,旨在使其更直观、更省时。

Gif 用于展示测试计划和套件 ID 搜索的详细信息。

Azure Test Runner 更新

我们很高兴地分享 Azure 测试运行程序已更新到较新版本。 此更新可提高稳定性和性能,使你能够在不中断或延迟的情况下运行测试。 不再支持较旧版本的 Azure 测试运行程序。 为了获得测试操作的最佳性能和可靠性,建议尽快更新到最新版本。

新增功能

  • 增强的稳定性和性能: 我们对测试运行程序进行了重大改进,解决了一些用户遇到的问题。 此升级可确保更可靠的测试过程,最大限度地减少工作中断。
  • 升级提示: 若要无缝过渡到新版本,你将遇到升级提示。 这可确保每个人都可以在方便时轻松迁移到改进的版本,从而提高兼容性和性能。

升级提示的屏幕截图。


反馈

我们期待你的宝贵意见和建议! 你可以报告问题或提供想法,并通过 开发人员社区 跟踪它,并获取 有关 Stack Overflow 的建议。


页面顶部