Azure DevOpsServer 2020 Update 1 发行说明

| 开发者社区系统要求 | 许可条款 | 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 部署为 TFS 2010 或更低版本，必须先执行一些过渡步骤，然后才能升级到 Azure DevOps Server 2019。 若要了解详细信息，请参阅 在本地安装和配置 Azure DevOps。

---

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

Azure DevOps Server 2020 引入了新的管道运行 (生成) 保留模型，该模型基于项目级设置工作。

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

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

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，其中包括以下修补程序：

• 解决了安装修补程序 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 Patch 10 发布日期：2023 年 11 月 14 日

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

• 扩展了 启用 shell 任务参数验证的 PowerShell 任务允许的字符列表。

注意

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

安装修补程序

重要

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

配置 TFX

1. 按照 将任务上传到项目集合文档中 的步骤，使用 tfx-cli 进行安装和登录。

使用 TFX 更新任务

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

1. 下载并提取 Tasks20231103.zip。
2. 将目录更改为提取的文件。
3. 执行以下命令上传任务：

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 修补程序 9 发布日期：2023 年 10 月 10 日

重要

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

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

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

Azure DevOps Server 2020 Update 1.2 修补程序 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 特权提升漏洞。

重要

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

注意

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

安装修补程序

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

更新 Azure Pipelines 代理

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

注意

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

配置 TFX

1. 按照 将任务上传到项目集合文档中 的步骤，使用 tfx-cli 进行安装和登录。

使用 TFX 更新任务

1. 下载并提取 Tasks_20230825.zip。
2. 将目录更改为提取的文件。
3. 执行以下命令上传任务：

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 修补程序 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 修补程序 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 中特殊字符的显示问题。

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

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 控件时，Email通知未发送。
• 用户个人资料中的首选电子邮件地址未更新。 这导致了电子邮件发送到之前的电子邮件地址。
• “项目摘要”页中未显示标头。 标头显示了几毫秒，然后消失了。
• 改进了 Active Directory 用户同步。
• 通过从 log4j 二进制文件中删除 jndilookup 类来解决 Elasticsearch 漏洞。

安装步骤

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

注意

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

1. 使用 修补程序 4 升级服务器。
2. 检查 HKLM:\Software\Elasticsearch\Version 的注册表值。 如果注册表值不存在，请添加一个字符串值，并将版本设置为 5.4.1 (Name = Version, Value = 5.4.1)。
3. 将名为 zip 且位于 C:\Program Files\{TFS Version Folder}\Search\zip 中的文件夹的内容复制到 Elasticsearch 远程文件文件夹。
4. 在 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 的连接。 使用此修补程序，项目管理员可以在 GitHub.com 上的Azure DevOps Server和存储库之间创建连接。 可以在 “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) 。

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

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

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

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

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

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

现在可以将系统工作项类型添加到所选的积压工作级别。 过去，这些工作项类型仅在查询中可用。

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

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

Azure Boards GitHub 应用存储库限制提高

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

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

并非所有工作流都是相同的。 一些客户希望在拉取请求完成后关闭其相关工作项。 另一些则希望将工作项设置为另一个状态，以在关闭之前进行验证。 我们应该允许两者兼而有之。

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

将工作项链接到其他项目中的生成

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

编辑说明 (系统字段上的帮助文本)

始终能够编辑自定义字段的说明。 但对于优先级、严重性和活动等系统字段，说明不可编辑。 这是 Hosted XML 和 Inherited 之间的功能差距，导致某些客户无法迁移到继承模型。 现在可以编辑系统字段的说明。 编辑的值将仅影响进程中和该工作项类型的该字段。 这使你能够灵活地对不同工作项类型上的同一字段使用不同的说明。

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

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

任务板上的父域

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

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

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

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

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

删除了“工作项”页上的项

“ 工作项”页 是快速查找已创建或分配给你的项目等项的绝佳位置。 它提供多个个性化透视表和筛选器。 “分配给我”透视表的主要投诉之一是，它显示已删除的工作项 (即处于“已删除”状态的工作项) 。 我们同意！ 已删除的项是不再具有价值的工作，因此已从积压工作中删除，因此在此视图中将其包含在内无用。

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

Repos

默认分支名称首选项

Azure Repos现在为 Git 提供可自定义默认分支名称。 在存储库设置中，可以选择在初始化存储库时使用的任何法定分支名称。 Azure Repos始终支持更改现有存储库的默认分支名称。 有关更多详细信息 ，请访问管理分支 。

 

注意：如果未启用此功能，则存储库将使用Azure Repos的默认名称进行初始化。 现在，该默认值为 master。 为了履行 Microsoft 对包容性语言的承诺和客户对语言的要求，我们将与行业同行一起将此默认值更改为main。 这种变化将在今年夏天晚些时候发生。 如果要继续使用 master，则应立即打开此功能并将其设置为 master。

默认分支组织级别设置

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

添加新的身份验证范围，用于贡献 PR 注释

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

拉取请求体验改进

新的拉取请求体验已得到以下改进：

• 使可选检查更可见

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

• 按 Ctrl 单击菜单项

PR 上的选项卡菜单不支持 Ctrl 单击。 用户通常会在查看拉取请求时打开新的浏览器选项卡。 此问题已解决。

• [+] 批注的位置

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

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

用于选择 PR 中的更新和比较文件的下拉列表在预览体验中丢失了一个重要元素。 它未显示更新的发生时间。 此问题已解决。

• **改进了批注筛选器布局 **

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

• 导航到父提交

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

• 在“PR 文件”选项卡中为具有长名称的文件夹和文件提供更多空间

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

新文件树的图像：

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

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

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

• 在移动设备上搜索提交

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

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

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

• PR 摘要视图中的增强图像

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

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

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

管道

其他代理平台：ARM64

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

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

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

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    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 Enterprise、Nexus、Aritfactory 等 ) 并触发管道。

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

1. 在外部服务上设置 Webhook。 创建 Webhook 时，需要提供以下信息：

   • 请求 URL - “https://dev.azure.com/<ADO collection>/_apis/public/distributedtask/webhooks/<WebHook Name>？api-version=6.0-preview”
   • 机密 - 这是可选的。 如果需要保护 JSON 有效负载，请提供 “机密” 值

2. 创建新的“传入 Webhook”服务连接。 这是新引入的服务连接类型，可用于定义三个重要信息：

   • Webhook 名称：Webhook 的名称应与在外部服务中创建的 Webhook 匹配。
   • HTTP 标头 - 请求中 HTTP 标头的名称，其中包含用于请求验证的有效负载哈希值。 例如，对于 GitHub，请求标头将为“X-Hub-Signature”
   • 机密 - 机密用于分析用于验证传入请求的有效负载哈希， (这是可选的) 。 如果在创建 Webhook 时使用了机密，则需要提供相同的密钥

   

3. 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}}

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

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

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

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

1. 如果所提供的服务连接源无效，或者触发器中存在任何语法错误，则根本不会配置触发器。 这些显示为错误。

2. 如果触发器条件不匹配，则不会执行触发器。 每当发生这种情况时，都会显示一条警告，以便你可以了解条件不匹配的原因。

   

多存储库触发器

可以在一个 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 采用与排队运行相同的参数，但不再需要“队列生成”权限。

接下来运行此作业

你曾经有过一个 bug 修复，你需要 立即 部署，但不得不等待 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 支持

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

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

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

新的导出函数替换了以前在经典生成设计器中找到的“View as YAML”函数。 该函数不完整，因为它只能检查 Web UI 对生成的了解，这有时会导致生成不正确的 YAML。 新的导出函数准确考虑了管道的处理方式，并生成与设计器管道完全保真的 YAML。

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

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

借助这种新体验，由于加载速度更快，并且增加了搜索筛选器，因此对具有大量存储库的项目的导航变得更加容易。 还可以在“策略”选项卡下查看项目级别策略和跨存储库策略列表。

如果单击存储库，可以查看在存储库级别设置的策略和权限。 在“策略”选项卡中，可以查看设置策略的每个分支的列表。 现在，单击分支可查看所有策略，同时从不离开“存储库设置”页。

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

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

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

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

通过在资源上配置“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 参数

名称	位于	必需	类型	说明
artifactId	path	TRUE	字符串	包的项目 ID
feed	path	TRUE	字符串	源的名称或 ID
groupId	path	TRUE	字符串	包的组 ID
collection	path	TRUE	字符串	Azure DevOps 集合的名称
版本	path	TRUE	字符串	包的版本
project	path		string	项目 ID 或项目名称
api-version	query	TRUE	字符串	要使用的 API 版本。 应将其设置为“5.1-preview.1”才能使用此版本的 API

请求正文

名称	类型	说明
视图	JsonPatchOperation	将向其添加包版本的视图

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

反馈

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

---

返回页首