Azure DevOpsServer 2020 Update 1 发行说明

项目
11/12/2024

| 开发者社区System 要求 | 许可条款 | DevOps 博客 | SHA-1 哈希

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

若要详细了解如何安装或升级 Azure DevOps Server 部署，请参阅 Azure DevOps Server 要求。若要下载 Azure DevOps 产品，请访问 Azure DevOps Server 下载页。

Azure DevOps Server 2019 或 Team Foundation Server 2015 或更高版本支持直接升级到 Azure DevOps Server 2020。如果在 TFS 2010 或更低版本上进行 TFS 部署，需要先执行一些中间步骤，再升级到 Azure DevOps Server 2019。若要了解详细信息，请参阅在本地安装和配置 Azure DevOps。

安全地从 Azure DevOps Server 2019 升级到 Azure DevOps Server 2020

Azure DevOps Server 2020 引入了基于项目级设置的新管道运行（生成）保留模型。

Azure DevOps Server 2020 根据管道级保留策略以不同的方式处理生成保留。某些策略配置会导致升级后删除管道运行。升级后，不会删除手动保留或由发布保留的管道运行。

阅读我们的博客文章，详细了解如何安全地从 Azure DevOps Server 2019 升级到 Azure DevOps Server 2020。

Azure DevOps Server 2020 Update 1.2 修补程序 14 发布日期：2024 年 11 月 12 日

文件	SHA-256 哈希
devops2020.1.2patch14.exe	29012B79569F042E2ED4518CE7216CA521F9435CCD80295B71F734AA60FCD03F

我们发布了 Azure DevOps Server 2020 Update 1.2 的修补程序 14 ，以包括升级到易受攻击的依赖项。

Azure DevOps Server 2020 Update 1.2 修补程序 13 发布日期：2024 年 3 月 12 日

文件	SHA-256 哈希
devops2020.1.2patch13.exe	55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

我们发布了 Azure DevOps Server 2020 Update 1.2 的修补程序 13 ，其中包括以下修补程序：

解决了安装 Patch 12 后代理服务器停止工作的问题。

Azure DevOps Server 2020 Update 1.2 修补程序 12 发布日期：2024 年 2 月 13 日

文件	SHA-256 哈希
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

我们发布了适用于 Azure DevOps Server 2020 Update 1.2 的修补程序 12 ，其中包括以下修补程序：

修复了代理缓存文件夹使用的磁盘空间不正确且文件夹未正确清理的 bug。
CVE-2024-20667：Azure DevOps Server 远程代码执行漏洞。

Azure DevOps Server 2020 Update 1.2 修补程序 11 发布日期：2023 年 12 月 12 日

文件	SHA-256 哈希
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

我们发布了适用于 Azure DevOps Server 2020 Update 1.2 的修补程序 11 ，其中包括以下修补程序：

修复了部署审批安全继承未在管道阶段工作的 bug。

Azure DevOps Server 2020 Update 1.2 修补程序 10 发布日期：2023 年 11 月 14 日

我们发布了 Azure DevOps Server 2020 Update 1.2 的修补程序，其中包括以下修补程序。

扩展了 PowerShell 任务允许对 Enable shell 任务参数参数验证的字符列表。

注意

若要实现此修补程序的修补程序，必须执行许多步骤来手动更新任务。

安装修补程序

重要

我们发布了 Azure Pipelines 代理的更新，修补程序 8 于 2023 年 9 月 12 日发布。如果未按照修补程序 8 的发行说明中所述安装代理更新，建议在安装修补程序 10 之前安装这些更新。安装 Patch 8 后的新版本为 3.225.0。

配置 TFX

遵循将任务上传到项目集合文档中的步骤进行安装，然后使用 tfx-cli 登录。

使用 TFX 更新任务

文件	SHA-256 哈希
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

下载并提取 Tasks20231103.zip。
切换到解压缩后的文件所在的目录。
执行以下命令以上传任务：

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip

管道要求

若要使用新行为，必须在使用受影响任务的管道中设置变量 AZP_75787_ENABLE_NEW_LOGIC = true。

在经典版上：

在管道中的变量选项卡上定义变量。
YAML 示例：

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true

Azure DevOps Server 2020 Update 1.2 Patch 9 发布日期：2023 年 10 月 10 日

重要

我们发布了 Azure Pipelines 代理的更新，修补程序 8 于 2023 年 9 月 12 日发布。如果未按照修补程序 8 的发行说明中所述安装代理更新，建议在安装修补程序 9 之前安装这些更新。安装 Patch 8 后的新版本为 3.225.0。

我们发布了一个修补程序。适用于 Azure DevOps Server 2020 Update 1.2，其中包括以下修补程序。

修复了“分析所有者”标识在修补程序升级计算机上显示为非活动标识的 bug。

Azure DevOps Server 2020 Update 1.2 Patch 8 发布日期：2023 年 9 月 12 日

我们发布了 Azure DevOps Server 2020 Update 1.2 的修补程序，其中包括以下修补程序。

CVE-2023-33136：Azure DevOps Server 远程代码执行漏洞。
CVE-2023-38155：Azure DevOps Server 和 Team Foundation Server 特权提升漏洞。

重要

请将修补程序部署到测试环境，并确保环境的管道按预期工作，然后将修复应用于生产环境。

注意

若要实现此修补程序的修复，必须执行许多步骤来手动更新代理和任务。

安装修补程序

下载并安装 Azure DevOps Server 2020 Update 1.2 修补程序 8。

更新 Azure Pipelines 代理

从以下位置下载代理：https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
使用自托管 Windows 代理文档中所述的步骤部署代理。

注意

必须将 AZP_AGENT_DOWNGRADE_DISABLED 设置为“true”以防止代理降级。在 Windows 上，可以在管理命令提示符下使用以下命令，然后重启。 setx AZP_AGENT_DOWNGRADE_DISABLED true /M

配置 TFX

遵循将任务上传到项目集合文档中的步骤进行安装，然后使用 tfx-cli 登录。

使用 TFX 更新任务

下载并解压 Tasks_20230825.zip。
切换到解压缩后的文件所在的目录。
执行以下命令以上传任务：

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip

管道要求

若要使用新行为，必须在使用受影响任务的管道中设置变量 AZP_75787_ENABLE_NEW_LOGIC = true。

在经典版上：

在管道中的变量选项卡上定义变量。
YAML 示例：

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true

Azure DevOps Server 2020 Update 1.2 Patch 7 发布日期：2023 年 8 月 8 日

我们发布了 Azure DevOps Server 2020 Update 1.2 的修补程序，其中包括以下修补程序。

CVE-2023-36869：Azure DevOps Server 欺骗漏洞。
更新 SSH 服务以支持 SHA2-256 和 SHA2-512。如果 SSH 配置文件硬编码为使用 RSA，则应更新为 SHA2 或删除条目。
解决了在 markdown 文件中无法工作的相对链接的问题。
修复了提交页上的注释导航的 bug。
修复了分析所有者标识显示为非活动标识的 bug。
修复了 CronScheduleJobExtension 上的无限循环 bug。

Azure DevOps Server 2020 Update 1.2 Patch 6 发布日期：2023 年 6 月 13 日

我们发布了 Azure DevOps Server 2020 Update 1.2 的修补程序，其中包括以下修补程序。

CVE-2023-21565：Azure DevOps Server 欺骗漏洞。
CVE-2023-21569：Azure DevOps Server 欺骗漏洞。
修复了从 2018 年或更早版本升级时干扰推送包的 bug。
修复了分离或附加集合失败并报告以下错误：“TF246018：数据库操作超出了超时限制并已取消。

Azure DevOps Server 2020 Update 1.2 Patch 5 发布日期：2023 年 2 月 14 日

我们发布了 Azure DevOps Server 2020 Update 1.2 的修补程序，其中包括以下修补程序。

CVE-2023-21553：Azure DevOps Server 远程代码执行漏洞
修复了通过 Web UI 解决货架辅助功能问题
客户需要在更新 Azure DevOps Server 管理控制台中的 SMTP 相关设置后重启 tfsjobagent 服务和 Azure DevOps Server 应用程序池。

Azure DevOps Server 2020 Update 1.2 Patch 4 发布日期：2022 年 12 月 13 日

我们发布了 Azure DevOps Server 2020 Update 1.2 的修补程序，其中包括以下修补程序。

修复了 IdentityPicker 中特殊字符的显示。

Gif 以演示 IndetityPicker 中的特殊字符。

测试数据未被删除，导致数据库增长。通过此修补程序，我们更新了生成保留期，以防止创建新的孤立测试数据。

Azure DevOps Server 2020 Update 1.2 Patch 3 发布日期：2022 年 10 月 18 日

我们发布了 Azure DevOps Server 2020 Update 1.2 的修补程序，其中包括以下修补程序。

解决新添加的 AD 标识未显示在安全对话标识选取器中的问题。
修复了 Web 挂钩设置中“组成员请求”筛选器的问题。
修复了当管道的组织设置已将作业授权范围配置为将作业授权范围限制为非发布管道的当前项目时，封闭式签入生成错误。
修复了在身份验证代理后面建立服务连接时从 Azure 检索访问令牌的修复。

Azure DevOps Server 2020 Update 1.2 修补程序 2 发布日期：2022 年 8 月 9 日

我们发布了 Azure DevOps Server 2020 Update 1.2 的修补程序，其中包括以下修补程序。

修复了向不同域中显示的标识分配工作项时出现的标识值错误。

Azure DevOps Server 2020 Update 1.2 修补程序 1 发布日期：2022 年 7 月 12 日

我们发布了 Azure DevOps Server 2020 Update 1.2 的修补程序，其中包括以下修补程序。

在测试运行 API 中，返回的延续令牌大于指定的“maxLastUpdatedDate”值。

Azure DevOps Server 2020 Update 1.2 发布日期：2022 年 5 月 17 日

Azure DevOps Server 2020 Update 1.2 是 bug 修复的汇总。可以直接安装 Azure DevOps Server 2020 Update 1.2 或从 Azure DevOps Server 2020 或 Team Foundation Server 2013 或更高版本升级。

注意

此版本发布后大约三周，Azure DevOps Server 2020 Update 1.2 将推出数据迁移工具。可在此处查看当前支持导入的版本的列表。

此版本包括以下修补程序：

Azure DevOps Server 2020.1.2 禁用新的保留模型（在 Azure DevOps Server 2020 中引入），以防止管道运行丢失（生成）。这意味着系统将：
- 为运行 Server 2020 时生成的最近 3 个内部版本创建租约
- 对于没有按管道保留策略的 YAML 管道和经典管道，将根据集合级别的最大保留设置保留生成
- 对于具有自定义每管道保留策略的经典管道，将根据特定于管道的保留策略保留生成
- 具有租约的生成不计入“最小值”以保留设置
更改集和货架集注释链接未正确重定向。将注释添加到更改集或货架集中的文件时，选择这些注释不会重定向到文件视图中的正确位置。
无法使用“运行下一步”按钮跳过生成队列。以前，仅为项目集合管理员启用了“运行下一步”按钮。
禁用用户的 Active Directory 帐户后，撤销所有个人访问令牌。

Azure DevOps Server 2020.1.1 修补程序 4 发布日期：2022 年 1 月 26 日

我们发布了 Azure DevOps Server 2020.1.1 的修补程序，其中包括以下修补程序。

使用 @mention 工作项中的控件时，不会发送电子邮件通知。
用户个人资料中的首选电子邮件地址未更新。这导致了电子邮件发送到之前的电子邮件地址。
“项目摘要”页中未显示页眉。标头显示几毫秒，然后它消失。
Active Directory 用户同步的改进。
通过从 log4j 二进制文件中删除 jndilookup 类来解决 Elasticsearch 漏洞。

安装步骤

使用 Patch 4 升级服务器。
检查 HKLM:\Software\Elasticsearch\Version 的注册表值。如果注册表值不存在，请添加一个字符串值，并将版本设置为 5.4.1 (Name = Version, Value = 5.4.1)。
按照自述文件中的说明运行 update 命令 PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update。它可能会返回类似于下面的警告：无法连接到远程服务器。请勿关闭窗口，因为更新正在执行重试，直到完成。

注意

如果 Azure DevOps Server 和 Elasticsearch 安装在不同的计算机上，请按照下面概述的步骤进行操作。

使用 Patch 4 升级服务器。
检查 HKLM:\Software\Elasticsearch\Version 的注册表值。如果注册表值不存在，请添加一个字符串值，并将版本设置为 5.4.1 (Name = Version, Value = 5.4.1)。
将名为 zip 且位于 C:\Program Files\{TFS Version Folder}\Search\zip 中的文件夹的内容复制到 Elasticsearch 远程文件文件夹。
在 Elasticsearch 服务器计算机上运行 Configure-TFSSearch.ps1 -Operation update。

SHA-256 哈希： 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 修补程序 3 发布日期：2021 年 12 月 15 日

Azure DevOps Server 2020.1.1 的修补程序 3 包括以下修补程序。

修复包含“包含字词”的查询的工作项宏。以前，查询返回包含换行符的值的错误结果。
提高 Maven 包版本字符长度的限制。
自定义工作项布局状态的本地化问题。
电子邮件通知模板中的本地化问题。
为字段定义了多个 NOTSAMEAS 规则时，NOTSAMEAS 规则评估的问题。

Azure DevOps Server 2020.1.1 修补程序 2 发布日期：2021 年 10 月 26 日

Azure DevOps Server 2020.1.1 的修补程序 2 包括以下修补程序。

以前，Azure DevOps Server 只能创建与 GitHub Enterprise Server 的连接。通过此修补程序，项目管理员可以在 Azure DevOps Server 与 GitHub.com 上的存储库之间创建连接。可以在“项目设置”下的“GitHub 连接”页中找到此设置。
解决测试计划小组件的问题。测试执行报告在结果上显示不正确的用户。
修复了无法加载“项目概述”摘要页的问题。
修复了未发送电子邮件以确认产品升级的问题。

Azure DevOps Server 2020.1.1 修补程序 1 发布日期：2021 年 9 月 14 日

Azure DevOps Server 2020.1.1 的修补程序 1 包括以下修补程序。

修复项目下载/上传失败。
解决测试结果数据不一致的问题。

Azure DevOps Server 2020 Update 1.1 发布日期：2021 年 8 月 17 日

Azure DevOps Server 2020 Update 1.1 是 bug 修复的汇总。可以直接安装 Azure DevOps Server 2020 Update 1.1 或从 Azure DevOps Server 2020 或 Team Foundation Server 2013 或更高版本升级。

注意

此版本发布后大约三周，Azure DevOps Server 2020 Update 1.1 将推出数据迁移工具。可在此处查看当前支持导入的版本的列表。

此版本包含对以下 bug 的修复：

Azure Boards

通知电子邮件中的“查看工作项”超链接未使用公共 URL。

Azure Repos

修复了限制合并类型继承复选框的显示，以便在设置跨存储库策略后启用修改限制合并类型。

Azure Pipelines

更改代理更新的设置时，设置不会传播到环境中的其他应用程序层。

常规

修复了服务器配置向导中的拼写问题。
扩展包大小增加，允许更改注册表中的大小。

Azure Test Plans

从历史记录回击到摘要页后，无法导航回测试结果。

Azure DevOps Server 2020.1 修补程序 2 发布日期：2021 年 8 月 10 日

我们发布了 Azure DevOps Server 2020.1 的修补程序，修复了以下内容。

修复生成定义 UI 错误。
更改了浏览历史记录以显示文件而不是根存储库。

Azure DevOps Server 2020.1 修补程序 1 发布日期：2021 年 6 月 15 日

我们发布了 Azure DevOps Server 2020.1 的修补程序，修复了以下内容。

在断言 SameSite=None的授权流中使用的安全 Cookie。
解决通知 SDK 的问题。以前，未正确分析使用“区域路径”筛选器的通知订阅。

Azure DevOps Server 2020.1 RTW 发布日期：2021 年 5 月 25 日

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

Azure DevOps Server 2020.1 RTW 是 bug 修复的汇总。它包括以前发布的 Azure DevOps Server 2020.1 RC2 中的所有功能。 Azure DevOps Server 2020.1 RTW 是 bug 修复的汇总。可以直接安装 Azure DevOps Server 2020.1 或从 Azure DevOps Server 2020、2019 或 Team Foundation Server 2015 或更高版本升级。

注意

此版本发布后大约三周，Azure DevOps Server 2020 Update 1 将推出数据迁移工具。可在此处查看当前支持导入的版本的列表。

Azure DevOps Server 2020.1 RC2 发布日期：2021 年 4 月 13 日

Azure DevOps Server 2020.1 RC2 中的新增功能摘要

Azure DevOps Server 2020.1 RC2 是 bug 修复的汇总。它包括以前发布的 Azure DevOps Server 2020.1 RC1 中的所有功能。

Azure DevOps Server 2020.1 RC1 发布日期：2021 年 3 月 23 日

Azure DevOps Server 2020.1 RC1 中的新增功能摘要

Azure DevOps Server 2020.1 RC1 引入了许多新功能。其中一些重要内容包括：

Boards 中的状态转换限制规则
利益干系人现在可以跨板列移动工作项
通过限制访问令牌的范围来改进版本安全性
增强拉取请求体验
管道中的多存储库触发器

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

Boards
Repos
管道
项目

Boards

状态转换限制规则

我们继续缩小托管 XML 与继承的进程模型之间的功能奇偶校验差距。使用此新的工作项类型规则，可以限制工作项从一个状态移动到另一个状态。例如，可以限制 Bug 从“新建”转到“已解决”。相反，它们必须从“新建 -> 活动” -> “已解决”

还可以创建规则来限制组成员身份的状态转换。例如，只有“审批者”组中的用户才能从“新建 -> 已批准”移动用户情景。

复制工作项以复制子级

Azure Boards 最请求的功能之一是复制同时复制子工作项的工作项。我们向复制工作项对话框添加了“包括子工作项”的新选项。选中此选项后，将复制工作项并复制所有子工作项（最多 100 个）。

本页显示了 Azure Boards 中用于在复制的工作项中包含子工作项的新选项。

改进了已激活和已解析字段的规则

到目前为止，“已激活日期”、“已激活日期”、“已解决日期”和“已解决日期”的规则一直是个谜。它们仅针对系统工作项类型进行设置，特定于“Active”和“Resolved”的状态值。我们已更改逻辑，以便这些规则不再适用于特定状态。相反，它们由状态所在的类别（状态类别）触发。例如，假设你在“已解决”类别中有“需要测试”的自定义状态。当工作项从“活动”更改为“需要测试”时， 将触发“已解决者 ”和 “已解决日期 ”规则。

这样，客户就可以创建任何自定义状态值，并且仍生成“已激活的日期”、“已解决日期”和“已解析日期”字段，而无需使用自定义规则。

利益干系人可以跨板列移动工作项

利益干系人始终能够更改工作项的状态。但是，当他们去看板时，他们无法将工作项从一列移到另一列。相反，利益干系人必须一次打开每个工作项，并更新状态值。对于客户来说，这一直是一个难题，我们很高兴地宣布，现在可以跨板列移动工作项。

积压工作 (backlog) 和板上的系统工作项类型

现在可以将系统工作项类型添加到所选积压工作项级别。从历史上看，这些工作项类型仅在查询中可用。

处理	工作项类型
敏捷	问题
Scrum	障碍
CMMI	更改请求
	问题
	审阅
	风险

将系统工作项类型添加到积压工作级别非常简单。只需进入自定义过程，然后单击 “积压工作级别”选项卡。选择积压工作级别的选择（例如：要求积压工作），然后选择 编辑选项。然后添加工作项类型。

引发 Azure Boards GitHub 应用存储库限制

GitHub 市场中 Azure Boards 应用程序的存储库限制已从 100 增加到 250。

合并拉取请求时自定义工作项状态

并非所有工作流都是相同的。某些客户希望在拉取请求完成后关闭其相关工作项。其他人希望将工作项设置为在关闭之前要验证的另一个状态。我们应该同时允许这两者。

我们提供了一项新功能，可用于在合并和完成拉取请求时将工作项设置为所需状态。为此，我们将扫描拉取请求说明，并查找状态值，然后查找工作项 #mention。在此示例中，我们将两个用户情景设置为“已解决”并关闭两个任务。

将工作项与其他项目中的生成项进行链接

现在，只需将工作项链接到生成、在生成中查找或集成生成，即可轻松跟踪项目中的生成依赖项。

链接工作项

在系统字段上编辑说明（帮助文本）

你一直能够编辑自定义字段的说明。但是，对于优先级、严重性和活动等系统字段，说明不可编辑。这是托管 XML 与 Inherited 之间的功能差距，阻止某些客户迁移到继承的模型。现在可以编辑系统字段的说明。编辑的值只会影响进程中的该字段以及该工作项类型。这样，便可以灵活地在不同的工作项类型上为同一字段提供不同的说明。

编辑说明

合并拉取请求时自定义工作项状态

拉取请求通常引用多个工作项。创建或更新拉取请求时，可能需要关闭其中一些内容，解决其中一些问题，并使其余部分保持打开状态。现在可以使用下图所示的注释来完成此操作。有关更多详细信息，请参阅文档。

任务板上的父字段

由于常用请求，现在可以将“父”字段添加到任务板上的子卡和父卡。

删除 Bug 工作项类型的“已分配”规则

敏捷、Scrum 和 CMMI 中所有不同工作项类型都有多个隐藏的系统规则。这些规则已经存在了十多年，一般没有投诉就罚款了。然而，有几个规则已经耗尽了他们的欢迎。特别是一条规则给新客户和现有客户带来了很大的痛苦，我们决定是时候删除它了。此规则存在于敏捷过程中的 Bug 工作项类型上。

“将状态更改为”已解决“时，将分配的值设置为”创建者”

我们收到了有关此规则的大量反馈。作为响应，我们继续从敏捷过程中的 Bug 工作项类型中删除此规则。此更改将影响使用继承的敏捷或自定义继承的敏捷过程的每个项目。对于喜欢并依赖此当前规则的客户，请参阅我们的博客文章，了解使用自定义规则重新添加规则所要执行的步骤。

工作项页上删除的项

“ 工作项”页是一个很好的位置，可用于快速查找已创建或分配给你的项，等等。它提供多个个性化透视和筛选器。 “分配给我”透视的一大投诉是它显示“已删除的工作项”（即“已删除”状态的工作项）。我们同意！已删除的项目是不再值的工作，因此已从积压工作中删除，因此，将此项包含在此视图中并不有用。

现在可以在“工作项”页上隐藏“已分配给我”的所有已删除项目。

Repos

默认分支名称首选项

Azure Repos 现在提供 Git 的可自定义默认分支名称。在存储库设置中，可以选择初始化存储库时要使用的任何法定分支名称。 Azure Repos 始终支持更改现有存储库的默认分支名称。

有关详细信息，请参阅“管理分支”和“更改默认分支。

默认分支的组织级别设置

现在，新存储库的首选初始分支名称有一个集合级设置。如果项目尚未选择初始分支名称，则将使用此组织级设置。如果未在组织设置或项目设置中指定初始分支名称，则新存储库将使用 Azure DevOps 定义的默认值。

添加一个新的身份验证范围用于处理 PR 注释

此版本添加了一个新的 OAuth 范围，用于读取/写入拉取请求注释。如果你有一个机器人或自动化，它只需要与注释交互，则可以为它提供一个仅具有此范围的 PAT。如果自动化有 bug 或令牌遭到入侵，则此过程会减少爆炸半径。

拉取请求体验改进

新的拉取请求体验已得到改进，如下所示：

使可选检查更加可见

客户使用可选检查来引起开发人员对潜在问题的注意。在前面的体验中，当这些检查失败时，它过去是显而易见的。但是，在预览体验中，情况并非如此。所需检查上的大绿色复选标记会屏蔽可选检查中的失败。用户只能通过打开检查面板来发现可选检查失败。当没有问题的迹象时，开发人员不会经常这样做。在此部署中，我们在摘要中使可选检查的状态更加明显。

显示可选检查

在菜单项上单击 Ctrl

PR 上的选项卡菜单不支持 Ctrl-click。用户经常在查看拉取请求时打开新的浏览器选项卡。此问题已修复。

[+] 批注的位置

PR 中文件的树列表显示注释 [+] 以帮助作者和审阅者识别新文件。由于批注是在省略号之后，因此在较长的文件名中通常不可见。

显示批注的位置

PR 更新下拉列表重新获取计时信息

用于选择更新和比较 PR 中的文件的下拉列表在预览体验中丢失了重要元素。它未显示该更新的创建时间。此问题已修复。

PR 更新下拉列表中缺少计时信息

**改进的注释筛选器布局 **

筛选拉取请求摘要页上的注释时，下拉列表位于右侧，但文本左对齐。此问题已修复。

改进了注释筛选器布局

导航到父提交

在“提交”页下，可以将特定提交中所做的更改与其父提交进行比较。但是，你可能想要导航到父提交，并进一步了解该提交与其自己的父级有何不同。当你想要了解发布中的所有更改时，通常需要这样做。我们向提交添加了一张家长卡片，以帮助你实现此目的。

导航到父提交

PR 文件选项卡中有更多空间用于具有长名称的文件夹和文件

由于文件树中缺少水平间距，具有长名称的文件夹和文件被切断。我们通过修改树的缩进来与根节点匹配，并从页面上隐藏省略号按钮（悬停时除外）来恢复树中的一些额外空间。

新文件树的图像：

文件夹和文件的更多空间

将鼠标悬停在目录上时文件树的图像：

名称显示

在 PR 文件选项卡中调整差异窗格大小时保留滚动位置

在 PR 文件选项卡中调整并排差异窗格的大小时，用户的滚动位置将丢失。此问题已修复;用户滚动位置现在保留在差异窗格大小上。

在移动设备上搜索提交

在移动设备上查看“提交”页面时，新体验中缺少搜索框。因此，很难通过哈希找到提交并打开它。现已修复此问题。

在移动设备上搜索提交

对于新的 PR 文件差异移动视图，改进了对空间的使用

我们更新了此页面以更好地利用空间，以便用户可以在移动视图中查看更多文件，而不是使 40% 的屏幕被标头占用。

改进了空间新 PR 文件名的使用

PR 摘要视图中的增强图像

PR 中编辑的图像未显示在 PR 摘要视图中，但在 PR 文件视图中正确显示。此问题已解决。

增强了创建新的 PR 时的分支体验

在此更新之前，此体验并不理想，因为它会将更改与存储库默认分支而不是比较分支进行比较。

分支体验增强

管道

其他代理平台：ARM64

我们向 Azure Pipelines 代理支持的平台列表添加了 Linux/ARM64。尽管代码更改很少，但许多幕后工作必须首先完成，我们很高兴地宣布其发布！

对管道资源的标记筛选器支持

我们现在在 YAML 管道中添加了“标记”。可以使用标记将 CI 管道设置为运行或何时自动触发。

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

上面的代码片段显示，标记可用于确定 CD（持续部署）管道运行未由某些其他源/资源或计划运行触发器触发时要运行的 CI（持续集成）管道的默认版本。

例如，如果已为 CD 管道设置了计划触发器，而仅当 CI 具有生产标记时，触发器部分中的标记可确保仅当 CI 完成事件满足标记条件时才会触发 CD 管道。

控制可在管道中使用哪些任务

现在可以禁用市场任务。其中一些可能允许市场扩展，但不允许它们带来的管道任务。为了获得更多的控制，我们还允许你独立禁用所有现装任务（除了签出，这是一项特殊操作）。启用这两个设置后，允许在管道中运行的唯一任务是使用 tfx 上传的任务。访问 https://dev.azure.com/<your_org>/_settings/pipelinessettings 并查找名为“任务限制”的部分以开始使用。

独占部署锁定策略

通过此更新，可以确保一次只有一个运行部署到环境。通过在环境中选择“独占锁”检查，只会继续运行一次。要部署到该环境的后续运行将暂停。使用独占锁完成的运行后，将继续执行最新的运行。将取消任何中间运行。

在“添加检查”页中，选择“独占锁”以确保一次只部署一个运行部署到环境。

管道资源触发器的阶段筛选器

我们添加了对“阶段”的支持，作为 YAML 中管道资源的筛选器。使用此筛选器，无需等待整个 CI 管道完成以触发 CD 管道。现在可以选择在 CI 管道中完成特定阶段后触发 CD 管道。

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

在 CI 管道中成功完成触发器筛选器中提供的阶段时，会自动为 CD 管道触发新的运行。

YAML 管道的基于 Webhook 的泛型触发器

目前，我们拥有各种资源（例如管道、容器、生成和包），可以通过这些资源来使用项目并启用自动触发器。但是，到目前为止，无法基于其他外部事件或服务自动执行部署过程。在此版本中，我们将介绍 YAML 管道中的 Webhook 触发器支持，以便将管道自动化与任何外部服务集成。可以通过其 Webhook（Github、Github Enterprise、Nexus、Aritfactory 等）订阅任何外部事件，并触发管道。

下面是配置 Webhook 触发器的步骤：

在外部服务上设置 Webhook。创建 Webhook 时，需要提供以下信息：
- 请求 URL - “https://dev.azure.com/<ADO collection>/_apis/public/distributedtask/webhooks/<WebHook Name>？api-version=6.0-preview”
- 机密 - 这是可选的。如果需要保护 JSON 有效负载，请提供机密值
创建新的“传入 Webhook”服务连接。这是一种新引入的服务连接类型，可让你定义三个重要信息片段：
- Webhook 名称：Webhook 的名称应与在外部服务中创建的 Webhook 匹配。
- HTTP 标头 - 请求中包含请求验证的有效负载哈希值的请求中的 HTTP 标头的名称。例如，对于 GitHub，请求标头将为“X-Hub-Signature”
- 机密 - 机密用于分析用于验证传入请求的有效负载哈希（这是可选的）。如果在创建 Webhook 时使用了机密，则需要提供相同的密钥
YAML 管道中引入了名为 webhooks 的新资源类型。若要订阅 Webhook 事件，需要在管道中定义 Webhook 资源，并将其指向传入 Webhook 服务连接。还可以根据 JSON 有效负载数据在 Webhook 资源上定义其他筛选器，以进一步自定义每个管道的触发器，并且可以以作业中的变量形式使用有效负载数据。

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

每当传入 Webhook 服务连接收到 Webhook 事件时，将为订阅 Webhook 事件的所有管道触发新的运行。

YAML 资源触发器问题支持和可跟踪性

当管道触发器无法按预期执行时，可能会让人困惑。为了帮助更好地了解这一点，我们在管道定义页中添加了一个名为“触发器问题”的新菜单项，其中显示了有关触发器不执行的原因的信息。

资源触发器由于两个原因而无法执行。

如果所提供的服务连接的源无效，或者触发器中存在任何语法错误，则根本不会配置触发器。这些作为错误浮出水面。
如果触发器条件不匹配，触发器将不会执行。每当发生这种情况时，都会显示警告，以便你可以了解条件不匹配的原因。

多存储库触发器

可以在一个 YAML 文件中指定多个存储库，并导致管道由任何存储库的更新触发。例如，此功能在以下方案中非常有用：

你使用不同存储库中的工具或库。每当更新工具或库时，你都希望为应用程序运行测试。
你将 YAML 文件保存在与应用程序代码不同的存储库中。每次将更新推送到应用程序存储库时，你都希望触发管道。

通过此更新，多存储库触发器仅适用于 Azure Repos 中的 Git 存储库。它们不适用于 GitHub 或 BitBucket 存储库资源。

下面是一个示例，演示如何在管道中定义多个存储库资源，以及如何在所有存储库上配置触发器。

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

如果存在以下任何更新，则会触发此示例中的管道：

main 包含 YAML 文件的存储库中的 self 分支
main 或 release 存储库中的 tools 分支

有关详细信息，请参阅管道中的多个存储库。

已改进代理日志上传

当代理停止与 Azure Pipelines 服务器通信时，它正在运行的作业将放弃。如果碰巧正在查看流式处理控制台日志，则可能在代理停止响应之前，已经获取了一些有关代理情况的线索。但是，如果没有，或者刷新了页面，这些控制台日志就消失了。在此版本中，如果代理在发送完整日志之前停止响应，我们将控制台日志保留为下一个最佳状态。控制台日志限制为每个行 1000 个字符，有时可能不完整，但它们比不显示任何内容更有用！检查这些日志可能有助于排查自己的管道问题，在帮助进行故障排除时，它肯定会帮助我们的支持工程师。

选择性地装载只读容器卷

在 Azure Pipelines 中运行容器作业时，包含工作区、任务和其他材料的多个卷将映射为卷。这些卷默认为读取/写入访问权限。为了提高安全性，可以通过在 YAML 中更改容器规范来装载只读卷。下面的 mountReadOnly 每个键可以设置为 true 只读（默认值为 false）。

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

对容器启动/停止的精细控制

一般情况下，我们建议允许 Azure Pipelines 管理作业和服务容器的生命周期。但是，在某些情况下，你可能想要自行启动和停止它们。在此版本中，我们已将该功能内置到 Docker 任务中。

下面是使用新功能的示例管道：

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

此外，我们还在管道变量 Agent.ContainerMapping中包含容器列表。例如，如果要检查脚本中的容器列表，则可以使用此方法。它包含字符串化的 JSON 对象，该对象将资源名称（上例中的“builder”）映射到代理管理的容器 ID。

为每个步骤解压缩任务包

代理运行作业时，它首先下载作业步骤所需的所有任务捆绑包。通常情况下，为了提高性能，即使任务在多个步骤中使用，每个作业也会解压缩一次任务。如果担心不受信任的代码更改未压缩的内容，可以通过让代理在每个用法上解压缩任务来消除一点性能。若要启用此模式，在配置代理时传递 --alwaysextracttask 。

通过限制访问令牌的范围来改进版本安全性

我们基于我们的计划来增强 Azure Pipelines 的安全设置，现在支持限制发布访问令牌的范围。

在发布中运行的每个作业都获取访问令牌。任务和脚本使用该访问令牌回调到 Azure DevOps。例如，我们使用访问令牌获取源代码、下载项目、上传日志、测试结果或对 Azure DevOps 进行 REST 调用。为每个作业都生成一个新的访问令牌，该令牌将在作业完成后过期。

通过此更新，我们将通过限制访问令牌的范围并扩展到经典版本来改进管道安全性。

默认情况下，新项目和集合都将启用此功能。对于现有集合，必须在集合 设置 > 管道 > 设置中启用它。 > 将作业授权范围限制为发布管道的当前项目。在此处了解更多信息。

YAML 预览版 API 增强功能

现在可以预览管道的完整 YAML ，而无需运行它。此外，我们还为预览功能创建了一个专用的新 URL。现在，可以 POST 检索 https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview 最终的 YAML 正文。此新 API 采用与排队运行相同的参数，但不再需要“队列生成”权限。

下次运行此作业R

你是否曾经有一个 bugfix，你现在需要部署它，但必须等待 CI 和 PR 作业？通过此版本，我们现在允许你提升排队作业的优先级。对池具有“管理”权限（通常是池管理员）的用户将在作业详细信息页上看到新的“下一步”按钮。单击该按钮将尽快将作业设置为运行。（当然，你仍然需要可用的并行度和合适的代理。

YAML `resources` 块中允许的模板表达式

以前，Azure Pipelines YAML 文件中不允许resources使用编译时表达式（${{ }}）。在此版本中，我们解除了容器的此限制。这样就可以使用资源内的运行时参数内容，例如在队列时选取容器。我们计划随着时间的推移将此支持扩展到其他资源。

控制来自市场的自动化任务更新

编写 YAML 管道时，通常只指定包含任务的主要版本号。这样，管道就可以自动执行最新的功能添加和 bug 修复。有时，你可能需要回滚到任务的上一个点版本，通过此更新，我们添加了执行此操作的功能。现在可以在 YAML 管道中指定完整的 major.minor.patch 任务版本。

建议不要定期执行此操作，并且仅在发现较新的任务中断管道时将其用作临时解决方法。此外，这不会从市场安装旧版任务。它必须已存在于集合中，否则管道将失败。

示例：

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

代理和任务中的节点 10 支持

由于不再支持 Node 6，因此我们将迁移任务以使用 Node 10。对于此更新，我们已将近 50% 的现成任务迁移到 Node 10。代理现在可以运行 Node 6 和 Node 10 任务。在将来的更新中，我们将完全从代理中删除 Node 6。为了准备从代理中删除 Node 6，我们请求更新内部扩展和自定义任务，以便尽快使用 Node 10。若要将 Node 10 用于任务，请在你的task.json下，从Node中更新到Node10execution。

改进经典生成设计器中的 YAML 转换

在此版本中，我们为设计器生成管道引入了新的“导出到 YAML”功能。保存管道定义，然后在菜单上找到“导出到 YAML”。...

新的导出函数将替换经典生成设计器中以前发现的“视图为 YAML”函数。该函数不完整，因为它只能检查 Web UI 对生成的了解，这有时会导致生成错误的 YAML。新的导出函数将准确考虑管道的处理方式，并生成完全保真于设计器管道的 YAML。

新的 Web 平台转换 - 存储库设置

我们已经将两个“存储库”设置页面转换为单一体验，并已升级到新的 Web 平台。此升级不仅使体验变得更快、更现代，而且这些页面还为从项目级别到分支级别的所有策略提供了一个单一的入口点。

新的 Web 平台转换。

利用这种新体验，由于加载速度更快且添加了搜索筛选器，因此可以更轻松地在具有大量存储库的项目中导航。还可以在“策略”选项卡下查看项目级别策略和跨存储库策略列表。

在“策略”选项卡下查看跨存储库策略。

如果单击进入存储库，则可以在存储库级别查看策略和权限集。在“策略”选项卡中，可以查看设置策略的每个分支的列表。现在，单击该分支即可查看策略，所有这些操作均在存储库设置页完成。

选择分支以查看策略。

现在，当策略继承自比你正在处理的范围更大的范围时，将显示从每个单独的策略旁边继承策略的位置。你还可以通过单击范围名称导航到设置了更高级别策略的页面。

显示策略的继承位置。

策略页本身也已升级到具有可折叠部分的新 Web 平台！为了改善查找特定生成验证、状态检查或自动审阅者策略的体验，我们为每个部分添加了搜索筛选器。

搜索每个部分的筛选器。

ServiceNow 与 YAML 管道的更改管理集成

适用于 ServiceNow 的 Azure Pipelines 应用可帮助你集成 Azure Pipelines 和 ServiceNow 更改管理。通过此更新，我们开始将 Azure Pipelines 了解 ServiceNow 中管理的更改管理过程进一步迁移到 YAML 管道的过程。

通过在资源上配置“ServiceNow 更改管理”检查，现在可以暂停更改，以便在将生成部署到该资源之前获得批准。可以为某个阶段自动创建新更改，也可以等待现有更改请求。

ServiceNow 变更管理集成

还可以在 UpdateServiceNowChangeRequest 服务器作业中添加任务，以使用部署状态、备注等更新更改请求。

Artifacts

能够从 UI 创建组织范围的源

我们正在恢复客户通过本地服务和托管服务的 Web UI 创建和管理集合范围的源的能力。

现在，可以通过 UI 创建组织范围的源，方法是转到“项目 -> 创建源”并选择“作用域”中的源类型。

通过依次选择“项目”、“创建源”和“作用域”中的源类型来创建集合范围的源。

虽然我们建议使用项目范围的源与 Azure DevOps 产品/服务的其余部分一致，但可以通过 UI 和各种 REST API 再次创建、管理和使用集合范围的源。有关详细信息，请参阅我们的源文档。

更新包版本 REST API 现可用于 Maven 包

现在可以使用 Azure 项目“更新包版本”REST API 来更新 Maven 包版本。以前，可以使用 REST API 更新 NuGet、Maven、npm 和通用包的包版本，但不能更新 Maven 包。

若要更新 Maven 包，请使用 HTTP PATCH 命令，如下所示。

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

可以设置以下内容：

URI 参数

Name	位于	必需	类型	描述
artifactId	path	TRUE	string	包的项目 ID
feed	path	TRUE	string	源的名称或 ID
groupId	path	TRUE	string	包的组 ID
collection	path	TRUE	string	Azure DevOps 集合的名称
版本	path	TRUE	string	包的版本
project	path		string	项目 ID 或项目名称
api-version	查询	TRUE	string	要使用的 API 版本。这应设置为“5.1-preview.1”才能使用此版本的 API

请求正文

Name	类型	描述
浏览	JsonPatchOperation	将向其添加包版本的视图

有关详细信息，请参阅 REST API 文档，因为它已更新。

反馈

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

返回页首