Azure DevOps Server 2020 发行说明

| 开发者社区系统要求 | 许可条款 | 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 0.2 修补程序 6 发布日期：2023 年 11 月 14 日

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

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

注意

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

安装修补程序

重要

我们在 2023 年 9 月 12 日发布了 Azure Pipelines 代理的修补程序 4 的更新。 如果未按照 修补程序 4 的发行说明中所述安装代理更新，我们建议在安装修补程序 6 之前安装这些更新。 安装修补程序 4 后代理的新版本将是 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 0.2 Patch 5 发布日期：2023 年 10 月 10 日

重要

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

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

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

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

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

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

重要

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

注意

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

安装修补程序

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

更新 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 0.2 Patch 3 发布日期：2023 年 8 月 8 日

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

• 修复了从 2018 或更早版本升级时干扰推送包的 bug。

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

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

• 修复了从 2018 或更早版本升级时干扰推送包的 bug。

Azure DevOps Server 2020 Update 0.2 修补程序 1 发布日期：2022 年 10 月 18 日

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

• 解决新添加的 AD 标识未显示在安全对话框标识选取器中的问题。
• 修复了 Web 挂钩设置中“组成员请求”筛选器的问题。
• 修复了管道的组织设置将作业授权范围配置为将作业授权范围限制为非发布管道的当前项目时，封闭检查生成错误。

Azure DevOps Server 2020.0.2 发布日期：2022 年 5 月 17 日

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

注意

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

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

• 无法使用“运行下一步”按钮跳过生成队列。 以前，“运行下一步”按钮仅为项目集合管理员启用。

• 禁用用户的 Active Directory 帐户后，撤销所有个人访问令牌。

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

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

• 在工作项中使用 控件时，@mention未发送Email通知。
• 修复切换帐户时TF400813错误。 从 TFS 2018 升级到 Azure DevOps Server 2020.0.1 时发生此错误。
• 修复了“项目概述摘要”页加载失败的问题。
• 对 Active Directory 用户同步的改进。
• 通过从 log4j 二进制文件中删除 jndilookup 类来解决 Elasticsearch 漏洞。

安装步骤

1. 使用 修补程序 9 升级服务器。
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. 使用 Patch 9 升级服务器。
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 哈希： B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

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

Azure DevOps Server 2020.0.1 的修补程序 8 包括以下修补程序。

• 自定义工作项布局状态的本地化问题。
• 电子邮件通知模板中的本地化问题。
• 当一行中有多个相同的链接时，控制台日志被截断的问题。
• 为字段定义多个 NOTSAMEAS 规则时，NOTSAMEAS 规则评估问题。

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

适用于 Azure DevOps Server 2020.0.1 的修补程序 7 包括以下各项的修补程序。

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

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

Azure DevOps Server 2020.0.1 的修补程序 6 包括以下修补程序。

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

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

Azure DevOps Server 2020.0.1 的修补程序 5 包括以下修补程序。

• 修复生成定义 UI 错误。
• 更改了浏览历史记录以显示文件而不是根存储库。
• 修复了某些工作项类型的电子邮件传递作业的问题。

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

Azure DevOps Server 2020.0.1 的修补程序 4 包括以下修补程序。

• 修复了数据导入问题。 对于具有大量过时测试用例的客户来说，数据导入需要很长时间。 这是由于引用增加了表的大小 tbl_testCaseReferences 。 通过此修补程序，我们删除了对过时测试用例的引用，以帮助加快数据导入过程。

Azure DevOps Server 2020.0.1 修补程序 3 发布日期：2021 年 5 月 11 日

我们发布了Azure DevOps Server 2020.0.1 的修补程序，可修复以下问题。

• 使用 Microsoft.TeamFoundation.TestManagement.Client 时的测试结果数据不一致。

如果Azure DevOps Server 2020.0.1，则应安装 Azure DevOps Server 2020.0.1 修补程序 3。

验证安装

• 选项 1：运行 devops2020.0.1patch3.exe CheckInstall，devops2020.0.1patch3.exe 是从上述链接下载的文件。 命令的输出将指示已安装修补程序或未安装修补程序。

• 选项 2：检查以下文件的版本： [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll。 Azure DevOps Server 2020.0.1 默认安装到 c:\Program Files\Azure DevOps Server 2020 。 安装 Azure DevOps Server 2020.0.1 修补程序 3 后，版本将为 18.170.31228.1。

Azure DevOps Server 2020.0.1 修补程序 2 发布日期：2021 年 4 月 13 日

注意

如果已Azure DevOps Server 2020，应首先更新为 Azure DevOps Server 2020.0.1。 在 2020.0.1 上安装 Azure DevOps Server 2020.0.1 修补程序 2

我们发布了Azure DevOps Server 2020.0.1 的修补程序，可修复以下问题。

• CVE-2021-27067 ：信息泄露
• CVE-2021-28459：特权提升

若要实现此修补程序的修补程序，必须按照下面列出的步骤安装 常规修补程序、 AzureResourceGroupDeploymentV2 和 AzureResourceManagerTemplateDeploymentV3 任务安装。

常规修补程序安装

如果Azure DevOps Server 2020.0.1，则应安装 Azure DevOps Server 2020.0.1 修补程序 2。

验证安装

• 选项 1：运行 devops2020.0.1patch2.exe CheckInstall，devops2020.0.1patch2.exe 是从上述链接下载的文件。 命令的输出将指示已安装修补程序或未安装修补程序。

• 选项 2：检查以下文件的版本： [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll。 Azure DevOps Server 2020.0.1 默认安装到 c:\Program Files\Azure DevOps Server 2020 。 安装 Azure DevOps Server 2020.0.1 修补程序 2 后，版本将为 18.170.31123.3。

AzureResourceGroupDeploymentV2 任务安装

注意

下面提及的所有步骤都需要在 Windows 计算机上执行

安装

1. 将 AzureResourceGroupDeploymentV2.zip 包解压缩到计算机上的新文件夹。 例如： D：\tasks\AzureResourceGroupDeploymentV2。

2. 根据计算机的要求下载并安装 Node.js 14.15.1 和 npm（包含在 Node.js 下载项中）。

3. 在管理员模式下打开命令提示符，并运行以下命令以安装 tfx-cli。

npm install -g tfx-cli

4. 创建具有完全访问特权的个人访问令牌并复制它。 运行 tfx login 命令时将使用此个人访问令牌。

5. 从命令提示符下运行以下命令。 出现提示时，输入服务 URL 和个人访问令牌。

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. 运行以下命令，将任务上传到服务器。 使用从步骤 1 中提取的 .zip 文件的路径。

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

AzureResourceManagerTemplateDeploymentV3 任务安装

注意

下面提及的所有步骤都需要在 Windows 计算机上执行

安装

1. 将 AzureResourceManagerTemplateDeploymentV3.zip 包解压缩到计算机上的新文件夹。 例如：D：\tasks\AzureResourceManagerTemplateDeploymentV3。

2. 下载并安装 Node.js 14.15.1 和 npm (，Node.js 下载) 适合你的计算机。

3. 在管理员模式下打开命令提示符，并运行以下命令以安装 tfx-cli。

npm install -g tfx-cli

4. 创建具有完全访问特权的个人访问令牌并复制它。 运行 tfx login 命令时将使用此个人访问令牌。

5. 从命令提示符下运行以下命令。 出现提示时，输入服务 URL 和个人访问令牌。

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. 运行以下命令，将任务上传到服务器。 使用从步骤 1 中提取的 .zip 文件的路径。

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

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

我们发布了Azure DevOps Server 2020.0.1 的修补程序，可修复以下问题。 有关详细信息，请参阅博客文章。

• 解决此开发者社区反馈票证中报告的问题 |“新建测试用例”按钮不起作用
• 包括随 Azure DevOps Server 2020 修补程序 2 发布的修补程序。

Azure DevOps Server 2020 修补程序 3 发布日期：2021 年 2 月 9 日

我们发布了Azure DevOps Server 2020 的修补程序，修复了以下问题。 有关详细信息，请参阅博客文章。

• 解决此开发者社区反馈票证中报告的问题 |“新建测试用例”按钮不起作用

Azure DevOps Server 2020.0.1 发布日期：2021 年 1 月 19 日

Azure DevOps Server 2020.0.1 是 bug 修复的汇总。 可以直接安装 Azure DevOps Server 2020.0.1 或从现有安装升级。 支持的升级版本为 Azure DevOps Server 2020、Azure DevOps Server 2019 和 Team Foundation Server 2012 或更高版本。

此版本包括针对以下 bug 的修补程序：

• 解决从 Azure DevOps Server 2019 升级后 Git 代理可能停止工作的升级问题。
• 修复升级到 Azure DevOps Server 2020 时，Team Foundation Server 2017 之前的非 ENU 集合的 System.OutOfMemoryException 异常。 解决了此开发者社区反馈票证中报告的问题。
• 缺少 Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll 导致的服务失败。 解决了此开发者社区反馈票证中报告的问题。
• 修复升级到 Azure DevOps Server 2020 时 Analytics 中的列名无效错误。 解决了此开发者社区反馈票证中报告的问题。
• 在测试用例结果中显示测试用例步骤时存储的 XSS。
• 将点结果数据迁移到 TCM 时升级步骤失败。

Azure DevOps Server 2020 修补程序 2 发布日期：2021 年 1 月 12 日

我们发布了Azure DevOps Server 2020 的修补程序，修复了以下问题。 有关详细信息，请参阅博客文章。

• 测试运行详细信息不显示使用 OpsHub 迁移迁移的测试数据的测试步骤详细信息
• “Microsoft.TeamFoundation.TestManagement.Server.TCMLogger”的初始值设定项异常
• 迁移到 Azure DevOps Server 2020 后，将立即删除未执行的内部版本
• 修复数据提供程序异常

Azure DevOps Server 2020 修补程序 1 日期：2020 年 12 月 8 日

我们发布了Azure DevOps Server 2020 的修补程序，修复了以下问题。 有关详细信息，请参阅博客文章。

• CVE-2020-17145 ：Azure DevOps Server 和 Team Foundation Services 欺骗漏洞

Azure DevOps Server 2020 发布日期：2020 年 10 月 6 日

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

注意

Azure DevOps 2020 Server 在安装 Git 虚拟文件系统 (GVFS) 使用的程序集时出现问题。

如果要从 Azure DevOps 2019 升级 (任何版本) 或 Azure DevOps 2020 候选版本并安装到与上一版本相同的目录，则不会安装程序集 Microsoft.TeamFoundation.Git.dll 。 可以通过在 <Install Dir>\Version Control Proxy\Web Services\bin和 <Install Dir>\Application Tier\TFSJobAgent<Install Dir>\Tools 文件夹中查找 Microsoft.TeamFoundation.Git.dll 来验证是否遇到了问题。 如果文件缺失，可以运行修复来还原缺失的文件。

若要运行修复，请在Azure DevOps Server计算机/VM 上转到 Settings -> Apps & Features ，并在 Azure DevOps 2020 服务器上运行修复。 修复完成后，可以重新启动计算机/VM。

Azure DevOps Server 2020 RC2 发布日期：2020 年 8 月 11 日

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

Azure DevOps Server 2020 RC1 重新发布日期：2020 年 7 月 10 日

我们已重新发布 Azure DevOps Server 2020 RC1，以修复此开发者社区反馈票证。

以前，从 Azure DevOps Server 2019 Update 1.1 升级到 Azure DevOps Server 2020 RC1 后，无法查看 Web UI 的 Repos、Pipelines 和 Wiki 中的文件。 有一条错误消息，指示 页面的此区域中发生了意外错误。可以尝试重新加载此组件或刷新整个页面。 在此版本中，我们修复了此问题。 有关详细信息，请参阅博客文章。

Azure DevOps Server 2020 RC1 发布日期：2020 年 6 月 30 日

2020 Azure DevOps Server新增功能摘要

Azure DevOps Server 2020 引入了许多新功能。 其中一些要点包括：

• 多阶段管道
• YAML 中的持续部署
• 使用 Boards 积压工作上的汇总跟踪父项的进度
• 将“父工作项”筛选器添加到任务板和冲刺积压工作
• 用于Azure Repos登陆页面的新 Web UI
• 跨存储库分支策略管理
• “新建测试计划”页
• 代码 Wiki 页面的丰富编辑
• 管道故障和持续时间报告

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

• 常规
• Boards
• Repos
• 管道
• 测试计划
• 项目
• Wiki
• 报告

---

常规

Azure DevOps CLI 正式发布

今年 2 月，我们引入了适用于 Azure CLI 的 Azure DevOps 扩展。 该扩展允许从命令行与 Azure DevOps 交互。 我们已收集你的反馈，帮助我们改进扩展并添加更多命令。 我们现在很高兴地宣布该扩展已正式发布。

若要详细了解 Azure DevOps CLI，请参阅 此处的文档。

使用发布配置文件从部署中心部署适用于 Windows 的 Azure WebApps

现在，可以使用基于发布配置文件的身份验证从部署中心部署适用于 Windows 的 Azure WebApps。 如果有权使用发布配置文件部署到 Azure WebApp for Windows，则可以在部署中心工作流中使用此配置文件设置管道。

Boards

将“父工作项”筛选器添加到任务板和冲刺积压工作

我们向冲刺板和冲刺积压工作添加了新的筛选器。 这使你可以按父项筛选要求级别积压工作项 (左侧) 的第一列。 例如，在下面的屏幕截图中，我们已筛选视图，以仅显示父级为“我的大功能”的用户情景。

改进错误处理体验 - Bug/任务上的必填字段

从历史上看板来看，如果将工作项从状态更改触发字段规则的另一列移动到另一列，卡只会显示红色错误消息，这会迫使你打开工作项以了解根本原因。 在 sprint 170 中，我们改进了体验，因此你现在可以单击红色错误消息以查看错误的详细信息，而无需打开工作项本身。

工作项实时重载

以前，当更新工作项时，第二个团队成员正在对同一工作项进行更改时，第二个用户将丢失其更改。 现在，只要你们都在编辑不同的字段，你就会看到对工作项所做的更改的实时更新。

从命令行管理迭代和区域路径

现在，可以使用 和 命令从命令行 az boards iteration 管理迭代和 az boards area 区域路径。 例如，可以从 CLI 以交互方式设置和管理迭代和区域路径，或使用脚本自动执行整个设置。 有关命令和语法的更多详细信息，请参阅 此处的文档。

工作项父列作为列选项

现在，你可以选择查看产品积压工作或冲刺积压工作中的每个工作项的父项。 若要启用此功能，请转到所需积压工作上的 列选项 ，然后添加 父 列。

更改项目使用的过程

工具应与团队一样发生更改，现在可以将项目从任何现成的流程模板切换到任何其他现成的进程。 例如，可以将项目从使用敏捷更改为 Scrum，或将基本更改为敏捷。 可 在此处找到完整的分步文档。

“

在布局中隐藏自定义字段

现在可以在自定义流程时从窗体布局中隐藏自定义字段。 该字段仍将在查询和 REST API 中可用。 在与其他系统集成时，这在跟踪额外字段时非常有用。

通过三份新的Azure Boards报告深入了解团队的运行状况

无法修复看不到的内容。 因此，需要密切关注其工作流程的状态和运行状况。 借助这些报表，我们可以更轻松地跟踪重要指标，只需极少量的Azure Boards。

这三个新的交互式报表是： Burndown、 Cumulative Flow Diagram (CFD) 和 Velocity。 可以在“新建分析”选项卡中查看报表。

冲刺进度、工作流和团队速度等指标可让你了解团队进度并帮助回答以下问题：

• 我们在这个冲刺中还剩下多少工作？ 我们是否有望完成它？
• 开发过程的哪个步骤花费的时间最长？ 我们能做些什么吗？
• 根据以前的迭代，我们应该为下一个冲刺计划多少工作？

注意

先前在标题中显示的图表已替换为这些增强的报表。

新报表具有完全交互性，可根据需要进行调整。 可以在每个中心的 “分析”选项卡 下找到新报表。

• 可以在 冲刺 中心下找到燃尽图表。

  

• 可以通过单击相关卡，从“板和积压工作”下的“分析”选项卡访问 CFD 和 Velocity 报告。

  

借助新报表，你可以对团队拥有更多控制权和信息。 下面是一些示例：

• Sprint Burndown 和 Velocity 报表可以设置为使用工作项计数或剩余工时的总和。
• 可以调整冲刺燃尽的时间范围，而不会影响项目日期。 因此，如果你的团队通常在每个冲刺计划的第一天度过，你现在可以匹配图表来反映这一点。
• 燃尽图现在有一个显示周末的水印。
• 通过 CFD 报表，可以删除设计等板列，以便更加关注团队所控制的流。

下面是一个CFD报表示例，其中显示了过去 30 天的故事积压工作流。

现在可以跟踪所有积压工作级别的速度图表。 例如，现在可以添加“功能”和“Epics”，而在上一个图表之前，仅支持“要求”。 下面是功能积压工作最近 6 次迭代的速度报告示例。

自定义任务板列

我们很高兴地宣布，我们添加了一个选项，用于自定义任务板上的列。 现在可以添加、删除、重命名和重新排序列。

若要配置任务板上的列，请转到 “列选项”。

此功能是根据开发者社区的建议确定的。

切换以显示或隐藏积压工作上已完成的子工作项

很多时候，在优化积压工作时，你只想看到尚未完成的项目。 现在，你可以在积压工作上显示或隐藏已完成的子项。

如果开关处于打开状态，你将看到所有子项处于已完成状态。 关闭开关后，处于已完成状态的所有子项将从积压工作中隐藏。

标记工作项时显示的最新标记

标记工作项时，自动完成选项现在最多会显示五个最近使用的标记。 这样，可以更轻松地向工作项添加正确的信息。

组成员身份的只读和必需规则

使用工作项规则可以设置对工作项字段的特定操作，以自动执行其行为。 可以创建规则，根据组成员身份将字段设置为只读或必需。 例如，你可能希望授予产品所有者设置功能优先级的能力，同时使其对其他人都是只读的。

自定义系统选取列表值

现在可以自定义除原因字段（例如严重性、活动、优先级等）之外的任何系统选取列表) (的值。选取列表自定义的范围已确定，以便您可以为每个工作项类型管理同一字段的不同值。

新建工作项 URL 参数

使用我们的新工作项 URL 参数，通过板或积压工作项的上下文共享工作项的链接。 现在，可以通过将 参数 ?workitem=[ID] 追加到 URL，在开发板、积压工作或冲刺体验中打开工作项对话框。

然后，与你共享链接的任何人都将使用你共享链接时的相同上下文登陆！

在文本字段中提及人员、工作项和 PR

当我们听取你的反馈时，我们听说你希望能够在工作项描述区域中提及人员、工作项和 PR， (和其他 HTML 字段) 工作项，而不仅仅是在注释中。 有时你正在与某人协作处理工作项，或者想要在工作项说明中突出显示 PR，但无法添加该信息。 现在，可以在工作项上的所有长文本字段中提及人员、工作项和 PR。

可在此处查看示例。

• 若要使用人员提及，请@键入要提及的符号和人员姓名。 @mentions工作项字段中会生成电子邮件通知，就像它对注释所做的那样。
• 若要使用工作项提及，请 # 键入后跟工作项 ID 或标题的符号。 #mentions 将在两个工作项之间创建链接。
• 若要使用 PR 提及，请添加 ！ ，后跟 PR ID 或名称。

对讨论评论的反应

我们的main目标之一是使工作项对团队更具协作性。 最近，我们在 Twitter 上 进行了一次投票，以了解你在讨论工作项时想要哪些协作功能。 对评论的回应赢得了民意测验，所以我们添加它们！ 以下是 Twitter 民意测验的结果。

你可以向任何批注添加反应，有两种方法可以添加你的反应 - 任何批注右上角的笑脸图标，以及任何现有反应旁边的批注底部。 如果愿意，可以添加所有六个反应，也可以只添加一两个。 若要删除你的反应，请单击批注底部的反应，它将被删除。 下面可以查看添加反应的体验，以及批注中的反应效果。

将Azure Boards报表固定到仪表板

在 Sprint 155 更新中，我们包含了 更新版本的 CFD 和速度报告。 这些报告位于“板和积压工作”的“分析”选项卡下。 现在可以将报表直接固定到仪表板。 若要固定报表，请将鼠标悬停在报表上，选择省略号“...”菜单，并 复制到仪表板。

使用 Boards 积压工作汇总跟踪父项的进度

汇总列显示层次结构中数字字段或后代项的进度条和/或总计。 后代项对应于层次结构中的所有子项。 可以将一个或多个汇总列添加到产品或项目组合积压工作。

例如，在这里，我们显示“按工作项的进度”，它根据已关闭的后代项的百分比显示祖代工作项的进度条。 Epics 的后代项包括所有子功能及其子或子级工作项。 功能的后代项包括所有子用户情景及其子工作项。

任务板实时更新

现在，任务板会在发生更改时自动刷新！ 当其他团队成员在任务板上移动或重新排序卡片时，板将自动更新这些更改。 无需再按 F5 即可查看最新更改。

支持汇总列中的自定义字段

现在可以对任何字段（包括自定义字段）执行汇总。 添加汇总列时，仍可以从“快速”列表中选择汇总列，但是，如果要对不属于现成进程模板的数值字段进行汇总，可以按如下所示配置自己的字段：

1. 在积压工作上，单击“列选项”。 然后在面板中单击“添加汇总列”和 配置自定义汇总。

   

2. 在进度栏和“总计”之间进行选择。
3. 选择工作项类型或积压工作级别 (通常积压工作聚合多个工作项类型) 。
4. 选择聚合类型。 工作项计数 或 总和。 对于 Sum，需要选择要汇总的字段。
5. “ 确定” 按钮将返回到列选项面板，可在其中重新排序新的自定义列。

请注意，单击“确定”后无法编辑自定义列。 如果需要进行更改，请删除自定义列并根据需要添加另一个列。

基于条件隐藏工作项窗体中的字段的新规则

我们已向继承的规则引擎添加了一个新规则，以便隐藏工作项窗体中的字段。 此规则将根据用户组成员身份隐藏字段。 例如，如果用户属于“产品所有者”组，则可以隐藏特定于开发人员的字段。 有关详细信息，请参阅 此处的文档。

自定义工作项通知设置

随时了解与你或你的团队相关的工作项非常重要。 它可帮助团队进行协作并跟踪项目，并确保所有合适的各方都参与其中。 但是，不同的利益干系人对不同工作的投资级别不同，我们认为这应该反映在你跟踪工作项状态的能力上。

以前，如果你想要关注工作项并获取有关所做的任何更改的通知，你将获得对工作项所做的任何和所有更改的电子邮件通知。 在考虑你的反馈后，我们将让所有利益干系人更加灵活地关注工作项。 现在，你将在工作项右上角的 “关注 ”按钮旁边看到一个新设置按钮。 这会将你带到一个弹出窗口，该弹出窗口将允许你配置关注选项。

在 “通知设置”中，可以从三个通知选项中进行选择。 首先，可以完全取消订阅。 其次，你可以完全订阅，其中你会收到有关所有工作项更改的通知。 最后，可以选择接收一些主要和关键工作项更改事件的通知。 只能选择一个或全部三个选项。 这将允许团队成员在更高级别关注工作项，并且不会因为所做的每一项更改而分心。 通过此功能，我们将消除不必要的电子邮件，并让你专注于手头的关键任务。

将工作项链接到部署

我们很高兴在工作项窗体上发布部署控制。 此控件将工作项链接到发布，使你能够轻松跟踪工作项的部署位置。 若要了解详细信息，请参阅 此处的文档。

从 CSV 文件导入工作项

到目前为止，从 CSV 文件导入工作项依赖于使用 Excel 插件。 在此更新中，我们将直接从 Azure Boards 提供一流的导入体验，以便你可以导入新的工作项或更新现有工作项。 若要了解详细信息，请参阅 此处的文档。

向工作项卡添加父字段

现在，在看板中，父上下文可用作工作项卡的新字段。 现在可以将 Parent 字段添加到卡片，无需使用标记和前缀等解决方法。

将父字段添加到积压工作和查询

查看积压工作和查询结果时，父字段现在可用。 若要添加父字段，请使用 “列选项” 视图。

Repos

拉取请求的代码覆盖率指标和分支策略

现在可以在拉取请求 (PR) 视图中查看更改的代码覆盖率指标。 这可确保通过自动测试充分测试更改。 覆盖状态将在 PR 概述中显示为注释。 可以查看文件差异视图中更改的每个代码行的覆盖率信息的详细信息。

此外，存储库所有者现在可以设置代码覆盖率策略，并防止将未经测试的大型更改合并到分支中。 可以在存储库根处签入的设置文件中定义azurepipelines-coverage.yml所需的覆盖率阈值，可以使用现有分支策略为 Azure Repos 中的其他服务功能配置覆盖策略。

筛选拉取请求中的注释通知

拉取请求中的注释通常会由于通知而产生大量干扰。 我们添加了一个自定义订阅，允许你按评论年龄、评论者、已删除的评论、提及的用户、拉取请求作者、目标分支和线程参与者来筛选你订阅的评论通知。 可以通过单击右上角的用户图标并导航到“ 用户设置”来创建这些通知订阅。

拉取请求注释的服务挂钩

现在可以基于存储库和目标分支为拉取请求中的注释创建服务挂钩。

阻止具有指定模式的文件的策略

管理员现在可以设置策略，以防止根据文件类型和路径将提交推送到存储库。 文件名验证策略将阻止与提供的模式匹配的推送。

使用关键字通过提交来解析工作项

现在，可以通过提交到默认分支来解析工作项，方法是使用修复、修复或固定等关键字。 例如，可以编写 - 提交消息中的“此更改已修复 #476”，当提交推送或合并到默认分支时，将完成工作项 #476。 有关详细信息，请参阅 此处的文档。

自动审阅者的粒度

以前，将组级别审阅者添加到拉取请求时，只需从已添加的组获得一次批准。 现在，你可以设置策略，要求团队中的多个审阅者在添加自动审阅者时批准拉取请求。 此外，还可以添加策略来阻止请求者批准其自己的更改。

使用基于服务帐户的身份验证连接到 AKS

以前，在从 AKS 部署中心配置 Azure Pipelines 时，我们使用了 Azure 资源管理器连接。 此连接有权访问整个群集，而不仅仅是为其配置了管道的命名空间。 通过此更新，管道将使用基于服务帐户的身份验证连接到群集，以便它仅有权访问与管道关联的命名空间。

预览拉取请求中的 Markdown 文件并行差异

现在，可以使用新的“预览”按钮查看 markdown 文件的外观 预览 。 此外，还可以通过选择“ 视图 ”按钮从“并行差异”查看文件的完整内容。

手动生成的生成策略过期

这些策略强制实施团队的代码质量和更改管理标准。 以前，可以为自动生成设置生成过期策略。 现在，还可以将生成过期策略设置为手动生成。

添加策略以基于提交作者电子邮件阻止提交

管理员现在可以设置推送策略，以防止将提交推送到提交作者电子邮件与所提供的模式不匹配的存储库。

此功能是根据开发者社区提供的提供类似体验的建议确定的。 我们将继续保持票证开放，并鼓励用户告诉我们你希望看到哪些其他类型的推送策略。

在拉取请求中将文件标记为已审阅

有时，需要查看包含对大量文件的更改的拉取请求，并且可能难以跟踪已审阅的文件。 现在可以在拉取请求中将文件标记为已审阅。

可以使用文件名旁边的下拉菜单或悬停并单击文件名，将文件标记为已审阅。

注意

此功能仅用于在查看拉取请求时跟踪进度。 它不表示对拉取请求的投票，因此这些标记将仅对审阅者可见。

此功能是根据开发者社区的建议确定的。

用于Azure Repos登陆页面的新 Web UI

现在可以在 Azure Repos 内试用我们的新式、快速且适合移动设备的登陆页面。 这些页面作为 “新建存储库”登陆页面提供。 登陆页面包括拉取请求详细信息、提交详细信息和分支比较以外的所有页面。

Web

移动

跨存储库分支策略管理

分支策略是Azure Repos的强大功能之一，可帮助保护重要分支。 尽管 REST API 中存在在项目级别设置策略的功能，但它没有用户界面。 现在，管理员可以跨项目中的所有存储库在特定分支或默认分支上设置策略。 例如，管理员可能需要至少两个审阅者，才能对项目中每个存储库的每个main分支发出的所有拉取请求。 可以在 Repos 项目设置中找到 “添加分支保护 ”功能。

新的 Web 平台转换登录页面

我们更新了 Repos 登陆页面用户体验，使其具有现代、快速和移动友好。 下面是已更新页面的两个示例，我们将在将来的更新中继续更新其他页面。

Web 体验：

移动体验：

支持 Kotlin 语言

我们很高兴地宣布，我们现在支持在文件编辑器中突出显示 Kotlin 语言。 突出显示将提高 Kotlin 文本文件的可读性，并帮助你快速扫描以查找错误。 我们根据开发者社区的建议确定此功能的优先级。

草稿拉取请求的自定义通知订阅

为了帮助减少拉取请求的电子邮件通知数，现在可以为在草稿状态下创建或更新的拉取请求创建自定义通知订阅。 可以获取专门针对草稿拉取请求的电子邮件，也可以从草稿拉取请求中筛选出电子邮件，这样团队就不会在拉取请求准备好审查之前收到通知。

提高了 PR 可操作性

如果有许多拉取请求需要查看，则很难先了解应采取哪些操作。 为了提高拉取请求的可操作性，现在可以在拉取请求列表页上创建多个自定义查询，其中包含多个新选项，例如草稿状态。 除了“由我创建”和“分配给我”之外，这些查询还会在拉取请求页上创建单独的可折叠部分。 还可以拒绝通过“投票”菜单或拉取请求列表页上的上下文菜单查看已添加到的拉取请求。 在自定义部分中，你现在会看到已提供评审或拒绝审阅的拉取请求的单独选项卡。 这些自定义查询将在集合主页的“我的拉取请求”选项卡上跨存储库工作。 如果要返回拉取请求，可以对其进行标记，它们将显示在列表顶部。 最后，已设置为自动完成的拉取请求将标有一个药丸，该药片在列表中显示“自动完成”。

管道

多阶段管道

我们一直在致力于 提供更新的用户体验 来管理管道。 这些更新使管道体验现代且符合 Azure DevOps 的方向。 此外，这些更新将经典生成管道和多阶段 YAML 管道整合到一个体验中。 它适用于移动设备，对管道的管理方式进行了各种改进。 可以向下钻取并查看管道详细信息、运行详细信息、管道分析、作业详细信息、日志等。

新体验包含以下功能：

• 查看和管理多个阶段
• 批准管道运行
• 在管道仍在进行时一直滚动回日志
• 管道的每分支运行状况。

YAML 中的持续部署

我们很高兴提供 Azure Pipelines YAML CD 功能。 我们现在提供统一的 YAML 体验，以便你可以将每个管道配置为一起执行 CI、CD 或 CI 和 CD。 YAML CD 功能引入了一些新的高级功能，这些功能可用于使用多阶段 YAML 管道的所有集合。 其中一些要点包括：

• CI 和 CD) 的多阶段 YAML 管道 (
• 对资源的审批和检查
• 环境和部署策略
• 环境中的 Kubernetes 和 虚拟机 资源
• 查看协作应用
• 为服务连接刷新 UX
• YAML 管道中的资源

如果已准备好开始生成，检查有关生成多阶段 CI/CD 管道的文档或博客。

在 YAML 编辑器中管理管道变量

我们更新了在 YAML 编辑器中管理管道变量的体验。 不再需要转到经典编辑器即可在 YAML 管道中添加或更新变量。

直接从发布中心批准发布

处理待定的审批变得更加容易。 以前，可以从发布的详细信息页批准发布。 现在可以直接从发布中心批准发布。

管道入门改进

入门向导的一个常见要求是能够重命名生成的文件。 目前，它作为存储库的根目录签入 azure-pipelines.yml 。 现在可以在保存管道之前将其更新为其他文件名或位置。

最后，在将文件签入 azure-pipelines.yml 到其他分支时，我们将拥有更多控制权，因为可以选择跳过从该分支创建拉取请求。

预览完全分析的 YAML 文档，而无需提交或运行管道

我们添加了 预览版，但不 运行 YAML 管道的模式。 现在，可以试用 YAML 管道，而无需将其提交到存储库或运行它。 给定现有管道和可选的新 YAML 有效负载，此新 API 将返回完整的 YAML 管道。 在将来的更新中，此 API 将用于新的编辑器功能。

对于开发人员：使用如下所示的 JSON 正文 POST 到 dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview ：

{
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
"
}

响应将包含呈现的 YAML。

YAML 中的 Cron 计划

以前，可以使用 UI 编辑器为 YAML 管道指定计划的触发器。 在此版本中，可以在 YAML 文件中使用 cron 语法计划生成，并利用以下优势：

1. 配置即代码：可以将计划与管道一起作为代码的一部分进行跟踪。
2. 表现力：与使用 UI 相比，你在定义计划方面具有更多的表现力。 例如，可以更轻松地指定每小时启动一次运行的单个计划。
3. 行业标准：许多开发人员和管理员已经熟悉 cron 语法。

schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

我们还使你能够轻松诊断 cron 计划的问题。 “运行管道”菜单中的“计划运行”将预览管道即将推出的几个计划运行，以帮助诊断 cron 计划错误。

汇报到服务连接 UI

我们一直在努力提供更新的用户体验，以管理服务连接。 这些更新使服务连接体验现代化，并与 Azure DevOps 的方向保持一致。 今年早些时候，我们引入了用于服务连接的新 UI 作为预览功能。 感谢所有尝试新体验并向我们提供宝贵反馈的人。

除了用户体验刷新之外，我们还添加了两项功能，这些功能对于在 YAML 管道中使用服务连接至关重要：管道授权、审批和检查。

在此更新中，新用户体验 默认处于打开状态 。 你仍然可以选择退出预览版。

注意

我们计划引入跨项目共享服务Connections作为新功能。 可 在此处找到有关共享体验和安全角色的更多详细信息。

跳过 YAML 管道中的阶段

启动手动运行时，有时可能需要跳过管道中的几个阶段。 例如，如果不想部署到生产环境，或者想要跳过部署到生产环境中的几个环境。 现在可以使用 YAML 管道执行此操作。

更新的运行管道面板显示 YAML 文件中的阶段列表，你可以选择跳过其中一个或多个阶段。 跳过阶段时必须谨慎。 例如，如果第一个阶段生成了后续阶段所需的某些项目，则不应跳过第一阶段。 每当跳过具有下游依赖项的阶段时，运行面板会显示一般警告。 这些依赖项是否是真正的项目依赖项，或者它们是否只是用于部署的排序，这一点由你决定。

跳过阶段等效于重新对阶段之间的依赖关系进行重排。 跳过阶段的任何直接下游依赖项都依赖于跳过阶段上游父级。 如果运行失败，并且尝试重新运行失败的阶段，该尝试也将具有相同的跳过行为。 若要更改跳过的阶段，必须启动新的运行。

服务连接新 UI 作为默认体验

有一个新的服务连接 UI。 此新 UI 基于新式设计标准构建，并附带各种关键功能，以支持多阶段 YAML CD 管道，例如审批、授权和跨项目共享。

在此处详细了解服务连接。

“创建运行”对话框中的管道资源版本选取器

我们在“创建运行”对话框中添加了手动选取管道资源版本的功能。 如果将 管道用作另一个 管道中的资源，现在可以在创建运行时选择该管道的版本。

az Azure Pipelines 的 CLI 改进

管道变量组和变量管理命令

将基于 YAML 的管道从一个项目移植到另一个项目可能很困难，因为需要手动设置管道变量和变量组。 但是，使用管道 变量组 和 变量 管理命令，现在可以编写管道变量和变量组的设置和管理脚本，这些变量和变量组又可以由版本控制，从而轻松共享将管道从一个项目移动到另一个项目的说明。

为 PR 分支运行管道

创建 PR 时，验证更改是否可能中断目标分支上的管道运行可能很困难。 但是，由于能够触发管道运行或将 PR 分支的生成排队，现在可以通过针对目标管道运行更改来验证和可视化这些更改。 有关详细信息 ，请参阅 az pipelines run 和 az pipelines build queue 命令文档。

跳过第一个管道运行

创建管道时，有时需要创建并提交 YAML 文件，而不触发管道运行，因为它可能会导致由于多种原因导致运行错误- 基础结构未就绪或需要创建和更新变量/变量组等。使用 Azure DevOps CLI，现在可以通过包含 --skip-first-run 参数来跳过创建管道时的第一个自动化管道运行。 有关详细信息，请参阅 az pipeline create 命令文档 。

服务终结点命令增强

服务终结点 CLI 命令仅支持 Azure rm 和 github 服务终结点设置和管理。 但是，在此版本中，服务终结点命令允许你通过文件提供配置来创建任何服务终结点，并提供优化的命令 - az devops service-endpoint github 和 az devops service-endpoint azurerm，它们为创建这些类型的服务终结点提供一流的支持。 有关详细信息，请参阅 命令文档 。

部署作业

部署作业是一种特殊类型的 作业 ，用于将应用部署到环境。 通过此更新，我们在部署作业中添加了对 步骤引用 的支持。 例如，可以在一个文件中定义一组步骤，并在部署作业中引用它。

我们还向部署作业添加了对其他属性的支持。 例如，下面是现在可以设置的部署作业的几个属性，

• timeoutInMinutes - 在自动取消之前运行作业的时长
• cancelTimeoutInMinutes - 在终止任务之前给予“即使已取消任务也始终运行”的时间
• 条件 - 有条件地运行作业
• variables - 可以直接添加硬编码值，也可以引用由 Azure Key Vault 支持的变量组、变量组，也可以引用文件中定义的一组变量。
• continueOnError - 如果将来的作业即使此部署作业失败，也应运行;默认值为“false”

有关部署作业和指定部署作业的完整语法的详细信息，请参阅 部署作业。

在 CI 管道中显示关联的 CD 管道信息

添加了对 CD YAML 管道详细信息的支持，其中 CI 管道称为管道资源。 在 CI 管道运行视图中，现在会看到一个新的“关联管道”选项卡，可在其中找到使用管道的所有管道运行以及其中的项目。

YAML 管道中对 GitHub 包的支持

我们最近引入了一种名为 “包 ”的新资源类型，它添加了使用 GitHub 中的 NuGet 和 npm 包作为 YAML 管道中的资源的支持。 作为此资源的一部分，现在可以指定要从 GitHub 使用的包类型 (NuGet 或 npm) 。 还可以在发布新的包版本时启用自动化管道触发器。 目前，支持仅适用于使用 GitHub 中的包，但今后，我们计划扩展支持以使用 NuGet、 npm、 AzureArtifacts 等其他包存储库中的包。 有关详细信息，请参阅以下示例：

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # Github service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the packge to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

注意

现在，GitHub 包仅支持基于 PAT 的身份验证，这意味着包资源中的 GitHub 服务连接应为 PAT 类型。 解除此限制后，我们将为其他类型的身份验证提供支持。

默认情况下，包不会自动下载到作业中，因此我们引入了 getPackage 宏，该宏允许你使用资源中定义的包。 有关详细信息，请参阅以下示例：

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

Kubernetes 环境资源视图中Azure Kubernetes 服务群集链接

我们添加了指向 Kubernetes 环境资源视图的链接，以便导航到相应群集的 Azure 边栏选项卡。 这适用于映射到Azure Kubernetes 服务群集中的命名空间的环境。

通知订阅中的发布文件夹筛选器

文件夹允许组织管道，以便更轻松地进行发现和安全控制。 通常，你可能希望为所有发布管道配置自定义电子邮件通知，这些管道由文件夹下的所有管道表示。 以前，必须配置多个订阅或在订阅中具有复杂的查询才能获得重点电子邮件。 通过此更新，现在可以向 部署已完成 和 审批挂起 事件添加 release folder 子句，并简化订阅。

将工作项与多阶段 YAML 管道链接

目前，你可以自动将工作项与经典版本链接。 但是，这在 YAML 管道中是不可能的。 通过此更新，我们解决了这一差距。 使用指定分支中的代码成功运行管道时，Azure Pipelines 会自动将运行与所有工作项相关联， (这些工作项是通过该代码) 提交推断得出的。 打开工作项时，你将能够看到生成该工作项的代码的运行。 若要对此进行配置，请使用管道的设置面板。

多阶段 YAML 管道运行中的取消阶段

运行多阶段 YAML 管道时，现在可以在阶段正在进行时取消该阶段的执行。 如果你知道阶段将失败，或者你有另一个运行要启动，这将很有帮助。

重试失败阶段

多阶段管道中请求最多的功能之一是能够重试失败的阶段，而无需从头开始。 通过此更新，我们将添加此功能的很大一部分。

现在可以在执行失败时重试管道阶段。 在第一次尝试中失败的任何作业以及那些以传递方式依赖于这些失败作业的作业都会重新尝试。

这可以通过多种方式节省时间。 例如，在一个阶段中运行多个作业时，可能希望每个阶段在不同的平台上运行测试。 如果一个平台上的测试失败，而另一个平台上的测试则通过，你可以通过不重新运行已通过的作业来节省时间。 再举一个例子，部署阶段可能由于网络连接不规则而失败。 重试该阶段有助于节省时间，无需生成另一个生成。

此功能存在一些已知的差距。 例如，无法重试显式取消的阶段。 我们正在努力在将来的更新中缩小这些差距。

多阶段 YAML 管道中的审批

YAML CD 管道可能包含手动审批。 基础结构所有者可以保护其环境，并在任何管道部署阶段之前寻求手动批准。 在基础结构 (环境) 和应用程序 (管道) 所有者之间完全分离角色后，你将确保手动注销特定管道中的部署，并在对所有部署中应用相同检查时获得集中控制。

部署到开发人员的管道在阶段开始时会停止审批。

增加入口超时限制和频率

以前，发布管道中的入口超时限制为三天。 在此更新中，超时限制已增加到 15 天 ，以允许持续时间更长的入口。 我们还将门的频率增加到 30 分钟。

Dockerfile 的新生成映像模板

以前，在创建新管道中为 Dockerfile 创建新管道时，模板建议将映像推送到Azure 容器注册表并部署到Azure Kubernetes 服务。 我们添加了一个新模板，使你能够使用 代理生成映像，而无需推送到容器注册表。

用于配置Azure 应用服务应用设置的新任务

Azure 应用服务允许通过各种设置（如应用设置、连接字符串和其他常规配置设置）进行配置。 现在，我们有了一个新的 Azure Pipelines 任务Azure 应用服务设置，该任务支持在 Web 应用或其任何部署槽位上使用 JSON 语法批量配置这些设置。 此任务可以与其他应用服务任务一起使用，以 部署、 管理和 配置 Web 应用、函数应用或任何其他容器化应用服务。

Azure 应用服务现在支持预览版交换

Azure 应用服务现在在其部署槽位上支持具有预览的交换。 在将应用从过渡槽实际交换到生产槽之前，这是使用生产配置验证应用的好方法。 这也可确保目标/生产槽不会遇到停机。

Azure 应用服务任务现在通过以下新操作支持此多阶段交换：

• 使用预览开始交换 - 使用预览 (多阶段交换) 启动交换，并将目标槽 (例如生产槽) 配置应用到源槽。
• 使用预览完成交换 - 准备好完成挂起的交换时，选择“使用预览完成交换”操作。
• 取消预览交换 - 若要取消挂起的交换，请选择“取消预览交换”。

用于Azure 容器注册表和Docker Hub项目的阶段级别筛选器

以前，Azure 容器注册表和Docker Hub项目的正则表达式筛选器仅在发布管道级别可用。 它们现在也已添加到阶段级别。

YAML 管道中审批的增强功能

我们已启用在服务连接和代理池上配置审批。 对于审批，我们遵循基础结构所有者和开发人员之间的角色分离。 通过在资源（如环境、服务连接和代理池）上配置审批，可以确保使用资源的所有管道运行都需要先获得批准。

此体验类似于为环境配置审批。 在阶段中引用的资源上等待审批时，管道的执行将等待管道手动批准。

Azure Pipelines 中的容器结构测试支持

应用程序中容器的使用正在增加，因此需要可靠的测试和验证。 Azure Pipelines 现在支持 容器结构测试。 此框架提供了一种方便而强大的方法来验证容器的内容和结构。

可以基于四类可以一起运行的测试来验证映像的结构：命令测试、文件存在测试、文件内容测试和元数据测试。 可以使用管道中的结果做出 go/no go 决策。 管道运行中提供了包含错误消息的测试数据，可帮助你更好地排查故障。

输入配置文件和映像详细信息

测试数据和摘要

发布管道的管道修饰器

管道修饰器允许向每个作业的开始和结束添加步骤。 这与将步骤添加到单个定义不同，因为它适用于集合中的所有管道。

我们一直支持生成和 YAML 管道的修饰器，客户使用它们集中控制其作业中的步骤。 我们现在也在扩展对发布管道的支持。 可以创建扩展来添加针对新贡献点的步骤，它们将添加到发布管道中的所有代理作业。

将 Azure 资源管理器 (ARM) 部署到订阅和管理组级别

以前，我们仅支持部署到资源组级别。 通过此更新，我们添加了将 ARM 模板部署到订阅和管理组级别的支持。 在一起部署一组资源但将它们放置在不同的资源组或订阅中时，这将有所帮助。 例如，将 Azure 的备份虚拟机Site Recovery部署到单独的资源组和位置。

多阶段 YAML 管道的 CD 功能

现在可以使用 CI 管道发布的项目并启用管道完成触发器。 在多阶段 YAML 管道中，我们将引入 pipelines 作为资源。 在 YAML 中，现在可以引用另一个管道并启用 CD 触发器。

下面是管道资源的详细 YAML 架构。

resources: 
  pipelines:
  - pipeline: MyAppCI  # identifier for the pipeline resource
    project:  DevOpsProject # project for the build pipeline; optional input for current project
    source: MyCIPipeline  # source pipeline definition name
    branch: releases/M159  # branch to pick the artifact, optional; defaults to all branches
    version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
    trigger:     # Optional; Triggers are not enabled by default.
      branches:  
        include:  # branches to consider the trigger events, optional; defaults to all branches.
        - main
        - releases/*
        exclude:   # branches to discard the trigger events, optional; defaults to none.
        - users/*  

此外，可以使用 任务下载管道资源 - download 发布的项目。

steps: 
- download: MyAppCI  # pipeline resource identifier
    artifact:  A1 # name of the artifact to download; optional; defaults to all artifacts

有关更多详细信息，请参阅 此处的下载项目文档。

协调 Kubernetes 环境上的 Canary 部署策略

持续交付应用程序更新的主要优势之一是能够快速将特定微服务的更新推送到生产环境中。 这使你能够快速响应业务需求的变化。 环境 是作为一流概念引入的，可实现部署策略的业务流程和促进零停机时间发布。 以前，我们支持 runOnce 策略，该策略按顺序执行步骤一次。 借助多阶段管道中对 Canary 策略的支持，现在可以通过缓慢地将更改推出到一小部分来降低风险。 随着你对新版本越来越有信心，你可以开始将其推广到基础结构中的更多服务器，并将更多用户路由到该版本。

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

Kuberenetes 的 Canary 策略将首先部署具有 10% Pod 的更改，然后部署 20% 的更改，同时在 PostRouteTraffic 期间监视运行状况。 如果一切顺利，它将提升到100%。

我们正在寻找有关环境中 VM 资源支持以及跨多台计算机执行滚动部署策略的早期反馈。 联系我们 进行注册。

YAML 管道的审批策略

在 YAML 管道中，我们遵循资源所有者控制的审批配置。 资源所有者在资源以及使用资源暂停进行审批的所有管道上配置审批，然后再开始使用资源的阶段。 基于 SOX 的应用程序所有者通常会限制部署的请求者批准其自己的部署。

现在可以使用 高级审批选项 来配置审批策略，例如请求者不应批准、需要部分用户的批准和审批超时。

ACR 作为一流管道资源

如果需要使用发布到 ACR (Azure 容器注册表) 的容器映像作为管道的一部分，并在发布新映像时触发管道，则可以使用 ACR 容器资源。

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

此外，可以使用预定义的变量访问 ACR 图像元数据。 以下列表包括可用于在管道中定义 ACR 容器资源的 ACR 变量。

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

用于评估管道中项目检查策略的增强功能

我们增强了评估项目检查，以便更轻松地从现成的策略定义列表中添加策略。 策略定义将自动生成并添加到检查配置中，如果需要，可以更新该配置。

支持部署作业中的输出变量

现在可以在部署作业的 生命周期挂钩 中定义输出变量，并在同一阶段的其他下游步骤和作业中使用它们。

在执行部署策略时，可以使用以下语法访问跨作业的输出变量。

• 对于 runOnce 策略： $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• 对于 Canary 策略：$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• 对于 滚动 策略： $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]

// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

 // Map the variable from the job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-16.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

详细了解如何 设置多作业输出变量

避免回滚关键更改

在经典发布管道中，通常依赖于计划的部署进行定期更新。 但是，如果有关键修补程序，可以选择启动带外手动部署。 这样做时，旧版本会继续按计划进行。 这带来了挑战，因为当部署按计划恢复时，手动部署将回滚。 你们中的许多人报告了此问题，我们现在已修复此问题。 使用修补程序，手动启动部署时，将取消环境中所有较旧的计划部署。 仅当排队选项被选为“部署最新并取消其他”时，这才适用。

YAML 管道中的简化资源授权

资源是管道外部的管道使用的任何内容。 必须先对资源进行授权，然后才能使用资源。 以前，在 YAML 管道中使用未经授权的资源时，失败并出现资源授权错误。 必须从失败运行的摘要页授权资源。 此外，如果管道使用的变量引用了未经授权的资源，则管道会失败。

现在，我们可以更轻松地管理资源授权。 运行将在使用资源的阶段开始时等待资源的权限，而不是失败。 资源所有者可以从“安全”页查看管道并为资源授权。

评估项目检查

现在可以定义一组策略，并将策略评估添加为容器映像项目的环境检查。 管道运行时，执行会在启动使用环境的阶段之前暂停。 根据所部署映像的可用元数据评估指定的策略。 当策略成功时，检查通过，并在检查失败时将阶段标记为失败。

汇报 ARM 模板部署任务

以前，我们没有在 ARM 模板部署任务中筛选服务连接。 如果选择较低范围的服务连接来执行到更广范围的 ARM 模板部署，则可能会导致部署失败。 现在，我们添加了服务连接的筛选，以根据所选部署范围筛选出范围较低的服务连接。

在环境中查看应用

ReviewApp 将 Git 存储库中的每个拉取请求部署到动态环境资源。 在将这些更改合并到 main 分支并部署到生产环境之前，审阅者可以查看这些更改的外观以及其他依赖服务。 这将使你能够轻松创建和管理 reviewApp 资源，并受益于环境功能的所有可跟踪性和诊断功能。 通过使用 reviewApp 关键字 (keyword) ，可以创建资源的克隆 (基于环境中的现有资源动态创建新资源) 并将新资源添加到环境中。

下面是在环境中使用 reviewApp 的示例 YAML 代码片段。

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MainNamespace

从管道收集自动和用户指定的元数据

现在可以从管道任务启用自动和用户指定的元数据收集。 可以使用元数据通过评估项目检查在环境中强制实施项目策略。

使用环境的 VM 部署

环境中最需要的功能之一是 VM 部署。 通过此更新，我们将在环境中启用虚拟机资源。 现在可以跨多台计算机协调部署，并使用 YAML 管道执行 滚动 更新。 还可以在每个目标服务器上直接安装代理，并将滚动部署驱动到这些服务器。 此外，还可以在目标计算机上使用完整的任务目录。

滚动部署将一组计算机上的旧版应用程序的实例替换为新版应用程序的实例， (每次迭代中的滚动集) 。

例如，下面的滚动部署在每个迭代中最多更新五个目标。 maxParallel 将确定可并行部署的目标数。 所选内容包含必须随时保持可用的目标数，不包括要部署到的目标。 它还用于确定部署过程中的成功和失败条件。

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

注意

通过此更新，当前管道和关联管道资源中的所有可用项目仅在生命周期挂钩中 deploy 下载。 但是，可以通过指定“ 下载管道项目”任务来选择下载。 此功能存在一些已知的差距。 例如，重试某个阶段时，它将在所有 VM 上重新运行部署，而不仅仅是在失败的目标上。 我们正在努力在将来的更新中缩小这些差距。

对部署的额外控制

一段时间以来，Azure Pipelines 一直支持通过手动审批控制的部署。 借助最新的增强功能，现在可以对部署进行额外的控制。 除了审批，资源所有者现在还可以添加自动 checks 验证安全和质量策略。 这些检查可用于触发操作，然后等待操作完成。 使用其他检查，现在可以基于多个源定义运行状况条件，并确保面向资源的所有部署都是安全的，无论执行部署的 YAML 管道如何。 可以根据检查的指定重试间隔定期重复评估每个检查。 现在提供以下附加检查：

• 调用任何 REST API 并基于响应正文或来自外部服务的回调执行验证
• 调用 Azure 函数并根据响应或函数的回调执行验证
• 查询 Azure Monitor 规则以获取活动警报
• 确保管道扩展一个或多个 YAML 模板

审批通知

将审批添加到环境或服务连接时，使用该资源的所有多阶段管道都会在阶段开始时自动等待审批。 指定的审批者需要完成审批，然后管道才能继续。

通过此更新，会向审批者发送等待审批的电子邮件通知。 用户和团队所有者可以使用 通知设置选择退出或配置自定义订阅。

从 Azure 门户 配置部署策略

借助此功能，我们可以更轻松地配置使用所选部署策略的管道，例如 Rolling、 Canary 或 Blue-Green。 使用这些现成的策略，可以安全的方式推出更新并降低相关的部署风险。 若要访问此功能，请单击 Azure 虚拟机中的“持续交付”设置。 在配置窗格中，系统会提示你选择有关将在其中创建管道的 Azure DevOps 项目、部署组、发布要部署的包的生成管道以及所选部署策略的详细信息。 继续操作将配置一个功能齐全的管道，用于将所选包部署到此虚拟机。

有关更多详细信息，检查有关配置部署策略的文档。

运行时参数

利用运行时参数，能够更好地控制可以传递给管道的值。 与变量不同，运行时参数具有数据类型，并且不会自动成为环境变量。 使用运行时参数可以实现以下功能：

• 在运行时为脚本和任务提供不同的值
• 控制参数类型、允许的范围和默认值
• 使用模板表达式动态选择作业和阶段

若要详细了解运行时参数，请参阅 此处的文档。

在管道中使用扩展关键字 (keyword)

目前，管道可以分解为模板，促进重用并减少样板。 管道的整体结构仍由根 YAML 文件定义。 在此更新中，我们添加了一种更结构化的方式来使用管道模板。 根 YAML 文件现在可以使用关键字 (keyword) 扩展来指示可以在另一个文件中找到main管道结构。 这使你可以控制哪些段可以扩展或更改，哪些段是固定的。 我们还使用数据类型增强了管道参数，以清除可以提供的挂钩。

此示例演示如何提供简单的挂钩供管道作者使用。 模板将始终运行生成，可以选择运行管道提供的其他步骤，然后运行可选的测试步骤。

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

可在队列时重写的控制变量

以前，可以在开始新运行之前使用 UI 或 REST API 更新任何变量的值。 虽然管道的作者可以将某些变量标记为 _settable at queue time_，但系统未强制执行此操作，也不会阻止设置其他变量。 换句话说，设置仅用于在启动新运行时提示其他输入。

我们添加了强制参数 _settable at queue time_ 的新集合设置。 这样，便可以控制在启动新运行时可以更改的变量。 今后，无法更改作者 _settable at queue time_未标记为 的变量。

注意

默认情况下，此设置在现有集合中处于关闭状态，但在创建新的 Azure DevOps 集合时，此设置默认处于打开状态。

YAML 管道中新的预定义变量

变量为你提供了一种简便方法，可以将关键数据位导入管道的各个部分。 通过此更新，我们已向部署作业添加了一些预定义变量。 这些变量由系统自动设置，范围限定为特定的部署作业，并且是只读的。

• Environment.Id - 环境的 ID。
• Environment.Name - 部署作业所面向的环境的名称。
• Environment.ResourceId - 部署作业所面向的环境中的资源 ID。
• Environment.ResourceName - 部署作业所面向的环境中的资源的名称。

签出多个存储库

管道通常依赖于多个存储库。 可以具有不同的存储库，其中包含生成代码所需的源、工具、脚本或其他项。 以前，必须将这些存储库添加为子模块或手动脚本才能运行 git 签出。 现在，除了用于存储 YAML 管道的存储库之外，还可以提取和检查其他存储库。

例如，如果有一个名为 MyCode 的存储库，其中包含一个 YAML 管道，另一个名为 “工具”的存储库，则 YAML 管道将如下所示：

resources:
  repositories:
  - repository: tools
    name: Tools
    type: git

steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)

第三步将显示源目录中的 MyCode 和 Tools 两个目录。

支持Azure Repos Git 存储库。 有关详细信息，请参阅 多存储库签出。

在运行时获取有关多个存储库的详细信息

管道运行时，Azure Pipelines 会添加有关触发运行的存储库、分支和提交的信息。 由于 YAML 管道支持签出多个存储库，你可能还希望了解为其他存储库签出的存储库、分支和提交。 此数据通过运行时表达式提供，现在可以将其映射到变量中。 例如：

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

允许存储库引用其他Azure Repos集合

以前，在 YAML 管道中引用存储库时，所有Azure Repos存储库必须与管道位于同一集合中。 现在，可以使用服务连接指向其他集合中的存储库。 例如：

resources:
  repositories:
  - repository: otherrepo
    name: ProjectName/RepoName
    endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo

MyServiceConnection 指向另一个 Azure DevOps 集合，并具有可以访问另一个项目中的存储库的凭据。 存储库 self 和 otherrepo都将最终签出。

重要

MyServiceConnection必须是Azure Repos/Team Foundation Server 服务连接，请参阅下图。

管道资源元数据作为预定义变量

我们在管道中为 YAML 管道资源添加了预定义变量。 下面是可用的管道资源变量的列表。

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

kustomize 和 kompose 作为 KubernetesManifest 任务中的烘焙选项

kustomize (Kubernetes sig-cli 的一部分) 使你可以出于多种目的自定义原始的无模板 YAML 文件，并使原始 YAML 保持不变。 KubernetesManifest 任务的 bake 操作下添加了 kustomize 选项，以便包含 kustomization.yaml 文件的任何文件夹都可用于生成 KubernetesManifest 任务的部署操作中使用的清单文件。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose 会将 Docker Compose 文件转换为 Kubernetes 资源。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

支持 HelmDeploy 任务中的群集管理员凭据

以前， HelmDeploy 任务使用群集用户凭据进行部署。 这会导致启用了 Azure Active Directory 的 RBAC 群集出现交互式登录提示和管道故障。 为了解决此问题，我们添加了一个复选框，允许使用群集管理员凭据而不是群集用户凭据。

Docker Compose 任务中的参数输入

Docker Compose 任务中引入了一个新字段，用于添加参数，例如 --no-cache。 运行生成等命令时，任务将向下传递 参数。

GitHub 发布任务增强功能

我们对 GitHub 发布任务进行了多项增强。 现在，可以通过指定标记正则表达式来更好地控制使用标记模式字段创建发布，并且仅当使用匹配字符串标记触发提交时才会创建发布。

我们还添加了自定义更改日志的创建和格式设置的功能。 在更改日志配置的新部分中，现在可以指定应与当前版本进行比较的版本。 “ 与版本比较 ”可以是最后一个完整版本 (不包括预发行) 、上一个非草稿版本或任何与你提供的发布标记匹配的先前版本。 此外，任务还提供更改日志类型字段来设置更改日志的格式。 根据所选内容，更改日志将显示提交列表或基于标签分类的问题/PR 列表。

打开策略代理安装程序任务

Open Policy Agent 是一个开放源代码的常规用途策略引擎，可实现统一的上下文感知策略强制实施。 我们添加了“打开策略代理”安装程序任务。 对于基础结构即代码提供程序的管道内策略强制实施，它特别有用。

例如，Open Policy Agent 可以在管道中评估 Rego 策略文件和 Terraform 计划。

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

支持 Azure CLI 任务中的 PowerShell 脚本

以前，可以在 Azure CLI 任务中执行批处理和 bash 脚本。 通过此更新，我们向任务添加了对 PowerShell 和 PowerShell 核心脚本的支持。

KubernetesManifest 任务中基于服务网格接口的金丝雀部署

以前，在 KubernetesManifest 任务中指定金丝雀策略时，该任务将创建基线和金丝雀工作负载，其副本等于用于稳定工作负载的副本的百分比。 这与在请求级别将流量拆分为所需百分比并不完全相同。 为了解决此问题，我们向 KubernetesManifest 任务添加了对基于 服务网格接口 的 Canary 部署的支持。

服务网格接口抽象允许使用服务网格提供程序（如 Linkerd 和 Istio）进行即插即用配置。 现在，KubernetesManifest 任务无需在部署策略的生命周期内将 SMI 的 TrafficSplit 对象映射到稳定、基线和 Canary 服务。 稳定、基线和 Canary 之间所需的流量拆分百分比更准确，因为流量拆分百分比控制在服务网格平面中的请求上。

下面是以滚动方式执行基于 SMI 的 Canary 部署的示例。

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

Azure 文件复制任务现在支持 AzCopy V10

可以在生成或发布管道中使用 Azure 文件复制任务，将文件复制到 Microsoft 存储 blob 或虚拟机 (VM) 。 该任务使用 AzCopy（命令行实用工具版本）从/向 Azure 存储帐户快速复制数据。 在此更新中，我们添加了对 AzCopy V10（ AzCopy 最新版本）的支持。

命令 azcopy copy 仅支持与其关联的 参数 。 由于 AzCopy 语法的更改，某些现有功能在 AzCopy V10 中不可用。 其中包括：

• 指定日志位置
• 复制后清理日志和计划文件
• 作业失败时恢复复制

此版本的任务支持的其他功能包括：

• 源的文件名/路径中的通配符
• 在没有提供参数时基于文件扩展名推断内容类型
• 通过传递参数定义日志文件的日志详细程度

通过限制访问令牌的范围提高管道安全性

在 Azure Pipelines 中运行的每个作业都会获得一个访问令牌。 访问令牌由任务和脚本用来回调到 Azure DevOps 中。 例如，我们使用访问令牌获取源代码、上传日志、测试结果、项目或对 Azure DevOps 进行 REST 调用。 将为每个作业生成一个新的访问令牌，并在作业完成后过期。 在此更新中，我们添加了以下增强功能。

• 阻止令牌访问团队项目外部的资源

  到目前为止，所有管道的默认范围都是团队项目集合。 可以将范围更改为经典生成管道中的团队项目。 但是，对于经典发布或 YAML 管道，你没有这种控制。 在此更新中，我们将引入一个集合设置，以强制每个作业获取项目范围的令牌，无论管道中配置了什么。 我们还在项目级别添加了 设置。 现在，你创建的每个新项目和集合都将自动启用此设置。

  注意

  集合设置将替代项目设置。

  如果管道使用访问令牌访问团队项目外部的资源，在现有项目和集合中打开此设置可能会导致某些管道失败。 若要缓解管道故障，可以显式授予 项目生成服务帐户 对所需资源的访问权限。 强烈建议启用这些安全设置。

• 限制生成服务存储库范围访问

  Azure Pipelines 通过限制访问令牌的范围来提高管道安全性，现在可以将其存储库访问权限缩小到 基于 YAML 的管道所需的存储库。 这意味着，如果管道的访问令牌泄露，则只能看到存储库 (管道中使用的) 。 以前，访问令牌适用于项目中的任何Azure Repos存储库，也可能适用于整个集合。

  默认情况下，对于新项目和集合，此功能将启用。 对于现有集合，必须在“集合设置”“管道>设置”>中启用它。 使用此功能时，生成所需的所有存储库 (即使是使用脚本) 克隆的存储库也必须包含在管道的 存储库资源 中。

• 删除访问令牌的某些权限

  默认情况下，我们将向访问令牌授予多个权限，其中一个权限是 队列生成。 在此更新中，我们删除了访问令牌的此权限。 如果管道需要此权限，可以将其显式授予 Project Build Service Account 或 Project Collection Build Service Account ，具体取决于所使用的令牌。

服务连接的项目级安全性

我们为服务连接添加了中心级安全性。 现在，可以在集中位置为所有服务连接添加/删除用户、分配角色和管理访问权限。

步骤目标和命令隔离

Azure Pipelines 支持在容器中或在代理主机上运行作业。 以前，整个作业都设置为这两个目标之一。 现在，单个步骤 (任务或脚本) 可以在所选的目标上运行。 步骤也可能针对其他容器，因此管道可以在专用的专用容器中运行每个步骤。

容器可以充当隔离边界，防止代码在主机上进行意外更改。 步骤 与代理通信的方式以及从代理访问服务 的方式不受容器中隔离步骤的影响。 因此，我们还引入了可用于步骤目标的命令限制模式。 启用此选项将限制步骤可从代理请求的服务。 它将无法再附加日志、上传项目和某些其他操作。

下面是一个综合示例，显示了在作业容器中的主机和其他容器中的运行步骤：

resources:
  containers:
  - container: python
    image: python:3.8
  - container: node
    image: node:13.2

jobs:
- job: example
  container: python

  steps:
  - script: echo Running in the job container

  - script: echo Running on the host
    target: host

  - script: echo Running in another container, in restricted commands mode
    target:
      container: node
      commands: restricted

只读变量

系统变量记录为不可变，但实际上它们可能被任务覆盖，下游任务会选取新值。 通过此更新，我们加强了管道变量的安全性，使系统和队列时间变量成为只读的。 此外，还可以通过将 YAML 变量标记为只读， 如下所示。

variables:
- name: myVar
  value: myValue
  readonly: true

服务连接的基于角色的访问

我们为服务连接添加了基于角色的访问。 以前，只能通过预定义的 Azure DevOps 组（例如终结点管理员和终结点创建者）来管理服务连接安全性。

作为这项工作的一部分，我们引入了读者、用户、创建者和管理员的新角色。 可以通过项目中的服务连接页设置这些角色，这些角色由各个连接继承。 在每个服务连接中，可以选择打开或关闭继承，并替代服务连接范围内的角色。

在此处详细了解服务连接安全性。

服务连接的跨项目共享

我们启用了跨项目共享服务连接的支持。 现在可以安全可靠地与项目共享服务连接。

在此处详细了解服务连接共享。

管道和 ACR 资源的可追溯性

在管道中使用管道和 ACR 容器资源时，我们可确保完全的 E2E 可跟踪性。 对于 YAML 管道使用的每个资源，可以追溯到提交、工作项和项目。

在管道运行摘要视图中，可以看到：

• 触发运行的资源版本。 现在，可以在完成另一个 Azure 管道运行或将容器映像推送到 ACR 时触发管道。

  

• 管道使用的 提交 。 还可以查找管道使用的每个资源的提交明细。

  

• 与管道使用的每个资源关联的 工作项 。

• 可供运行使用 的项目 。

  

在环境的部署视图中，可以看到部署到环境的每个资源的提交和工作项。

支持大型测试附件

通过 Azure Pipelines 中的发布测试结果任务，可以在执行测试时发布测试结果，以提供全面的测试报告和分析体验。 到目前为止，测试运行和测试结果的测试附件限制为 100MB。 这限制了大文件的上传，例如故障转储或视频。 在此更新中，我们添加了对大型测试附件的支持，使你可以获得所有可用数据来排查失败的测试问题。

你可能会在日志中看到 VSTest 任务或发布测试结果任务返回 403 或 407 错误。 如果在防火墙后面使用自承载生成或发布代理来筛选出站请求，则需要进行一些配置更改才能使用此功能。 ​

为了解决此问题，建议将 出站请求 的防火墙更新为 https://*.vstmrblob.vsassets.io。 可 在此处的文档中找到故障排除信息。 ​

注意

仅当使用自承载 Azure Pipelines 代理并且位于筛选出站流量的防火墙后面时，才需要这样做。 如果在云中使用 Microsoft 托管的代理，或者未筛选出站网络流量，则无需执行任何操作。

显示每个作业的正确池信息

以前，当你使用矩阵来扩展作业或变量来标识池时，我们有时会在日志页中解析不正确的池信息。 这些问题已得到解决。

新分支的 CI 触发器

在创建新分支且该分支没有更改时，不触发 CI 生成是一个长期挂起的请求。 请开考虑以下示例：

• 使用 Web 界面基于现有分支创建新分支。 如果分支筛选器与新分支的名称匹配，这将立即触发新的 CI 生成。 这是不需要的，因为与现有分支相比，新分支的内容相同。
• 你有一个包含两个文件夹的存储库 - 应用和文档。为 CI 设置路径筛选器以匹配“应用”。 换句话说，如果已将更改推送到文档，则不希望创建新的生成。在本地创建新分支，对文档进行一些更改，然后将该分支推送到服务器。 我们用于触发新的 CI 生成。 这是不需要的，因为显式要求不要在 docs 文件夹中查找更改。 但是，由于处理新分支事件的方式，似乎也对应用文件夹进行了更改。

现在，我们有了一种更好的方法来处理新分支的 CI 来解决这些问题。 发布新分支时，我们会在该分支中显式查找新提交，并检查它们是否与路径筛选器匹配。

作业可以访问前一阶段的输出变量

输出变量现在可以在基于 YAML 的管道中跨阶段使用。 这有助于将有用的信息（如 go/no-go 决策或生成的输出的 ID）从一个阶段传递到下一个阶段。 结果 (上一阶段的状态) ，其作业也可用。

输出变量仍由作业中的步骤生成。 阶段引用 dependencies.jobName.outputs['stepName.variableName']而不是 ，阶段引用 stageDependencies.stageName.jobName.outputs['stepName.variableName']。

注意

默认情况下，管道中的每个阶段都依赖于 YAML 文件中与其紧邻的前面一个阶段。 因此，每个阶段都可以使用上一阶段的输出变量。 可以更改依赖项关系图，这也会更改可用的输出变量。 例如，如果阶段 3 需要阶段 1 中的变量，则需要在阶段 1 上声明显式依赖项。

在池级别禁用自动代理升级

目前，管道代理将在需要时自动更新到最新版本。 当有新功能或任务需要更新的代理版本才能正常运行时，通常会发生这种情况。 通过此更新，我们将添加在池级别禁用自动升级的功能。 在此模式下，如果没有正确版本的代理连接到池，管道将失败并显示明确的错误消息，而不是请求代理进行更新。 对于具有自承载池和非常严格的变更控制要求的客户，此功能最感兴趣。 自动更新默认启用，我们不建议大多数客户禁用它们。

代理诊断

我们为许多常见的代理相关问题（例如许多网络问题和升级失败的常见原因）添加了诊断。 若要开始使用诊断，请在 Windows 上使用 run.sh --诊断 或 run.cmd --诊断。

YAML 管道的服务挂钩

将服务与 YAML 管道集成变得更加简单。 使用 YAML 管道的服务挂钩事件，现在可以根据管道运行进度在自定义应用或服务中驱动活动。 例如，可以在需要审批时创建支持票证，在阶段完成后启动监视工作流，或者在阶段失败时向团队的移动设备发送推送通知。

所有事件都支持筛选管道名称和阶段名称。 也可以针对特定环境筛选审批事件。 同样，状态更改事件可以按管道运行或阶段的新状态进行筛选。

优化集成

Optimizely 是适用于产品团队的强大 A/B 测试和功能标记平台。 Azure Pipelines 与 Optimizely 试验平台的集成使产品团队能够加快测试、学习和部署速度，同时从 Azure Pipelines 获得所有 DevOps 优势。

适用于 Azure DevOps 的 Optimizely 扩展向生成和发布管道添加了试验和功能标志推出步骤，因此可以使用 Azure Pipelines 持续迭代、推出和回滚功能。

在此处详细了解 Azure DevOps Optimizely 扩展。

将 GitHub 版本添加为项目源

现在，可以在 Azure DevOps 发布管道中将 GitHub 版本链接为项目源。 这样，就可以在部署过程中使用 GitHub 版本。

在发布管道定义中单击“ 添加项目 ”时，将找到新的 GitHub 发布 源类型。 可以提供服务连接和 GitHub 存储库来使用 GitHub 版本。 还可以为 GitHub 版本选择默认版本，以作为最新的特定标记版本使用，或在发布创建时选择。 链接 GitHub 版本后，它会自动下载并在发布作业中提供。

Terraform 与 Azure Pipelines 集成

Terraform 是一种开源工具，用于安全高效地开发、更改和版本控制基础结构。 Terraform 将 API 编入声明性配置文件，允许你使用高级配置语言定义和预配基础结构。 可以使用 Terraform 扩展跨所有主要基础结构提供商创建资源：Azure、Amazon Web Services (AWS) 和 Google Cloud Platform (GCP) 。

若要了解有关 Terraform 扩展的详细信息，请参阅 此处的文档。

与 Google Analytics 集成

借助 Google Analytics 试验框架，可以测试网站或应用几乎任何更改或变化，以衡量其对特定目标的影响。 例如，你可能希望用户完成 (活动，例如购买、注册新闻稿) 和/或要提高 (的指标，例如收入、会话持续时间、跳出率) 。 通过这些活动，可以根据更改对功能性能的直接影响来确定值得实现的更改。

适用于 Azure DevOps 的 Google Analytics 试验扩展为生成和发布管道添加了试验步骤，因此，你可以通过持续管理试验来加快迭代、学习和部署，同时从 Azure Pipelines 获得所有 DevOps 优势。

可以从市场下载 Google Analytics 试验扩展 。

更新了 ServiceNow 与 Azure Pipelines 的集成

适用于 ServiceNow 的 Azure Pipelines 应用有助于集成 Azure Pipelines 和 ServiceNow 更改管理。 通过此更新，你可以与 ServiceNow 的纽约版本集成。 现在可以使用 OAuth 和基本身份验证在两个服务之间进行身份验证。 此外，现在可以配置高级成功条件，以便可以使用任何更改属性来决定入口结果。

从 VSCode Create Azure Pipelines

我们已向适用于 VSCode 的 Azure Pipelines 扩展添加了一项新功能。 现在，无需离开 IDE 即可直接从 VSCode 创建 Azure Pipelines。

不起的 bug 管理和解决

我们引入了不规则的测试管理，以支持具有检测、报告和解决的端到端生命周期。 为了进一步增强它，我们添加了不起的测试 bug 管理和解决方法。

在调查不合格测试时，可以使用 Bug 操作创建 Bug，然后将该 Bug 分配给开发人员以进一步调查不合格测试的根本原因。 bug 报告包括有关管道的信息，例如错误消息、堆栈跟踪以及与测试关联的其他信息。

解决或关闭 bug 报告后，将自动取消测试的标记为不平淡。

如果未运行最小测试数，请将 VSTest 任务设置为失败

VSTest 任务使用用户输入 (测试文件、筛选条件等) 以及特定于所用测试框架的测试适配器来发现和运行测试。 更改用户输入或测试适配器可能会导致未发现测试，并且仅运行一部分预期测试的情况。 这可能会导致管道成功的情况，因为跳过测试，而不是因为代码质量足够高。 为了帮助避免这种情况，我们在 VSTest 任务中添加了一个新选项，该选项允许指定任务必须运行的最小测试数才能通过。

VSTest TestResultsDirectory 选项在任务 UI 中可用

VSTest 任务将测试结果和关联的文件 $(Agent.TempDirectory)\TestResults 存储在 文件夹中。 我们在任务 UI 中添加了一个选项，使你可以配置其他文件夹来存储测试结果。 现在，需要特定位置的文件的任何后续任务都可以使用这些文件。

自动测试错误消息中的 Markdown 支持

我们已为自动测试的错误消息添加了 markdown 支持。 现在，可以轻松地为测试运行和测试结果设置错误消息的格式，以提高可读性并简化 Azure Pipelines 中的测试失败故障排除体验。 可 在此处找到支持的 markdown 语法。

使用管道修饰器在部署作业中自动注入步骤

现在可以将 管道修饰器 添加到部署作业。 可以将任何自定义步骤 (例如漏洞扫描程序) 自动注入到每个部署作业的每个 生命周期挂钩 执行。 由于管道修饰器可以应用于集合中的所有管道，因此这可以用作强制实施安全部署做法的一部分。

此外，部署作业可以作为容器作业与服务 side-car（如果已定义）一起运行。

Test Plans

“新建测试计划”页

新的Test Plans页 (Test Plans *) 可用于所有 Azure DevOps 集合。 新页面提供了简化的视图，可帮助你专注于手头的任务 - 测试规划、创作或执行。 它也是无混乱的，并与 Azure DevOps 产品/服务的其余部分一致。

帮助我了解新页面

新的Test Plans页共有 6 个部分，其中前 4 个部分是新的，而“图表 & 扩展性”部分是现有功能。

1. 测试计划标头：用于查找、收藏、编辑、复制或克隆测试计划。
2. 测试套件树：用于添加、管理、导出或订购测试套件。 利用此功能还可以分配配置并执行用户验收测试。
3. 定义选项卡：通过此选项卡整理、添加和管理所选测试套件中的测试用例。
4. “执行”选项卡：通过此选项卡分配和执行测试，或找到要钻取的测试结果。
5. “图表”选项卡：通过图表跟踪测试执行和状态，这些图表也可以固定到仪表板。
6. 扩展性：支持产品中的 当前扩展点 。

下面让我们大致了解这些新部分。

1. 测试计划标头

任务

使用“测试计划”标头可以执行以下任务：

• 将测试计划标记为收藏夹
• 取消标记收藏的测试计划
• 在喜爱的测试计划之间轻松导航
• 查看测试计划的迭代路径，其中明确指示测试计划是“当前”还是“过去”
• 查看“测试进度”报表的快速摘要，其中包含导航到该报表的链接
• 导航回“全部/我的Test Plans”页

上下文菜单选项

“测试计划”标头上的上下文菜单提供以下选项：

• 复制测试计划：这是一个新选项，可用于快速复制当前测试计划。 请参阅以下详细信息。
• 编辑测试计划：此选项允许编辑“测试计划”工作项窗体以管理工作项字段。
• 测试计划设置：此选项允许配置“测试运行”设置， (将生成或发布管道) 与“测试结果”设置相关联

复制测试计划 (新功能)

建议按冲刺/发布创建新的测试计划。 执行此操作时，通常可以复制上一个周期的测试计划，如果更改很少，复制的测试计划就可以用于新周期。 为了简化此过程，我们在新页面上启用了“复制测试计划”功能。 利用它可以复制或克隆测试计划。 此处介绍了其后备 REST API，API 还允许跨项目复制/克隆测试计划。
有关Test Plans用法的更多指南，请参阅此处。

2. 测试套件树

任务

使用测试套件标头可以执行以下任务：

• 展开/折叠：使用此工具栏选项可以展开或折叠套件层次结构树。
• 显示子套件中的测试点：仅在“执行”选项卡中显示此工具栏选项。这使你可以在一个视图中查看给定套件及其子级的所有测试点，以便更轻松地管理测试点，而无需一次导航到单个套件。
• 订单套件：可以拖放套件以重新排序套件的层次结构，或在测试计划中将它们从一个套件层次结构移到另一个套件层次结构。

上下文菜单选项

测试套件树上的上下文菜单提供以下选项：

• Create新套件：可以创建 3 种不同类型的套件，如下所示：
  • 使用静态套件或文件夹套件来组织测试。
  • 使用基于要求的套件直接链接到要求/用户情景，实现无缝可跟踪性。
  • 使用基于查询的动态组织符合查询条件的测试用例。
• 分配配置：可以分配套件的配置 (示例：Chrome、Firefox、EdgeChromium) 这些配置将适用于所有现有测试用例或稍后添加到此套件的新测试用例。
• 导出为 pdf/电子邮件：将测试计划属性、测试套件属性以及测试用例和测试点的详细信息导出为“电子邮件”或“打印到 pdf”。
• 打开测试套件工作项：此选项允许编辑“测试套件工作项”窗体以管理工作项字段。
• 分配测试人员以运行所有测试：此选项对于用户验收测试非常有用， (UAT) 方案中，同一测试需要由多个测试人员运行/执行，通常属于不同部门。
• 重命名/删除：这些选项允许你管理套件名称或从测试计划中删除套件及其内容。

3. 定义选项卡

使用“定义”选项卡可以整理、添加和管理测试套件的测试用例。 而“执行”选项卡用于分配并执行测试点。

“定义”选项卡和某些操作仅适用于具有基本 + Test Plans访问级别或等效访问级别的用户。 其他所有内容都应由具有“基本”访问级别的用户执行。

任务

使用“定义”选项卡可以执行以下任务：

• 使用工作项表单添加新测试用例：此选项允许使用工作项窗体创建新的测试用例。 创建的测试用例将自动添加到套件中。
• 使用网格添加新测试用例：此选项允许使用测试用例网格视图创建一个或多个测试用例。 创建的测试用例将自动添加到套件中。
• 使用查询添加现有测试用例：此选项允许通过指定查询将现有测试用例添加到套件。
• 通过拖放对测试用例进行排序：可以通过在给定套件中拖放一个或多个测试用例来重新排序测试用例。 测试用例的顺序仅适用于手动测试用例，不适用于自动测试。
• 将测试用例从一个套件移动到另一个套件：使用拖放，可以将测试用例从一个测试套件移动到另一个测试套件。
• 显示网格：可以使用网格模式查看/编辑测试用例以及测试步骤。
• 全屏视图：可以使用此选项在全屏模式下查看整个“定义”选项卡的内容。
• 筛选：使用筛选栏，可以使用“测试用例标题”、“分配给”和“状态”字段筛选测试用例列表。 还可以通过单击列标题对列表进行排序。
• 列选项：可以使用“列选项”管理“定义”选项卡中可见的列列表。 可供选择的列列表主要是测试用例工作项窗体中的字段。

上下文菜单选项

“定义”选项卡中“测试用例”节点上的上下文菜单提供以下选项：

• 打开/编辑测试用例工作项窗体：此选项允许你使用工作项窗体编辑测试用例，在其中编辑工作项字段，包括测试步骤。
• 编辑测试用例：此选项允许批量编辑测试用例工作项字段。 但是，不能使用此选项批量编辑测试步骤。
• 在网格中编辑测试用例：此选项允许使用网格视图批量编辑所选测试用例，包括测试步骤。
• 分配配置：此选项允许使用测试用例级别配置替代套件级别配置。
• 删除测试用例：此选项允许从给定套件中删除测试用例。 不过，它不会更改基础测试用例工作项。
• Create测试用例的副本/克隆：此选项允许创建所选测试用例的副本/克隆。 有关详细信息，请参阅下文。
• 查看链接项：此选项允许查看给定测试用例的链接项。 有关详细信息，请参阅下文。

(新功能) 复制/克隆测试用例

对于想要复制/克隆测试用例的方案，可以使用“复制测试用例”选项。 可以指定要在其中创建复制/克隆测试用例的目标项目、目标测试计划和目标测试套件。 此外，还可以指定是否要包含要流向克隆副本的现有链接/附件。

(新功能) 查看链接项

测试项目、要求和 bug 之间的可追溯性是Test Plans产品的关键价值主张。 使用“查看链接项”选项，可以轻松查看此测试用例链接的所有链接要求、使用此测试用例的所有测试套件/测试计划，以及作为测试执行一部分提交的所有 bug。

4.“执行”选项卡

使用“定义”选项卡可以整理、添加和管理测试套件的测试用例。 而“执行”选项卡用于分配并执行测试点。

什么是测试点？ 测试用例本身不可执行。 将测试用例添加到测试套件时，将生成测试点 () 。 测试点是测试用例、测试套件、配置和测试人员的唯一组合。 示例：如果你有一个测试用例作为“测试登录功能”，并向其添加 2 个配置作为 Edge 和 Chrome，则这会导致 2 个测试点。 现在可以执行这些测试点。 执行时，将生成测试结果。 通过测试结果视图 (执行历史记录) 可以看到测试点的所有执行。 测试点的最新执行是在“执行”选项卡中看到的内容。
因此，测试用例是可重用的实体。 通过将测试点包含在测试计划或套件中，将生成测试点。 通过执行测试点，可以确定正在开发的产品或服务的质量。

新页面的主要优势之一是，对于主要执行测试执行/跟踪 (只需拥有“基本”访问级别) 的用户，他们不会因为套件管理的复杂性而不知所措， (定义选项卡对于此类用户) 隐藏。

“定义”选项卡和某些操作仅适用于具有基本 + Test Plans访问级别或等效访问级别的用户。 其他所有内容（包括“执行”选项卡）都应可由具有“基本”访问级别的用户执行。

任务

使用“执行”选项卡可以执行以下任务：

• 批量标记测试点：此选项允许快速标记测试点的结果 - 通过、失败、阻止或不适用，而无需通过测试运行程序运行测试用例。 结果可以一次性标记为一个或多个测试点。
• 运行测试点：此选项允许你通过单独执行每个测试步骤并使用测试运行程序将其标记为通过/失败来运行测试用例。 根据要测试的应用程序，可以使用“Web 运行器”来测试“Web 应用程序”或“桌面运行器”来测试桌面和/或 Web 应用程序。 还可以调用“使用选项运行”来指定要对其执行测试的生成。
• 列选项：可以使用“列选项”管理“执行”选项卡中可见的列列表。 可供选择的列列表与测试点相关联，例如“运行者”、“分配的测试人员”、“配置”等。
• 全屏视图：可以使用此选项在全屏模式下查看整个“执行”选项卡的内容。
• 筛选：使用筛选栏，可以使用“测试用例标题”、“分配到”、“状态”、“测试结果”、“测试人员”和“配置”字段筛选测试点列表。 还可以通过单击列标题对列表进行排序。

上下文菜单选项

“执行”选项卡中“测试点”节点上的上下文菜单提供以下选项：

• 标记测试结果：与上述相同，可用于快速标记测试点的结果 - 通过、失败、阻止或不适用。
• 运行测试点：与上述相同，允许通过测试运行器运行测试用例。
• 将测试重置为活动：此选项允许将测试结果重置为活动，从而忽略测试点的最后一个结果。
• 打开/编辑测试用例工作项窗体：此选项允许你使用工作项窗体编辑测试用例，在其中编辑工作项字段，包括测试步骤。
• 分配测试人员：此选项允许将测试点分配给测试人员以执行测试。
• 查看测试结果：此选项允许查看最新的测试结果详细信息，包括每个测试步骤的结果、添加的注释或提交的 bug。
• 查看执行历史记录：此选项允许查看所选测试点的整个执行历史记录。 这会打开一个新页面，你可以在其中调整筛选器，以便不仅查看所选测试点的执行历史记录，还可以查看整个测试用例的执行历史记录。

Test Plans进度报告

此现成的报告有助于跟踪项目中一个或多个Test Plans的执行和状态。 访问Test Plans>进度报告*以开始使用报表。

报表的三个部分包括以下内容：

1. 摘要：显示所选测试计划的合并视图。
2. 结果趋势：呈现每日快照，以提供执行和状态趋势线。 它可以显示 14 天 (默认) 、30 天或自定义范围的数据。
3. 详细信息：本部分可向下钻取每个测试计划，并为每个测试套件提供重要的分析。

Artifacts

注意

Azure DevOps Server 2020 不会在数据导入期间导入回收站中的源。 如果要导入回收站中的源，请在开始数据导入之前从回收站还原它们。

许可证表达式和嵌入许可证

现在，在 Visual Studio 中浏览包时，可以看到存储在 Azure Artifacts 中的 NuGet 包的许可证信息的详细信息。 这适用于使用许可证表达式或嵌入许可证表示的许可证。 现在，可以在 Visual Studio 包详细信息页中看到指向许可证信息的链接， (下图中的红色箭头) 。

单击该链接会将你带到一个网页，你可以在其中查看许可证的详细信息。 此体验对于许可证表达式和嵌入式许可证都是相同的，因此可以在一个位置查看存储在 Azure Artifacts 中的包的许可证详细信息， (指定许可证信息并受 Visual Studio) 支持的包。

轻型身份验证任务

现在，可以使用轻型身份验证任务向 Azure Pipelines 中的常用包管理器进行身份验证。 这包括 NuGet、npm、PIP、Twine 和 Maven。 以前，可以使用提供大量功能（包括发布和下载包的功能）的任务向这些包管理器进行身份验证。 但是，这需要将这些任务用于与包管理器交互的所有活动。 如果运行自己的脚本来执行发布或下载包等任务，则无法在管道中使用它们。 现在，可以在管道 YAML 中使用自己设计的脚本，并使用这些新的轻型任务执行身份验证。 使用 npm 的示例：

在此图中，“ci”和“publish”命令的使用是任意的，可以使用 Azure Pipelines YAML 支持的任何命令。 这使你能够完全控制命令调用，并使你在管道配置中轻松使用共享脚本。 有关详细信息，请参阅 NuGet、 npm、 PIP、 Twine 和 Maven 身份验证任务文档。

对源页面加载时间的改进

我们很高兴地宣布，我们改进了源页面加载时间。 平均而言，源页面加载时间减少了 10%。 最大的源的改进最大，第 99 个百分位的源页面加载时间 (加载时间在所有源中最高 99%，) 减少了 75%。

使用公共源公开共享包

现在可以在公共源中创建和存储包。 存储在公共源中的包可供 Internet 上的每个人使用，而无需进行身份验证，无论它们是否在你的集合中，甚至是否登录到 Azure DevOps 集合。 在我们的 源文档中 了解有关公共源的详细信息，或直接跳转到公开 共享包的教程。

在 AAD 租户的不同集合中配置上游

现在可以在与 Azure Active Directory (AAD) 租户关联的另一个集合中添加源，作为项目源的上游源。 源可以从配置为上游源的源中查找和使用包，从而在与 AAD 租户关联的集合之间轻松共享包。 请参阅文档中的 此设置。

使用 Python 凭据提供程序通过 Azure Artifacts 源对 pip 和 twine 进行身份验证

现在可以安装并使用 Python 凭据提供程序 (artifacts-keyring) 来自动设置身份验证，以在 Azure Artifacts 源中发布或使用 Python 包。 使用凭据提供程序时，无需 (pip.ini/pip.conf/.pypirc) 设置任何配置文件，首次调用 pip 或 twine 时，只需在 Web 浏览器中通过身份验证流。 有关详细信息 ，请参阅文档。

Visual Studio 包管理器中的 Azure Artifacts 源

现在，在 Visual Studio NuGet 包管理器中显示从 Azure Artifacts 源提供的包的包图标、说明和作者。 以前，大部分元数据未提供给 VS。

更新了“连接到源”体验

“连接到源”对话框是使用 Azure Artifacts 的入口;它包含有关如何配置客户端和存储库以从 Azure DevOps 中的源推送和拉取包的信息。 我们更新了对话框以添加详细的设置信息，并扩展了我们为其提供说明的工具。

公共源现已正式发布，上游支持

公共源的公共预览版得到了很好的采用和反馈。 在此版本中，我们扩展了其他功能以正式发布。 现在，可以将公共源设置为专用源中的上游源。 可以通过能够上游专用源和项目范围的源来保持配置文件的简单性。

从门户Create项目范围的源

发布公共源时，我们还发布了 项目范围的源。 到目前为止，可以通过 REST API 或创建公共源，然后将项目转换为私有来创建项目范围的源。 现在，如果具有所需的权限，可以直接在门户中从任何项目创建项目范围的源。 还可以在源选取器中查看哪些源是项目，哪些源属于集合范围。

npm 性能改进

我们对核心设计进行了更改，以改进在 Azure Artifacts 源中存储和交付 npm 包的方式。 这帮助我们将 npm 的一些最高使用 API 的延迟降低了 10 倍。

辅助功能改进

我们已部署修补程序来解决源页面上的辅助功能问题。 修复程序包括：

• Create源体验
• 全局源设置体验
• 连接到源体验

Wiki

代码 Wiki 页面的丰富编辑

以前，在编辑代码 Wiki 页面时，你被重定向到 Azure Repos 中心进行编辑。 目前，存储库中心未针对 Markdown 编辑进行优化。

现在，可以在 wiki 内的并排编辑器中编辑代码 Wiki 页面。 这允许您使用 rich Markdown 工具栏创建内容，使编辑体验与 project wiki 中的编辑体验相同。 你仍可以通过选择上下文菜单中的“ 在存储库中编辑” 选项来选择在存储库中进行编辑。

从 Wiki 页面Create和嵌入工作项

当我们听取你的反馈时，我们听说你使用 Wiki 来捕获集思广益的文档、规划文档、功能想法、规范文档、会议纪要。 现在，你可以直接从规划文档轻松创建功能和用户情景，而无需离开 Wiki 页面。

若要创建工作项，请在 Wiki 页面中选择要在其中嵌入工作项的文本，然后选择“ 新建工作项”。 这可以节省时间，因为您不必先创建工作项，转到编辑，然后找到工作项以嵌入它。 它还会减少上下文切换，因为不会超出 Wiki 范围。

若要了解有关从 Wiki 创建和嵌入工作项的详细信息，请参阅 此处的文档。

Wiki 网页中的注释

以前，你没有办法与 Wiki 中的其他 Wiki 用户进行交互。 这使得协作处理内容和获取问题成为一项挑战，因为对话必须通过邮件或聊天渠道进行。 通过批注，你现在可以直接在 Wiki 中与他人协作。 可以利用注释中的 @mention 用户功能来吸引其他团队成员的注意。 此功能基于 此建议票证确定优先级。 有关评论的详细信息，请参阅 此处的文档。

隐藏以“.”开头的文件夹和文件 wiki 树中的

到目前为止，Wiki 树显示 wiki 树中以点 (.) 开头的所有文件夹和文件。 在代码 Wiki 方案中，这会导致诸如 .vscode 之类的文件夹显示在 Wiki 树中，这些文件夹将被隐藏。 现在，所有以点开头的文件和文件夹都将在 Wiki 树中保持隐藏状态，从而减少不必要的混乱。

此功能基于 此建议票证确定优先级。

简短且可读的 Wiki 页面 URL

您不再需要使用多行 URL 来共享 Wiki 网页链接。 我们正在利用 URL 中的页面 ID 来删除参数，从而使 URL 更短且更易于阅读。

URL 的新结构将如下所示：

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

下面是 欢迎使用 Azure DevOps Wiki 页的新 URL 的示例：

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

这是根据开发者社区中的此功能建议票证来确定优先级的。

用于编辑 Wiki 页面的同步滚动

现在，通过编辑窗格和预览窗格之间的同步滚动，可以更轻松地编辑 Wiki 页面。 在一侧滚动将自动滚动另一侧以映射相应的部分。 可以使用切换按钮禁用同步滚动。

注意

同步滚动切换的状态按用户和帐户保存。

Wiki 页面的页面访问数

现在可以深入了解 Wiki 页面的页面访问量。 REST API 允许访问过去 30 天内访问的页面信息。 可以使用此数据为 Wiki 页面创建报表。 此外，还可以将此数据存储在数据源中，并创建仪表板以获取特定见解，例如 排名靠前的 N 个页面。

你还将在每个页面中看到过去 30 天的总页面访问计数。

注意

页面访问定义为给定用户在 15 分钟的间隔内的页面视图。

报表

管道故障和持续时间报告

指标和见解可帮助你不断提高管道的吞吐量和稳定性。 我们添加了两个新报表，以提供有关管道的见解。

1. 管道故障报告显示生成通过率和失败趋势。 此外，它还会显示任务失败趋势，以提供有关管道中哪些任务导致最大失败数的见解。

2. 管道持续时间报表显示管道运行所花费的时间趋势。 它还显示管道中哪些任务花费的时间最多。

查询结果小组件改进

查询结果小组件是我们最常用的小组件之一，有充分的理由。 小组件直接在仪表板上显示查询结果，在许多情况下非常有用。

在此更新中，我们包含了许多期待已久的改进：

• 现在可以选择要在小组件中显示的任意数量的列。 不再有 5 列限制！
• 小组件 支持从 1x1 到 10x10 的所有大小。
• 调整列的大小时， 将保存列宽。
• 可以将 小组件展开到全屏视图。 展开后，它将显示查询返回的所有列。

潜在客户和周期时间小组件高级筛选

团队使用潜在客户和周期时间 来查看工作流经开发管道并最终为客户提供价值所需的时间。

直到现在， 潜在顾客和周期时间小组件 都不支持高级筛选条件来提出以下问题：“我的团队需要多长时间才能关闭优先级较高的项目？”

使用此更新时，可以通过筛选板泳道来回答此类问题。

我们还包含工作项筛选器，以限制图表中显示的工作项。

使用故事点的内联冲刺燃尽

你的冲刺燃烧现在可以被故事烧毁。 这解决了来自开发者社区的反馈。

从 Sprint 中心选择“分析”选项卡。然后配置报表，如下所示：

1. 选择故事积压工作
2. 选择可对故事点数的总和进行烧毁

包含你一直要求的所有内容的冲刺燃烧小组件

新的 Sprint Burndown 小组件支持按故事点数、任务计数或自定义字段求和进行向下燃烧。 甚至可以为功能或长篇故事创建冲刺进度。 小组件显示平均燃尽、完成百分比和范围增加。 可以配置团队，以便在同一仪表板上显示多个团队的冲刺进度。 通过显示所有这些出色的信息，我们允许你在仪表板上将其大小调整为 10x10。

若要试用，可以从小组件目录中添加它，或者编辑现有 Sprint Burndown 小组件的配置并选中“ 立即试用新版本 ”框。

注意

新小组件使用 Analytics。 我们保留了旧版 Sprint Burndown，以防你无权访问 Analytics。

内联冲刺燃尽缩略图

冲刺燃烧回来了！ 几次冲刺之前，我们从 Sprint Burndown 和 Taskboard 标头中删除了上下文冲刺燃尽。 根据你的反馈，我们改进了并重新引入了冲刺燃尽缩略图。

单击缩略图将立即显示较大版本的图表，并在“分析”选项卡下提供查看完整报表的选项。对完整报表所做的任何更改都将反映在标题中显示的图表中。 因此，现在可以根据故事、故事点或任务计数（而不仅仅是剩余的工时量）将其配置为燃尽。

在没有团队的情况下Create仪表板

现在可以创建仪表板，而无需将其与团队相关联。 创建仪表板时，请选择“项目仪表板”类型。

项目仪表板类似于团队仪表板，但它不与团队关联，你可以决定谁可以编辑/管理仪表板。 就像团队仪表板一样，它对项目中的每个人都可见。

所有需要团队上下文的 Azure DevOps 小组件都已更新，让你可以在其配置中选择团队。 可以将这些小组件添加到项目仪表板，并选择所需的特定团队。

注意

对于自定义或第三方小组件，项目仪表板会将默认团队的上下文传递给这些小组件。 如果你有依赖于团队上下文的自定义小组件，则应更新配置以允许你选择团队。

---

反馈

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

---

返回页首