Azure DevOps Server 2020 发行说明

开发人员社区 | 系统要求 | 许可条款 | DevOps 博客 | SHA-1 哈希

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

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

Azure DevOps Server 2020、Azure DevOps Server 2019 或 Team Foundation Server （TFS） 2015 或更高版本支持直接升级到 Azure DevOps Server。 如果 TFS 部署在 TFS 2010 或更早版本上，则需要在升级到 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 0.2 修补程序 6 发布日期：2023 年 11 月 14 日

我们发布了针对 Azure DevOps Server 2020 Update 0.2 的补丁，包含以下问题的修复。

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

安装补丁

配置 TFX

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

使用 TFX 更新任务

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 日

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

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

Azure DevOps Server 2020 Update 0.2 修补程序 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 代理文档中 概述的步骤部署代理。  

配置 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 修补程序 3 发布日期：2023 年 8 月 8 日

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

• 修复了从 2018 年或更早版本升级时干扰软件包推送的问题。

Azure DevOps Server 2020 Update 0.2 修补程序 2 发布日期：2023 年 6 月 13 日

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

• 修复了从 2018 年或更早版本升级时干扰软件包推送的问题。

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 是错误修复汇总包。 可以直接安装 Azure DevOps Server 2020.0.2 或从 Azure DevOps Server 2020 或 Team Foundation Server 2013 或更高版本升级。

此版本包括以下修复：

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

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

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

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

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

安装步骤

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

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 Patch 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 的连接。 通过此修补程序，项目管理员可以在 Azure DevOps Server 与 GitHub.com 上的存储库之间创建连接。 可以在“项目设置”下的“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.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 任务安装

Install

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 登录 命令时，将使用此个人访问令牌。

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 任务安装

Install

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 登录 命令时，将使用此个人访问令牌。

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 是一个累计更新，包含了错误修复。 可以直接安装 Azure DevOps Server 2020.0.1 或从现有安装升级。 支持升级的版本是 Azure DevOps Server 2020、Azure DevOps Server 2019 和 Team Foundation Server 2012 或更高版本。

此版本包含以下问题的修复：

• 解决 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 是错误修复的累积更新。 它包括以前发布的 Azure DevOps Server 2020 RC2 中的所有功能。

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

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

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

Azure DevOps Server 2020 RC2 是一个包含错误修复的版本汇总。 它包括以前发布的 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 日

Azure DevOps Server 2020 中的新增功能摘要

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

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

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

• 常规
• 板
• 存储库
• 管道
• 测试计划
• 文物
• 维基
• 报告

概况

Azure DevOps CLI 正式版

2 月，我们引入了用于 Azure CLI 的 Azure DevOps 扩展。 使用此扩展可从命令行与 Azure DevOps 交互。 我们已经收集了你的反馈，这些反馈有助于我们改进扩展并添加更多命令。 我们现在很高兴地宣布，此扩展已正式发布。

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

使用发布配置文件通过开发中心部署 Azure WebApps for Windows

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

Boards

向任务板和冲刺积压工作 (sprint backlog) 添加“父工作项”筛选器

我们在 Sprint 看板和待办事项中添加了一个新筛选器。 这样，你可以按父项筛选需求级别积压工作项（左侧第一列）。 例如，在下面的屏幕截图中，我们已筛选视图，仅显示父级为“我的大功能”的用户情景。

改进错误处理体验 - 关于 Bug/任务的必需字段

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

工作项实时重载

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

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

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

工作项父列作为列选项

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

更改项目使用的过程

应根据团队的变化改变工具，现在可将项目从任何现成的流程模板切换到任何其他现成的流程。 例如，可以将项目从使用 Agile 更改为 Scrum，或从 Basic 更改为 Agile。 可在此处找到完整的分步文档。

从布局中隐藏自定义字段

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

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

无法修复无法看到的内容。 因此，你希望密切关注其工作流程的状态和运行状况。 通过这些报表，我们让你能够更轻松地跟踪重要指标，只需在 Azure Boards 中做出最少的努力即可。

这三个新的交互式报告包括：燃尽图、累积流图 和 速度。 可以在“新建分析”选项卡中查看报表。

指标（例如冲刺进度削减图、工作流和团队速度）能够让你清晰地了解团队的进展，并帮助你解答以下问题：

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

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

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

  

• 可以通过单击相关卡片，从“看板”和“待办事项”下的“分析”选项卡访问CFD和速度报告。

  

使用新报表时，你拥有有关团队的更多控制和信息。 下面是一些示例：

• Sprint 燃尽图和速率报表可以设置为使用工作项计数或者剩余工作量的总和。
• 可以调整冲刺进度的时间范围，而不会影响项目日期。 因此，如果你的团队通常在每个迭代中花费第一天进行计划，你现在可以调整图表来反映这一点。
• “燃尽图”现在有一个水印显示周末。
• 通过CFD报表，团队可以删除像设计这样的看板列，以便更深入关注他们所能控制的流程。

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

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

自定义工作板列

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

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

此功能是根据开发人员社区 的建议 确定优先级的。

切换以在积压工作 (backlog) 上显示或隐藏完成的子工作项

很多时候，在优化积压工作时，你只想看到尚未完成的项目。 现在，你能够在待办事项中显示或隐藏已完成的子项。

如果切换开关打开时，您将看到所有子项处于已完成状态。 关闭切换时，处于已完成状态的所有子项都将隐藏在积压工作中。

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

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

针对组成员资格的只读和必填规则

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

自定西系统选择列表值

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

新工作项 URL 参数

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

与你共享链接的任何人都可以与你共享链接时使用你拥有的相同上下文登陆！

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

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

可在此处查看示例。

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

讨论评论的回应

我们的主要目标之一是使工作项对团队来说更具协作性。 最近 ，我们在 Twitter 上进行了一项民意调查 ，以了解你在讨论工作项时想要的协作功能。 评论中的反应在民意调查中获胜，所以我们添加了它们！ 以下是 Twitter 投票的结果。

你可以向任何批注添加反应，并且有两种方法来添加你的反应：在任何批注的右上角点击笑脸图标，或者在任何现有反应旁边的批注底部进行添加。 如果需要，可以添加所有六个反应，也可以只添加一两个反应。 若要删除你的反应，请单击批注底部的反应，该反应将被删除。 下面可以看到添加评论的反应体验，以及该反应在评论中的显示方式。

将 Azure Boards 报表固定到仪表板

在 Sprint 155 更新中，我们包括 更新版本的CFD和速度报告。 这些报告可在“看板”和“待办事项”选项卡下查看。 现在可以将报表直接固定到仪表板。 若要固定报表，请将鼠标悬停在报表上，选择省略号“...”菜单和 “复制到仪表板”。

使用“板”积压工作 (backlog) 上的“汇总”跟踪父项的进度

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

例如，此处显示了 “按工作项进度 ”，它根据已关闭的后代项的百分比显示升序工作项的进度条。 Epics 的子代项包括所有子功能及其子或大子工作项。 Features 的子代项包括所有子用户情景及其子工作项。

任务板实时更新

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

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

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

1. 在您的待办事项上点击“列选项”。 然后在面板中单击“添加汇总列”并 配置自定义汇总。

   

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

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

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

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

自定义工作项通知设置

随时了解与你或你的团队相关的工作项非常重要。 它帮助团队协作并保持项目进度，确保所有相关方都参与其中。 但是，不同的利益干系人对不同工作的投资水平不同，我们认为应该反映在你遵循工作项目状态的能力中。

以前，如果想要关注工作项并获取有关所做任何更改的通知，则会收到对工作项所做的任何和所有更改的电子邮件通知。 在考虑了你的反馈后，我们正在为所有利益相关者提供更灵活的工作项跟进方式。 现在，你将在工作项右上角的 “关注 ”按钮旁边看到一个新的设置按钮。 这会将你带到一个弹出窗口，以便配置以下选项。

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

将工作项链接到部署

我们非常高兴地在工作项表单中推出部署控制功能。 此控件将工作项链接到发布，使你能够轻松跟踪工作项的部署位置。 若要了解详细信息，请参阅 此处的文档。

从 CSV 文件导入工作项

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

将父字段添加到工作项卡片

在您的看板板面中，父级上下文现已作为工作项卡片的一个新字段提供。 现在可以将父字段添加到卡片，无需使用诸如标记和前缀等解决方法。

将父字段添加到积压工作 (backlog) 和查询中

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

Repos

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

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

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

从拉取请求筛选注释通知

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

用于拉取请求注释的服务挂钩

现在可以根据存储库和目标分支在拉取请求中创建评论的服务钩子。

用于阻止使用指定模式的文件的策略

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

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

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

自动审阅者的粒度

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

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

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

在拉取请求中以并行比较的形式预览 Markdown 文件

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

生成手动生成的策略有效期

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

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

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

此功能是根据 开发人员社区提供 类似体验的建议确定优先级的。 我们将继续让票证保持打开状态，并鼓励用户告诉我们你想要查看的其他类型的推送策略。

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

有时，您需要审阅涉及许多文件更改的拉取请求，很难跟踪哪些文件已经审阅过。 现在可以在拉取请求中将文件标记为已审阅。

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

此功能是根据 开发人员社区的建议确定优先级的。

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

现在，可以在 Azure Repos 中试用新的新式、快速和移动友好的登陆页面。 这些页面可用作 新的 Repos 登陆页面。 登陆页面包括除拉取请求详细信息、提交详细信息和分支比较之外的所有页面。

Web

手机

跨存储库分支策略管理

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

新的 Web 平台转换登陆页面

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

Web 体验：

移动体验：

支持 Kotlin 语言

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

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

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

改进了拉取请求可操作性

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

Pipelines

多阶段管道

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

新体验中包括以下功能：

• 查看和管理多个阶段
• 批准流水线运行
• 在管道仍在运行时从头滚动查看日志
• 管道的按分支运行状况。

YAML 中的持续部署

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

• 多阶段 YAML 管道（适用于 CI 和 CD）
• 审批和检查资源
• 环境和部署策略
• 环境中的 Kubernetes 和虚拟机资源
• 查看用于协作的应用
• 服务连接的用户体验进行了刷新
• 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 调度的错误。

针对服务连接用户界面的更新

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

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

此更新默认启用新的用户体验。 你仍可以选择退出预览。

在 YAML 管道中跳过阶段

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

更新的运行管道面板提供 YAML 文件中的阶段列表，可以选择跳过其中一个或多个阶段。 跳过阶段时必须谨慎。 例如，如果第一个阶段生成后续阶段所需的某些项目，则不应跳过第一个阶段。 每当跳过具有下游依赖项的阶段时，运行面板会显示一个泛型警告。 这些依赖项是否为真正的构建物依赖，或仅仅为了部署顺序而存在，留给你决定。

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

新的服务连接 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 - 在终止任务之前为“运行始终运行”提供多少时间
• 条件 - 有条件地运行作业
• 变量 - 可以直接添加硬编码值，也可以是 变量组，也可以引用 由 Azure 密钥保管库支持的变量组 ，也可以引用 文件中定义的一组变量。
• 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

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

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

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

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

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

文件夹允许对管道进行组织，以便其更易于发现以及实现安全控制。 通常，可能需要为所有发布管道（即文件夹下的所有管道）配置自定义电子邮件通知。 以前，需要配置多个订阅或在订阅中进行复杂的查询才能获得重点电子邮件。 通过此更新，现在可以将发布文件夹子句添加到 部署已完成 和 审批挂起 的事件，并简化订阅。

使用多阶段 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 管道中的容器结构测试支持

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

可以根据可以一起运行的四类测试来验证映像的结构：命令测试、文件存在测试、文件内容测试和元数据测试。 可以使用管道中的结果做出继续/终止决策。 管道运行中提供了测试数据，并显示一条错误消息，以帮助更好地排查故障。

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

测试数据和摘要

适用于发布管道的管道修饰器

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

我们一直在支持构建和 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...

Kubernetes 的 Canary 策略将首先部署更改到 10% 的 pods，随后增加到 20% 的 pods，同时监控 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>']]
• 对于 金丝雀策略： $[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

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

下面是在环境中使用 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...

对部署的更多控制

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

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

批准通知

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

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

从 Azure 门户配置部署策略

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

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

运行时参数

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

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

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

在管道中使用 extends 关键字

目前，管道可以抽象为模板，促进重复使用和减少样板代码。 管道的整体结构仍由根 YAML 文件定义。 通过此更新，我们添加了一种更结构化的方式来使用管道模板。 根 YAML 文件现在可以使用关键字 扩展 来指示可以在另一个文件中找到主管道结构。 这使你能够控制哪些段可以扩展或更改，以及哪些段是固定的。 我们还使用数据类型增强了管道参数，以明确可以提供的钩子。

此示例演示如何为管道作者提供简单的钩子。 该模板将始终执行构建，可选择运行由管道提供的额外步骤，然后执行可选的测试步骤。

# 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_未标记为的变量。

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 都会被签出。

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

我们已为管道中的 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

在 KubernetesManifest 任务中以烘焙任务的形式进行 Kubernetes 自定义和 Kubernetes 编写

kustomize （Kubernetes sig-cli 的一部分）使你可以自定义原始的无模板 YAML 文件以实现多种用途，并使原始 YAML 保持不变。 在 KubernetesManifest 任务 的烘焙操作中添加了 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 代理可以在管道中评估 Rego 策略文件和 Terraform 计划。

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

支持 Azure CLI 任务中的 PowerShell 脚本

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

KubernetesManifest 任务中基于服务对等网格接口的 canary 部署

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

服务网格接口抽象允许与 Linkerd 和 Istio 等服务网格提供程序进行即插即用配置。 现在，KubernetesManifest 任务在部署策略的生命周期中简化了将 SMI 的 TrafficSplit 对象映射到稳定服务、基线服务和金丝雀服务的过程。 在稳定、基线和 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 存储体或虚拟机（VM）。 该任务使用 AzCopy，这是为快速从和到 Azure 存储帐户传输数据而建立的命令行实用工具。 通过此更新，我们添加了对 AzCopy V10 的支持，它是 AzCopy 的最新版本。

该 azcopy copy 命令仅支持与其关联的 参数 。 由于 AzCopy 语法发生更改，AzCopy V10 中不提供一些现有功能。 这些包括：

• 指定日志位置
• 在复制后清理日志和计划文件
• 如果作业失败，重新开始复制

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

• 源文件名或路径中的通配符符号
• 如果未提供任何参数，则基于文件扩展名推断内容类型
• 通过传递参数定义日志文件的日志详细程度

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

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

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

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

  注释

  集合设置将覆盖项目设置。

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

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

  通过限制访问令牌的范围来改进管道安全性，Azure Pipelines 现在可以将存储库访问权限限定为仅 基于 YAML 的管道所需的存储库。 这意味着，如果管道的访问令牌泄露，它只能访问管道中使用的存储库。 以前，访问令牌适用于项目中的任何 Azure Repos 存储库，或者可能是整个集合。

  对于新项目和集合，此功能默认为打开。 对于现有集合，必须在“集合设置>>中启用它。 使用此功能时，生成所需的所有存储库（即使是使用脚本克隆的存储库）都必须包含在管道的 存储库资源 中。

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

  默认情况下，我们向访问令牌授予大量权限，其中一个权限是 队列生成。 更新后，我们删除了对访问令牌的此权限。 如果管道需要此权限，您可以根据所使用的令牌显式授予 项目构建服务帐户 或 项目集合构建服务帐户。

服务连接的项目级安全性

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

目标分步设定和命令隔离

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 变量标记为如下所示，使 YAML 变量只读。

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

针对服务连接的基于角色的访问权限

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

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

在此处了解有关服务连接安全性的详细信息。

服务连接的跨项目共享

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

在此处了解有关服务 连接共享的详细信息。

管道和 ACR 资源的可追溯性

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

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

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

  

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

  

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

• 可供运行使用的工件。

  

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

大型测试附件支持

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

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

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

显示有关每个作业的池信息

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

适用于新分支的 CI 触发器

有一个长期未决的请求，即在创建新分支且该分支没有更改时不触发 CI 构建。 请考虑以下示例：

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

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

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

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

输出变量仍由作业中的步骤生成。 dependencies.jobName.outputs['stepName.variableName']被称为stageDependencies.stageName.jobName.outputs['stepName.variableName']阶段。

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

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

代理诊断

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

YAML 管道的服务挂钩

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

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

优化集成

Optimizely 是面向产品团队的功能强大的 A/B 测试和功能标记平台。 将 Azure Pipelines 与 Optimizely 实验平台集成，使产品团队能够以更快的速度进行测试、学习和部署，同时从 Azure Pipelines 中获得所有 DevOps 权益。

适用于 Azure DevOps 的 Optimizely 扩展在生成和发布管道中添加了实验和功能标志推出步骤，因此你可以使用 Azure Pipelines 连续进行迭代、推出功能并将其回滚。

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

添加 GitHub 发布作为项目源

现在，你可以将 GitHub 版本链接为 Azure DevOps 发布管道中的项目源。 这将允许你在部署中使用 GitHub 版本。

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

与 Azure Pipelines 的 Terraform 集成

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 试验扩展 。

已更新与 Azure Pipelines 的 ServiceNow 集成

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

从 VSCode 创建 Azure Pipelines

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

管理和解决不靠谱 bug

我们采用了不稳定的测试管理，以支持具备检测、报告和解决功能的端到端生命周期。 为了进一步增强它，我们将添加异常测试 bug 管理和解决方法。

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

当 bug 报告解决或关闭时，我们会自动取消标记测试为不稳定。

如果未运行最低数量的测试，则将 VSTest 设置为失败

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

任务用户界面中提供了 VSTest TestResultsDirectory 选项

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

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

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

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

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

此外，部署作业可以作为 容器作业 运行，并附带 服务侧车（如果已定义）。

Test Plans

“新建测试计划”页

新的测试计划页 （测试计划 *） 适用于所有 Azure DevOps 集合。 新页面提供了简化的视图，可帮助你专注于手头的任务（测试规划、创作或执行）。 它也很简单，并且与其余的 Azure DevOps 产品/服务保持一致。

帮助我了解新页面

新的“测试计划”页共有 6 个部分，其中前 4 个是新的，而“图表和扩展性”部分是现有功能。

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

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

1. 测试计划标头

任务

测试计划标头允许你执行以下任务：

• 将测试计划标记为收藏
• 取消标记收藏的测试计划
• 轻松在喜欢的测试计划之间导航
• 查看测试计划的迭代路径，该路径清楚地指示测试计划是否为“当前”或“过去”
• 查看“测试进度”报表的快速摘要，其中包含导航到报表的链接
• 导航返回“所有/我的测试计划”页面

上下文菜单选项

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

• 复制测试计划：这是一个新选项，可用于快速复制当前测试计划。 下面提供了更多详细信息。
• 编辑测试计划：此选项允许编辑测试计划工作项窗体来管理工作项字段。
• 测试计划设置：此选项允许配置测试运行设置（用于关联生成或发布管道）和测试结果设置

复制测试计划（新功能）

建议为每个冲刺/版本创建新的测试计划。 执行此作时，通常可以复制上一个周期的测试计划，并且复制的测试计划几乎没有更改，即可在新周期中使用。 为了简化此过程，我们在新页面上启用了“复制测试计划”功能。 利用它，可以复制或克隆测试计划。 此处 介绍了其 支持 REST API，API 允许跨项目复制/克隆测试计划。
有关测试计划使用情况的更多指南，请参阅 此处。

2. 测试套件树

任务

测试套件标头允许你执行以下任务：

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

上下文菜单选项

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

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

3. 定义选项卡

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

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

任务

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

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

上下文菜单选项

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

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

复制/克隆测试用例（新功能）

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

查看链接项（新功能）

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

4. 执行选项卡

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

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

新页面的一个主要优点是，对于主要进行测试执行/跟踪（只需要“基本”访问级别）的用户来说，他们不会因为套件管理复杂性而感到不知所措（对于这些用户，定义选项卡是隐藏的）。

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

任务

“执行”选项卡允许你执行以下任务：

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

上下文菜单选项

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

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

测试计划进度报告

开箱即用报表帮助你跟踪项目中一个或多个测试计划的执行情况和状态。 访问测试计划 > 进度报告* 以开始使用报告。

报告的三个部分包括：

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

Artifacts

许可证表示形式和嵌入式许可证

现在，可以在 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 集合。 在 订阅流文档 中了解有关公共订阅流的详细信息，或直接跳转到我们的 公开共享软件包教程。

在 Azure Active Directory 租户内的不同集合中配置上游

现在，您可以将与 Azure Active Directory（AAD）租户相关联的另一个集合中的馈送添加为您的 Artifacts 馈送的上游源。 源可以从配置为上游源的源中查找和使用包，从而允许在与 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 中的源推送和拉取包的信息。 我们更新了对话框，以添加详细的设置信息，并扩展了我们提供相关说明的工具。

现已为公共源提供上游支持

公共源的公共预览版收到了很好的采用和反馈。 在此版本中，我们将一些附加功能扩展到普遍使用。 现在，可以将公共源设置为私有源的上游源。 通过能够将配置上传和下载到私有和项目范围的源，可以保持配置文件简单。

从门户创建项目范围的源

当我们发布公共源时，我们还发布了项目范围内的源。 到目前为止，可以通过 REST API 或创建一个公共订阅源，然后将项目设为私人项目来创建项目范围内的订阅源。 现在，如果拥有所需的权限，您可以直接在门户网站中从任何项目创建项目限定的信息源。 您还可以在源选取器中查看哪些源是项目范围的，哪些源是集合范围的。

npm 性能改进

我们对核心设计进行了更改，以改进我们在 Azure Artifacts 源中存储和交付 npm 包的方式。 这帮助我们将 npm 的一些最常使用的 API 的延迟减少至原来的十分之一。

辅助功能改进

我们已部署修补程序以解决订阅页面上的无障碍问题。 修复包括以下内容：

• 创建信息流体验
• 全局信息流设置体验
• 连接到信息流体验

维基

代码 Wiki 页丰富的编辑功能

以前，在编辑代码 Wiki 页面时，你会被重定向到 Azure Repos 中心以进行编辑。 当前，Repo 中心尚未针对 markdown 编辑进行优化。

现在，你可以在 Wiki 内的并排编辑器中编辑代码 Wiki 页面。 这样，便可以使用丰富的 Markdown 工具栏创建内容，使编辑体验与项目 wiki 中的内容相同。 你仍然可以选择在存储库中编辑，方法是 在上下文菜单中选择“在存储库 中编辑”选项。

从 Wiki 页创建和嵌入工作项

我们从你的反馈中了解到，你使用 Wiki 来捕获集思广益文档、计划文档、有关功能的想法、规格文档、会议时间。 现在，你可以直接从计划文档中轻松创建功能和用户案例，而无需离开 Wiki 页面。

若要创建工作项，请在 Wiki 页面中选择要嵌入工作项的文本，然后选择“ 新建工作项”。 这样做可以节省时间，因为你不必先创建工作项，再进行编辑，然后找到要嵌入的工作项。 而且由于你不会超出 Wiki 范围，因此还可以减少上下文切换。

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

wiki 页面中的注释

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

隐藏以“.”开头的文件夹和文件。 在维基树中

直到现在，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 页面访问量的统计数据。 REST API 允许您访问过去 30 天内的页面访问信息。 可以使用此数据为 Wiki 页面创建报表。 此外，可以将此数据存储在数据源中，并创建仪表板以获取特定见解，例如 最前 n 个查看的页面。

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

报告

管道失败和持续时间报告

指标和见解可帮助你不断提高管道的吞吐量和稳定性。 我们增加了两个新报告，为您提供有关管道的洞察。

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

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

对查询结果小组件的改进

查询结果小组件是我们最受欢迎的小组件之一，这是有原因的。 该组件直接在仪表板上呈现查询结果，在许多情况下非常有用。

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

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

提前期和周期时间小组件高级筛选

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

到目前为止， 潜在顾客和周期时间小组件 不支持高级筛选条件来提问，例如：“我的团队需要多长时间才能关闭更高的优先级项目？

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

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

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

你的冲刺燃烧现在可以被故事烧毁。 这是针对来自开发人员社区的反馈。

从Sprint中心选择“分析”标签页。然后如下配置您的报表：

1. 选择“故事积压工作”
2. 选择在 故事点的总和 上生成燃尽图

包含你所需的所有项的冲刺 (sprint) 燃尽小组件

新的 Sprint Burndown 小组件支持按故事点、任务数量或通过自定义字段求和来减少工作量。 甚至可以为功能或史诗创建冲刺进度。 该小组件显示平均燃尽、完成百分比和范围扩展量。 您可以配置团队，从而能够在同一仪表板上显示多个团队的冲刺进度。 我们允许您在仪表板上将这些出色的信息调整为最多10x10的尺寸。

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

内联的冲刺(sprint)燃尽缩略图

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

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

创建无团队的仪表板

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

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

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

反馈

我们期待您的反馈！ 你可以报告问题或提供想法，并通过 开发人员社区 跟踪它，并获取 有关 Stack Overflow 的建议。