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 根据管道级保留策略以不同的方式处理生成保留。 某些策略配置会导致升级后删除管道运行。 升级后，不会删除已手动保留或由发布保留的管道运行。
阅读我们的博客帖子，详细了解如何从 2019 Azure DevOps Server 安全地升级到 2020 Azure DevOps Server。
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 工作项中的控件时，不会发送电子邮件通知。
- 修复切换帐户时出现 TF400813 错误。 从 TFS 2018 升级到 2020.0.1 Azure DevOps Server时发生此错误。
- 修复了Project“概述摘要”页无法加载的问题。
- Active Directory 用户同步的改进。
- 通过从 log4j 二进制文件中删除 jndilookup 类来解决 Elasticsearch 漏洞。
安装步骤
- 使用 Patch 9 升级服务器。
- 检查
HKLM:\Software\Elasticsearch\Version的注册表值。 如果注册表值不存在，请添加一个字符串值，并将版本设置为 5.4.1 (Name = Version, Value = 5.4.1)。 - 按照自述文件中的说明运行 update 命令
PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update。 它可能会返回类似于下面的警告：无法连接到远程服务器。 请勿关闭窗口，因为更新正在执行重试，直到完成。
注意
如果Azure DevOps Server和 Elasticsearch 安装在不同的计算机上，请按照下面概述的步骤进行操作。
- 使用 Patch 9 升级服务器。
- 检查
HKLM:\Software\Elasticsearch\Version的注册表值。 如果注册表值不存在，请添加一个字符串值，并将版本设置为 5.4.1 (Name = Version, Value = 5.4.1)。 - 将名为 zip
C:\Program Files\{TFS Version Folder}\Search\zip的文件夹的内容复制到 Elasticsearch 远程文件文件夹中。 - 在 Elasticsearch 服务器计算机上运行
Configure-TFSSearch.ps1 -Operation update。
SHA-256 哈希： B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDDD881545E
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 和存储库之间创建连接。 可以在Project 设置下的“GitHub连接”页中找到此设置。
- 解决测试计划小组件的问题。 测试执行报告显示结果上的用户不正确。
- 修复了Project“概述摘要”页无法加载的问题。
- 修复了未发送电子邮件以确认产品升级的问题。
Azure DevOps Server 2020.0.1 修补程序 6 发布日期：2021 年 9 月 14 日
Azure DevOps Server 2020.0.1 的修补程序 6 包括以下修补程序。
- 修复Artifacts下载/上传失败。
- 解决测试结果数据不一致的问题。
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 日
注意
如果你有 2020 Azure DevOps Server，则应首先更新到 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 计算机上执行
安装
将 AzureResourceGroupDeploymentV2.zip 包提取到计算机上的新文件夹。 例如： D：\tasks\AzureResourceGroupDeploymentV2。
根据计算机的要求下载并安装 Node.js 14.15.1 和 npm（包含在 Node.js 下载项中）。
在管理员模式下打开命令提示符，并运行以下命令以安装 tfx-cli。
npm install -g tfx-cli
创建具有完全访问特权的个人访问令牌并复制它。 运行 tfx login 命令时将使用此个人访问令牌。
从命令提示符下运行以下命令。 出现提示时，输入服务 URL 和个人访问令牌。
~$ tfx login
Copyright Microsoft Corporation
> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully
- 运行以下命令，将任务上传到服务器。 使用从步骤 1 中提取的 .zip 文件的路径。
~$ tfx build tasks upload --task-path *<Path of the extracted package>*
AzureResourceManagerTemplateDeploymentV3 任务安装
注意
下面提及的所有步骤都需要在 Windows 计算机上执行
安装
将 AzureResourceManagerTemplateDeploymentV3.zip 包提取到计算机上的新文件夹。 例如：D：\tasks\AzureResourceManagerTemplateDeploymentV3。
下载并安装 Node.js 14.15.1，npm (随计算机下载Node.js一起下载) 。
在管理员模式下打开命令提示符，并运行以下命令以安装 tfx-cli。
npm install -g tfx-cli
创建具有完全访问特权的个人访问令牌并复制它。 运行 tfx login 命令时将使用此个人访问令牌。
从命令提示符下运行以下命令。 出现提示时，输入服务 URL 和个人访问令牌。
~$ tfx login
Copyright Microsoft Corporation
> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully
- 运行以下命令，将任务上传到服务器。 使用从步骤 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。 可以通过查找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 Server 上运行修复。 修复完成后，可以重启计算机/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 日
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 的详细信息，请参阅此处的文档。
使用发布配置文件从部署中心部署用于Windows的 Azure WebApps
现在，可以使用基于配置文件的发布身份验证从部署中心部署 Azure WebApps 以Windows。 如果有权使用其发布配置文件部署到 Azure WebApp for Windows，则可以在部署中心工作流中使用此配置文件设置管道。
Boards
将“父工作项”筛选器添加到任务板和冲刺积压工作
我们向 Sprint 板和 Sprint 积压工作添加了一个新筛选器。 这使你可以按父级筛选) 左侧的第一列 (要求级别积压工作项。 例如，在下面的屏幕截图中，我们已筛选视图，仅显示父级为“我的大功能”的用户情景。
改进错误处理体验 – Bug/Task 上的必填字段
从历史上看板开始，如果将工作项从一列移动到另一列，而状态更改触发字段规则的位置，卡将只显示红色错误消息，这会强制打开工作项以了解根本原因。 在冲刺 170 中，我们改进了体验，因此现在可以单击红色错误消息查看错误的详细信息，而无需打开工作项本身。
工作项实时重新加载
以前，更新工作项时，第二个团队成员正在对同一个工作项进行更改，第二个用户将丢失其更改。 现在，只要同时编辑不同的字段，就会看到对工作项所做的更改的实时更新。
从命令行管理迭代和区域路径
现在，可以使用命令az boards area从命令行az boards iteration管理迭代和区域路径。 例如，可以从 CLI 以交互方式设置和管理迭代和区域路径，或使用脚本自动执行整个设置。 有关命令和语法的更多详细信息，请参阅 此处的文档。
工作项父列作为列选项
现在，可以选择查看产品积压工作或冲刺积压工作项的父级。 若要启用此功能，请转到所需积压工作上的 列选项 ，然后添加 父 列。
更改项目使用的过程
工具应随团队一样更改，现在可以将项目从任何现成的进程模板切换到任何其他现成进程。 例如，可以将项目从使用敏捷更改为 Scrum，也可以将“基本”更改为“敏捷”。 可 在此处找到完整的分步文档。
隐藏布局中的自定义字段
现在可以在自定义流程时隐藏表单布局中的自定义字段。 该字段仍可从查询和 REST API 获取。 当你与其他系统集成时，这会方便跟踪额外的字段。
使用三个新的Azure Boards报告深入了解团队的运行状况
无法修复看不到的内容。 因此，你希望密切关注其工作流程的状态和运行状况。 通过这些报表，我们让你更轻松地跟踪重要指标，同时尽量减少Azure Boards工作量。
这三个新的交互式报告包括：烧毁、累积Flow关系图 () 和速度。 可以在“新分析”选项卡中查看报表。
冲刺烧毁、工作流和团队速度等指标可让你了解团队进度并帮助回答以下问题：
- 我们在这个短跑中留下多少工作？ 我们是否有望完成它？
- 开发过程需要花费的时间最长？ 我们能做点什么吗？
- 根据以前的迭代，我们应该为下一个冲刺计划多少工作？
注意
前面显示在标题中的图表已替换为这些增强型报表。
新报表是完全交互式的，可根据需要对其进行调整。 可以在每个中心的 “分析”选项卡 下找到新报表。
可以在 冲刺 中心下找到烧毁图表。
可以通过单击相关卡，从Boards和积压工作下的“分析”选项卡访问CFD和速度报告。
有了新报表，你拥有有关团队的更多控制和信息。 下面是一些示例：
- 冲刺烧毁和速度报表可以设置为使用工时项计数或剩余工时的总和。
- 你可以调整冲刺烧毁的时间范围，而不会影响项目日期。 因此，如果你的团队通常花费每个冲刺计划的第一天，现在可以匹配图表来反映这一点。
- 燃烧图现在有一个水印显示周末。
- 通过CFD报表，可以删除设计等板列，以便更专注于团队控制流。
下面是一个显示过去 30 天“故事积压工作”流程的FDA报表示例。
现在可以跟踪所有积压工作级别的速度图表。 例如，现在可以同时添加功能和 Epics，而在上一个图表仅支持“要求”之前。 下面是功能积压工作的最后 6 次迭代的速度报告示例。
自定义任务板列
我们很高兴地宣布，我们添加了一个选项，用于自定义 Taskboard 上的列。 现在可以添加、删除、重命名和重新排序列。
若要配置任务板上的列，请转到“列选项”。
此功能是根据开发者社区的建议确定优先级的。
切换以在积压工作中显示或隐藏已完成的子工作项
很多时候，在优化积压工作时，你只想看到尚未完成的项目。 现在，你能够在积压工作上显示或隐藏已完成的子项。
如果切换处于打开状态，你将看到所有处于已完成状态的子项。 切换关闭后，所有处于已完成状态的子项都将从积压工作中隐藏。
标记工作项时显示的最新标记
标记工作项时，自动完成选项现在最多会显示最近使用的标记中的五个。 这样，即可更轻松地将正确的信息添加到工作项。
组成员身份的只读和必需规则
使用工作项规则可以设置工作项字段的特定操作，以自动执行其行为。 可以创建规则，以根据组成员身份将字段设置为只读或必需。 例如，你可能希望向产品所有者授予设置功能优先级的能力，同时让其他人只读。
自定义系统选取列表值
现在可以自定义除原因字段) （例如严重性、活动、优先级等）之外的任何系统选取列表的值 (。选取列表自定义的范围是这样，以便你可以为每个工作项类型管理同一字段的不同值。
新建工作项 URL 参数
使用新的工作项 URL 参数共享指向工作项上下文或积压工作项的链接。 现在，可以通过将参数 ?workitem=[ID] 追加到 URL，在开发板、积压工作或冲刺体验上打开工作项对话框。
与你共享链接的任何人都可以在共享链接时使用你拥有的相同上下文登录！
在文本字段中提及人员、工作项和 PR
当我们听取你的反馈时，我们听到你希望能够在工作项说明区域中提及人员、工作项和 PR， (和其他 HTML 字段) 工作项，而不仅仅是在批注中提及。 有时你正在与某人协作处理工作项，或者想要在工作项说明中突出显示 PR，但没有办法添加该信息。 现在可以在工作项的所有长文本字段中提及人员、工作项和 PR。
可在此处查看示例。
- 若要使用人员提及，请键入 @ 要提及的符号和人员的姓名。 @mentions 在工作项字段中，将生成电子邮件通知，如对批注执行的操作。
- 若要使用工作项提及，请键入 # 后跟工作项 ID 或标题的符号。 #mentions将在两个工作项之间创建链接。
- 若要使用 PR 提及，请添加 一个 ！ ，后跟 PR ID 或名称。
讨论评论的反应
我们的主要目标是使工作项更加协作的团队。 最近 ，我们在 Twitter 上进行了一次民意调查 ，以了解在讨论工作项时所需的协作功能。 给评论带来反应赢得了民调， 所以我们加了他们！ 以下是推特民意测验的结果。
你可以向任何批注添加反应，并且有两种方法可以添加你的反应 - 任何批注右上角的笑脸图标，以及任何现有反应旁边的批注底部。 如果需要，可以添加所有六个反应，也可以只添加一两个反应。 若要删除你的反应，请单击批注底部的反应，并将其删除。 下面可以看到添加反应的体验，以及注释上的反应的外观。
将Azure Boards报表固定到仪表板
在冲刺 155 更新中，我们包含了 最新版的CFD和速度报告。 这些报告在Boards和积压工作的分析选项卡下提供。 现在可以将报表直接固定到仪表板。 若要固定报表，请将鼠标悬停在报表上，选择省略号“...”菜单和 “复制到仪表板”。
使用 Boards积压工作汇总跟踪父项的进度
汇总列显示层次结构中数值字段或后代项的进度栏和/或总计。 子代项对应于层次结构中的所有子项。 可以将一个或多个汇总列添加到产品或项目组合积压工作。
例如，此处显示了 “按工作项的进度 ”，它根据已关闭的后代项的百分比显示升序工作项的进度条。 Epics 的后代项包括所有子特征及其子或大子工作项。 Features 的后代项包括所有子用户故事及其子工作项。
任务板实时更新
任务板现在会在发生更改时自动刷新！ 当其他团队成员移动或重新排序任务板上的卡片时，你的板将自动更新这些更改。 你不再需要按 F5 来查看最新更改。
支持汇总列中的自定义字段
现在可以在任何字段（包括自定义字段）上完成汇总。 添加汇总列时，仍可以从“快速”列表中选择汇总列，但是，如果要对不属于现成进程模板的数值字段进行汇总，可以按如下所示配置自己的列：
- 在积压工作上，单击“列选项”。 然后在面板中单击“添加汇总列”并 配置自定义汇总。
- 在 进度栏 和 总计之间进行选取。
- 选择工作项类型或积压工作级别 (通常积压工作项聚合多个工作项类型) 。
- 选择聚合类型。 工作项计数 或 总和。 对于 Sum，需要选择要汇总的字段。
- “ 确定 ”按钮将返回到列选项面板，你可以在其中重新排序新的自定义列。
请注意，单击“确定”后，无法编辑自定义列。 如果需要进行更改，请删除自定义列并根据需要添加另一列。
基于条件隐藏工作项窗体中的字段的新规则
我们已将新规则添加到继承的规则引擎，以允许隐藏工作项窗体中的字段。 此规则将根据用户组成员身份隐藏字段。 例如，如果用户属于“产品所有者”组，则可以隐藏开发人员特定字段。 有关详细信息，请参阅 此处的文档。
自定义工作项通知设置
随时了解与你或你的团队相关的工作项非常重要。 它可帮助团队协作并跟踪项目，并确保所有相关方都参与其中。 但是，不同的利益干系人对不同工作的投资水平不同，我们认为应该反映在你遵循工作项目状态的能力中。
以前，如果想要关注工作项并获取有关所做的任何更改的通知，则会收到对工作项所做的任何和所有更改的电子邮件通知。 考虑你的反馈后，我们正在为所有利益干系人提供更灵活的工作项。 现在，你将在工作项右上角的 “关注 ”按钮旁边看到一个新的设置按钮。 这会将你带到一个弹出窗口，以便配置以下选项。
从通知设置，可以从三个通知选项中进行选择。 首先，可以完全取消订阅。 其次，可以完全订阅，可在其中获取所有工作项更改的通知。 最后，可以选择获取一些顶级和关键工作项更改事件的通知。 只能选择一个选项或全部三个选项。 这样，团队成员就可以更高级别地关注工作项，并且不会因为每次做出的更改而分心。 借助此功能，我们将消除不必要的电子邮件，并让你专注于手头的关键任务。
将工作项链接到部署
我们很高兴在工作项窗体上发布部署控制。 此控件将工作项链接到发布，使你能够轻松跟踪已部署工作项的位置。 若要了解详细信息，请参阅 此处的文档。
从 CSV 文件导入工作项
到目前为止，从 CSV 文件导入工作项依赖于使用 Excel 插件。 在此更新中，我们将直接从Azure Boards提供一流的导入体验，以便导入新的或更新现有工作项。 若要了解详细信息，请参阅 此处的文档。
将父字段添加到工作项卡片
在看板中，父上下文现已作为工作项卡的新字段提供。 现在可以将父字段添加到卡片，而无需使用标记和前缀等解决方法。
将父字段添加到积压工作和查询
查看积压工作和查询结果时，父字段现已可用。 若要添加父字段，请使用 “列”选项 视图。
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 Project 设置中找到“添加分支保护”功能。
新的 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 编辑器中管理管道变量
我们更新了在 YAML 编辑器中管理管道变量的体验。 不再需要转到经典编辑器，才能在 YAML 管道中添加或更新变量。
直接从发布中心批准发布
在等待批准时采取行动变得更加容易。 以前，可以从发布的详细信息页批准发布。 现在可以直接从发布中心批准发布。
Bitbucket 集成和其他改进，以开始使用管道
Pipelines的入门向导体验已更新为使用 Bitbucket 存储库。 Azure Pipelines现在将分析 Bitbucket 存储库的内容，并建议使用 YAML 模板进行访问。
开始使用向导的一个常见要求是能够重命名生成的文件。 目前，它作为存储库的根目录签入 azure-pipelines.yml 。 现在，可以在保存管道之前将此更新为其他文件名或位置。
最后，在将文件签入 azure-pipelines.yml 到其他分支时，我们将有更多的控制权，因为可以选择跳过从该分支创建拉取请求。
预览完全分析的 YAML 文档，而无需提交或运行管道
我们添加了 预览版，但不 为 YAML 管道运行模式。 现在，你可以尝试 YAML 管道，而无需将其提交到存储库或运行它。 给定现有管道和可选的新 YAML 有效负载，此新 API 将返回完整的 YAML 管道。 在将来的更新中，此 API 将在新的编辑器功能中使用。
对于开发人员：使用如下所示的 JSON 正文的 dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview POST：
{
"PreviewRun": true,
"YamlOverride": "
# your new YAML here, optionally
"
}
响应将包含呈现的 YAML。
YAML 中的 Cron 计划
以前，可以使用 UI 编辑器为 YAML 管道指定计划触发器。 通过此版本，可以在 YAML 文件中使用 cron 语法计划生成，并利用以下优势：
- 配置代码：可以将计划与管道一起作为代码的一部分进行跟踪。
- 表现力：定义计划比使用 UI 更具有表现力。 例如，可以更轻松地指定一个每小时开始运行的计划。
- 行业标准：许多开发人员和管理员已经熟悉 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 管道中使用服务连接至关重要：管道授权和审批和检查。
默认情况下，此更新会 打开 新的用户体验。 你仍可以选择退出预览。
注意
我们计划将 跨项目共享服务连接 作为新功能引入。 可以 在此处找到有关共享体验和安全角色的更多详细信息。
跳过 YAML 管道中的阶段
启动手动运行时，有时可能需要跳过管道中的几个阶段。 例如，如果不想部署到生产环境，或者想要跳过部署到生产环境中的几个环境。 现在可以使用 YAML 管道执行此操作。
更新的运行管道面板提供 YAML 文件中的阶段列表，可以选择跳过其中一个或多个阶段。 跳过阶段时必须谨慎。 例如，如果第一个阶段生成后续阶段所需的某些项目，则不应跳过第一阶段。 每当跳过具有下游依赖项的阶段时，运行面板会显示泛型警告。 对于这些依赖项是真正的项目依赖项，还是它们只是为了对部署进行排序而存在，则留给你。
跳过阶段等效于重新重排阶段之间的依赖关系。 跳过阶段的任何直接下游依赖项都取决于跳过阶段的上游父级。 如果运行失败，并且尝试重新运行失败阶段，该尝试也将具有相同的跳过行为。 若要更改跳过的阶段，必须启动新的运行。
服务连接新 UI 作为默认体验
有一个新的服务连接 UI。 此新 UI 基于现代设计标准构建，它附带了各种关键功能来支持多阶段 YAML CD 管道，例如审批、授权和跨项目共享。
在此处了解有关服务连接的详细信息。
“创建运行”对话框中的管道资源版本选取器
我们添加了在“创建运行”对话中手动选取管道资源版本的功能。 如果在另一个管道中使用 管道作为资源 ，现在可以在创建运行时选取该管道的版本。
azAzure 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包
我们最近引入了一个名为包的新资源类型，该类型增加了对使用 YAML 管道中GitHub NuGet和npm包的支持。 作为此资源的一部分，现在可以指定要从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 服务群集中的命名空间的环境。
通知订阅中的发布文件夹筛选器
文件夹允许组织管道，以便更轻松地发现和安全控制。 通常，你可能希望为所有发布管道配置自定义电子邮件通知，这些通知由文件夹下的所有管道表示。 以前，必须配置多个订阅，或在订阅中具有复杂的查询来获取重点电子邮件。 通过此更新，现在可以将发布文件夹子句添加到 部署已完成 和 审批挂起 的事件，并简化订阅。
使用多阶段 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现在为容器结构测试带来了支持。 此框架提供了一种方便且强大的方法来验证容器的内容和结构。
可以根据可以一起运行的四类测试来验证映像的结构：命令测试、文件存在测试、文件内容测试和元数据测试。 可以使用管道中的结果做出选择/不执行决策。 管道运行中提供了测试数据，并显示错误消息，以帮助你更好地排查故障问题。
输入配置文件和映像详细信息
测试数据和摘要
发布管道的管道修饰器
管道修饰器允许将步骤添加到每个作业的开头和结尾。 这不同于将步骤添加到单个定义，因为它适用于集合中的所有管道。
我们一直在支持生成和 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 模板部署，则可能会导致部署失败。 现在，我们添加了服务连接的筛选，以根据所选部署范围筛选出范围较低的服务连接。
Environment 中的 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: MasterNamespace
从管道收集自动和用户指定的元数据
现在，可以从管道任务启用自动和用户指定的元数据集合。 可以使用元数据通过 评估项目检查在环境中强制实施项目策略。
使用环境的 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 门户配置部署策略
借助此功能，我们让你能够更轻松地配置管道，这些管道使用所选的部署策略，例如 滚动、 Canary 或 Blue-Green。 使用这些现用策略，可以安全地推出更新并缓解相关的部署风险。 若要访问此项，请单击 Azure 虚拟机中的“持续交付”设置。 在配置窗格中，系统将提示你选择有关将在其中创建管道的Azure DevOps项目的详细信息、部署组、生成发布要部署的包的管道以及所选的部署策略。 接下来，将配置将所选包部署到此虚拟机的全功能管道。
有关更多详细信息，请查看有关 配置部署策略的文档。
运行时参数
运行时参数使你可以更好地控制哪些值可以传递给管道。 与变量不同，运行时参数具有数据类型，并且不会自动成为环境变量。 使用运行时参数，可以：
- 在运行时为脚本和任务提供不同的值
- 控制参数类型、允许的范围和默认值
- 使用模板表达式动态选择作业和阶段
若要了解有关运行时参数的详细信息，请参阅 此处的文档。
在管道中使用扩展关键字
目前，管道可以分解为模板，促进重用和减少样板。 管道的整体结构仍由根 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_未标记为的变量。
注意
默认情况下，此设置在现有集合中处于关闭状态，但在创建新Azure DevOps集合时，此设置默认处于打开状态。
YAML 管道中的新预定义变量
变量提供了一种将关键位数据获取到管道的各个部分的便捷方法。 通过此更新，我们已将几个预定义变量添加到部署作业。 这些变量由系统自动设置，范围限定为特定的部署作业，并且是只读的。
- Environment.Id - 环境的 ID。
- Environment.Name - 部署作业针对的环境的名称。
- Environment.ResourceId - 部署作业目标环境中的资源的 ID。
- Environment.ResourceName - 部署作业针对的环境中的资源的名称。
签出多个存储库
Pipelines通常依赖于多个存储库。 可以使用生成代码所需的源、工具、脚本或其他项使用不同的存储库。 以前，必须将这些存储库添加为子模块或手动脚本来运行 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、GitHub 和 Bitbucket 云存储库。 有关详细信息，请参阅 多存储库签出。
在运行时获取有关多个存储库的详细信息
管道运行时，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 任务的 烘焙操作下添加了 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 代理可以在管道中评估 Rego 策略文件和 Terraform 计划。
task: OpenPolicyAgentInstaller@0
inputs:
opaVersion: '0.13.5'
支持 Azure CLI 任务中的 PowerShell 脚本
以前，可以将批处理脚本和 bash 脚本作为 Azure CLI 任务的一部分执行。 通过此更新，我们向任务添加了对 PowerShell 和 PowerShell 核心脚本的支持。
KubernetesManifest 任务中基于接口的服务Mesh Canary 部署
以前，当 Canary 策略在 KubernetesManifest 任务中指定时，该任务将创建基线和 Canary 工作负荷，其副本等于用于稳定工作负荷的副本的百分比。 这与将流量拆分为请求级别的所需百分比不同。 为了解决此问题，我们已向 KubernetesManifest 任务添加了对基于接口的服务Mesh接口部署的支持。
服务Mesh接口抽象允许使用 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 存储帐户复制到 Azure 存储帐户中。 通过此更新，我们添加了对 AzCopy V10 的支持，这是 最新版本的 AzCopy。
该 azcopy copy 命令仅支持与之关联的 参数 。 由于 AzCopy 语法的变化，AzCopy V10 中不提供某些现有功能。 其中包括：
- 指定日志位置
- 在复制后清理日志和计划文件
- 如果作业失败，请恢复复制
此版本的任务支持的其他功能包括：
- 源文件名/路径中的通配符
- 在没有提供参数时基于文件扩展名推断内容类型
- 通过传递参数来定义日志文件的日志详细程度
通过限制访问令牌的范围来提高管道安全性
Azure Pipelines中运行的每个作业都会获取访问令牌。 访问令牌由任务和脚本用来调用回Azure DevOps。 例如，我们使用访问令牌来获取源代码、上传日志、测试结果、项目或对 Azure DevOps 进行 REST 调用。 为每个作业生成新的访问令牌，并在作业完成后过期。 通过此更新，我们添加了以下增强功能。
阻止令牌访问团队项目外部的资源
到目前为止，所有管道的默认范围都是团队项目集合。 可以将范围更改为经典生成管道中的团队项目。 但是，对于经典发布或 YAML 管道，你没有该控制。 通过此更新，我们将引入一个集合设置，以强制每个作业获取项目范围的令牌，无论管道中配置了什么。 我们还在项目级别添加了设置。 现在，你创建的每个新项目和集合将自动启用此设置。
注意
集合设置将替代项目设置。
如果管道使用访问令牌访问团队项目外部的资源，请在现有项目和集合中打开此设置可能会导致某些管道失败。 若要缓解管道故障，可以显式授予对所需资源的生成服务帐户访问权限Project。 强烈建议你启用这些安全设置。
限制生成服务存储库范围访问
通过限制访问令牌的范围来改进管道安全性，Azure Pipelines现在可以将其存储库访问权限限定为仅基于 YAML 的管道所需的存储库。 这意味着，如果管道的访问令牌泄露，它只能看到存储库 (管道中使用的) 。 以前，访问令牌适用于项目中的任何Azure Repos存储库，或者可能是整个集合。
对于新项目和集合，此功能默认为打开状态。 对于现有集合，必须在集合设置>Pipelines>设置中启用它。 使用此功能时，生成所需的所有存储库 (即使使用脚本克隆的存储库) 也必须包含在管道的 存储库资源 中。
删除访问令牌的某些权限
默认情况下，我们向访问令牌授予大量权限，其中一个权限是 队列生成。 通过此更新，我们删除了对访问令牌的此权限。 如果管道需要此权限，则可以根据所使用的令牌显式授予Project生成服务帐户或Project集合生成服务帐户。
服务连接的Project级别安全性
我们为服务连接添加了中心级安全性。 现在，可以添加/删除用户、分配角色和管理所有服务连接的集中位置的访问权限。
单步定位和命令隔离
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组（例如终结点管理员和 Endpoint Creators）管理服务连接安全性。
作为这项工作的一部分，我们引入了读者、用户、创意者和管理员的新角色。 可以通过项目中的服务连接页设置这些角色，这些角色由各个连接继承。 在每个服务连接中，可以选择打开或关闭继承并覆盖服务连接范围内的角色。
在此处了解有关服务连接安全性的详细信息。
服务连接的跨项目共享
我们启用了跨项目服务连接共享的支持。 现在可以安全地安全地与项目共享服务连接。
在此处了解有关服务 连接共享的详细信息。
管道和 ACR 资源的可跟踪性
当管道和 ACR 容器资源在管道中使用时，我们确保完整的 E2E 可跟踪性。 对于 YAML 管道使用的每个资源，可以追溯到提交、工作项和项目。
在管道运行摘要视图中，可以看到：
触发运行的资源版本。 现在，可以在完成另一个 Azure 管道运行或将容器映像推送到 ACR 时触发管道。
管道使用的 提交 。 还可以找到管道消耗的每个资源的提交明细。
与管道使用的每个资源关联的 工作项 。
可供运行使用 的项目 。
在环境的部署视图中，可以看到部署到环境的每个资源的提交和工作项。
支持大型测试附件
Azure Pipelines中的发布测试结果任务允许你在执行测试时发布测试结果，以提供全面的测试报告和分析体验。 到目前为止，测试运行和测试结果的测试附件限制为 100MB。 这限制了大型文件的上传，例如故障转储或视频。 通过此更新，我们添加了对大型测试附件的支持，使你能够使用所有数据来排查测试失败的问题。
你可能会在日志中看到 VSTest 任务或发布测试结果任务返回 403 或 407 错误。 如果在防火墙后面使用自承载生成或发布代理来筛选出站请求，则需要进行一些配置更改才能使用此功能。
为了解决此问题，我们建议更新防火墙以发出出站请求https://*.vstmrblob.vsassets.io。 可以在 此处的文档中找到故障排除信息。
注意
仅当使用自承载Azure Pipelines代理，并且位于正在筛选出站流量的防火墙后面时，才需要这样做。 如果在云中使用 Microsoft 托管的代理或未筛选出站网络流量，则无需执行任何操作。
显示每个作业的正确池信息
以前，当你使用矩阵来扩展作业或变量来标识池时，我们有时会在日志页中解析不正确的池信息。 这些问题已得到解决。
新分支的 CI 触发器
创建新分支且该分支没有更改时，这是一个长时间挂起的请求，无法触发 CI 生成。 请开考虑以下示例：
- 使用 Web 界面基于现有分支创建新分支。 如果分支筛选器与新分支的名称匹配，这会立即触发新的 CI 生成。 这是不需要的，因为与现有分支相比，新分支的内容是相同的。
- 你有一个包含两个文件夹的存储库 - 应用和文档。为 CI 设置与“app”匹配的路径筛选器。 换句话说，如果更改已推送到文档，则不希望创建新的生成。在本地创建新分支，对文档进行一些更改，然后将该分支推送到服务器。 我们用于触发新的 CI 生成。 这是不需要的，因为你明确要求不要在 docs 文件夹中查找更改。 但是，由于我们处理新分支事件的方式，似乎也对应用文件夹进行了更改。
现在，我们有一种更好的方法来处理 CI，以便新分支解决这些问题。 发布新分支时，我们会在该分支中显式查找新提交，并检查它们是否与路径筛选器匹配。
作业可以访问上一阶段的输出变量
现在，可以在基于 YAML 的管道中跨阶段使用输出变量。 这有助于将有用的信息（例如 go/no-go 决策或生成的输出的 ID）从一个阶段传递到下一个阶段。 结果 (上一阶段的状态) ，并且其作业也可用。
输出变量仍由作业中的步骤生成。 阶段stageDependencies.stageName.jobName.outputs['stepName.variableName']引用，而不是引用dependencies.jobName.outputs['stepName.variableName']。
注意
默认情况下，管道中的每个阶段都依赖于 YAML 文件中的阶段。 因此，每个阶段都可以使用上一阶段的输出变量。 可以更改依赖项图，这将更改可用的输出变量。 例如，如果阶段 3 需要阶段 1 的变量，则需要在阶段 1 上声明显式依赖项。
在池级别禁用自动代理升级
目前，管道代理会在需要时自动更新到最新版本。 当有一项新功能或任务需要较新的代理版本才能正常运行时，通常会发生这种情况。 通过此更新，我们将添加在池级别禁用自动升级的功能。 在此模式下，如果没有正确版本的代理连接到池，管道将失败并显示明确的错误消息，而不是请求代理进行更新。 此功能主要适用于具有自承载池的客户以及非常严格的变更控制要求。 自动更新默认处于启用状态，不建议大多数客户禁用它们。
代理诊断
我们为许多常见的代理相关问题（例如许多网络问题和升级失败的常见原因）添加了诊断。 若要开始使用诊断，请在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版本后，它会自动下载并在发布作业中提供。
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 创建Azure Pipelines
我们已向 VSCode 的 Azure Pipelines 扩展添加了新功能。 现在，无需离开 IDE 即可直接从 VSCode 创建Azure Pipelines。
Flaky bug 管理和解决
我们引入了不起的测试管理，以支持通过检测、报告和解决方法实现端到端生命周期。 为了进一步增强它，我们将添加不起的测试 bug 管理和解决方法。
在调查浮点测试时，可以使用 Bug 操作创建 bug，然后可将其分配给开发人员，以进一步调查异常测试的根本原因。 bug 报告包含有关管道的信息，例如错误消息、堆栈跟踪以及与测试关联的其他信息。
当 bug 报告解决或关闭时，我们会自动将测试标记为不平移。
如果未运行最少的测试数，请将 VSTest 任务设置为失败
VSTest 任务使用用户输入发现和运行测试 (测试文件、筛选条件等) 以及特定于所使用的测试框架的测试适配器。 对用户输入或测试适配器的更改可能会导致未发现测试的情况，并且仅运行预期测试的子集。 这可能会导致管道成功的情况，因为跳过测试，而不是因为代码质量足够高。 为了帮助避免这种情况，我们在 VSTest 任务中添加了一个新选项，该选项允许指定必须为任务传递运行的最小测试数。
VSTest TestResultsDirectory 选项在任务 UI 中可用
VSTest 任务将测试结果和关联的文件 $(Agent.TempDirectory)\TestResults 存储在文件夹中。 我们已向任务 UI 添加了一个选项，用于配置其他文件夹来存储测试结果。 现在，需要特定位置的文件的任何后续任务都可以使用它们。
自动测试错误消息中的 Markdown 支持
我们已为自动测试的错误消息添加了 Markdown 支持。 现在，可以轻松设置测试运行和测试结果的错误消息的格式，以提高可读性，并简化Azure Pipelines中的测试失败故障排除体验。 可 在此处找到支持的 markdown 语法。
使用管道修饰器自动在部署作业中注入步骤
现在可以将 管道修饰器 添加到部署作业。 你可以 (任何自定义步骤，例如漏洞扫描程序) 自动注入到每个部署作业的每个 生命周期挂钩 执行。 由于管道修饰器可以应用于集合中的所有管道，因此可以将其用作强制实施安全部署做法的一部分。
此外，如果定义了部署作业，则可以将部署 作业作为容器作业 以及 服务端车 运行。
Test Plans
“新建测试计划”页
所有Azure DevOps集合都可以使用新的 Test Plans Page (Test Plans *) 。 新页面提供了简化的视图，可帮助你专注于手头的任务 - 测试规划、创作或执行。 它也是混乱的，与Azure DevOps产品的其他部分一致。
帮助我了解新页面
新的Test Plans页总共有 6 个部分，其中前 4 个是新的，而“图表&扩展性”部分是现有功能。
- 测试计划标头：使用此标头查找、收藏、编辑、复制或克隆测试计划。
- 测试套件树：使用此树可以添加、管理、导出或订购测试套件。 利用此功能还可以分配配置和执行用户验收测试。
- 定义选项卡：通过此选项卡在所选测试套件中排序规则、添加和管理测试用例。
- 执行选项卡：通过此选项卡分配和执行测试，或找到要钻取的测试结果。
- 图表选项卡：通过图表跟踪测试执行和状态，这些图表也可以固定到仪表板。
- 扩展性：支持产品中的 当前扩展点 。
让我们大致了解下面这些新部分。
1. 测试计划标头
任务
使用测试计划标头可以执行以下任务：
- 将测试计划标记为收藏夹
- 取消标记收藏的测试计划
- 在喜欢的测试计划之间轻松导航
- 查看测试计划的迭代路径，这清楚地指示测试计划是否为“当前”或“过去”
- 使用指向报表的链接查看测试进度报表的快速摘要
- 导航回“全部/我的Test Plans”页
上下文菜单选项
测试计划标头上的上下文菜单提供以下选项：
- 复制测试计划：这是一个新选项，可用于快速复制当前测试计划。 请参阅以下详细信息。
- 编辑测试计划：此选项允许编辑测试计划工作项窗体来管理工作项字段。
- 测试计划设置：此选项允许配置测试运行设置， (关联生成或发布管道) 和测试结果设置
复制测试计划 (新功能)
建议为每个冲刺/版本创建新的测试计划。 执行此操作时，通常可以复制上一个周期的测试计划，并且复制的测试计划很少更改即可用于新周期。 为了简化此过程，我们在新页面上启用了“复制测试计划”功能。 利用它，可以复制或克隆测试计划。 此处 介绍了其 支持 REST API，API 允许跨项目复制/克隆测试计划。
有关Test Plans使用情况的更多指南，请参阅此处。
2. 测试套件树
任务
使用 Test suite 标头可以执行以下任务：
- 展开/折叠：此工具栏选项允许展开或折叠套件层次结构树。
- 显示子套件中的测试点：只有在“执行”选项卡中时，此工具栏选项才可见。这样，就可以在一个视图中查看给定套件及其子级的所有测试点，以便更轻松地管理测试点，而无需一次导航到单个套件。
- 订单套件：可以将套件拖放到重新排序套件的层次结构，或者将它们从一个套件层次结构移动到测试计划中的另一个套件层次结构。
上下文菜单选项
测试套件树上的上下文菜单提供以下选项：
- 创建新套件：可以创建 3 种不同类型的套件，如下所示：
- 使用静态套件或文件夹套件来组织测试。
- 使用基于要求的套件直接链接到要求/用户情景，实现无缝可追溯性。
- 使用基于查询的函数动态组织满足查询条件的测试用例。
- 分配配置：可以为套件分配配置 (示例：Chrome、Firefox、EdgeChromium) ，然后这些配置适用于以后添加到此套件的所有现有测试用例或新的测试用例。
- 导出为 pdf/email：导出测试计划属性、测试套件属性以及测试用例和测试点的详细信息，作为“电子邮件”或“打印到 pdf”。
- 打开测试套件工作项：此选项允许编辑测试套件工作项窗体来管理工作项字段。
- 分配测试人员以运行所有测试：此选项对于用户验收测试 (UAT) 方案非常有用，这些方案需要由多个测试人员运行/执行，通常属于不同部门。
- 重命名/删除：这些选项允许你管理套件名称，或者从测试计划中删除套件及其内容。
3. 定义选项卡
“定义”选项卡允许你对测试套件进行排序、添加和管理测试用例。 而执行选项卡用于分配测试点并执行它们。
“定义”选项卡和某些操作仅适用于具有基本 + Test Plans访问级别或等效项的用户。 其他所有内容都应由具有“基本”访问级别的用户执行。
任务
使用“定义”选项卡可以执行以下任务：
- 使用工作项窗体添加新测试用例：此选项允许使用工作项窗体创建新的测试用例。 创建的测试用例将自动添加到套件。
- 使用网格添加新测试用例：此选项允许使用测试用例网格视图创建一个或多个测试用例。 创建的测试用例将自动添加到套件。
- 使用查询添加现有测试用例：此选项允许通过指定查询将现有测试用例添加到套件。
- 按拖放对测试用例进行排序：可以通过在给定套件中拖动/删除一个或多个测试用例来重新排序测试用例。 测试用例的顺序仅适用于手动测试用例，不适用于自动测试。
- 将测试用例从一个套件移到另一个套件：使用拖放，可以将测试用例从一个测试套件移到另一个测试套件。
- 显示网格：可以使用网格模式查看/编辑测试用例以及测试步骤。
- 全屏视图：可以使用此选项在全屏模式下查看整个“定义”选项卡的内容。
- 筛选：使用筛选栏，可以使用“测试用例标题”、“已分配给”和“state”的字段筛选测试用例列表。 还可以通过单击列标题对列表进行排序。
- 列选项：可以使用“列选项”在“定义”选项卡中管理可见的列列表。 可用于选择的列列表主要是测试用例工作项窗体中的字段。
上下文菜单选项
“定义”选项卡中“测试用例”节点上的上下文菜单提供以下选项：
- 打开/编辑测试用例工作项窗体：此选项允许使用工作项窗体编辑测试用例，在其中编辑工作项字段，包括测试步骤。
- 编辑测试用例：此选项允许批量编辑测试用例工作项字段。 但是，不能使用此选项批量编辑测试步骤。
- 在网格中编辑测试用例：此选项允许你批量编辑所选测试用例，包括使用网格视图的测试步骤。
- 分配配置：此选项允许使用测试用例级别配置替代套件级别配置。
- 删除测试用例：此选项允许从给定套件中删除测试用例。 不过，它不会更改基础测试用例工作项。
- 创建测试用例的副本/克隆：此选项允许创建所选测试用例的复制/克隆。 有关详细信息，请参阅下文。
- 查看链接项：此选项允许查看给定测试用例的链接项。 有关详细信息，请参阅下文。
复制/克隆测试用例， (新功能)
对于想要复制/克隆测试用例的方案，可以使用“复制测试用例”选项。 可以指定要在其中创建复制/克隆测试用例的目标项目、目标测试计划和目标测试套件。 此外，还可以指定是否要包含要流入克隆副本的现有链接/附件。
(新功能) 查看链接项
测试项目、要求和 bug 之间的可追溯性是Test Plans产品的关键价值主张。 使用“查看链接项”选项，可以轻松查看此测试用例链接到的所有链接要求、使用此测试用例的所有测试套件/测试计划以及作为测试执行的一部分提交的所有 bug。
4. 执行选项卡
“定义”选项卡允许你对测试套件进行排序、添加和管理测试用例。 而执行选项卡用于分配测试点并执行它们。
什么是测试点？ 测试用例本身不是可执行的。 将测试用例添加到测试套件时，将生成测试点 () 。 测试点是测试用例、测试套件、配置和测试器的独特组合。 示例：如果测试用例为“测试登录功能”，并将 2 个配置作为 Edge 和 Chrome 添加到其中，则这会导致 2 个测试点。 现在可以执行这些测试点。 在执行时，将生成测试结果。 通过测试结果视图 (执行历史记录) 可以查看测试点的所有执行。 测试点的最新执行是在“执行”选项卡中看到的内容。
因此，测试用例是可重用的实体。 通过在测试计划或套件中包含它们，将生成测试点。 通过执行测试点，可以确定正在开发的产品或服务的质量。
新页面的主要优点之一是，主要对主要执行/跟踪 (需要只有“基本”访问级别) 的用户而言，由于套件管理的复杂性 (定义选项卡对于此类用户) 隐藏，它们并不不知所措。
“定义”选项卡和某些操作仅适用于具有基本 + Test Plans访问级别或等效项的用户。 其他所有内容（包括“执行”选项卡）都应由具有“基本”访问级别的用户行使。
任务
使用“执行”选项卡可以执行以下任务：
- 批量标记测试点：此选项允许快速标记测试点的结果 - 通过、失败、阻止或不适用，而无需通过测试运行程序运行测试用例。 结果可以在一次标记一个或多个测试点。
- 运行测试点：此选项允许你单独完成每个测试步骤并使用测试运行程序标记测试用例通过/失败。 根据要测试的应用程序，可以使用“Web 运行程序”测试“Web 应用程序”或“桌面运行程序”来测试桌面和/或 Web 应用程序。 还可以调用“使用选项运行”，以指定要对其执行测试的生成。
- 列选项：可以使用“列选项”管理“执行选项卡中可见的列列表。 可用于选择的列列表与测试点相关联，例如运行者、分配的测试人员、配置等。
- 全屏视图：可以使用此选项在全屏模式下查看整个“执行”选项卡的内容。
- 筛选：使用筛选栏，可以使用“测试用例标题”、“已分配到”、“状态”、“测试结果”、“测试人员”和“配置”字段筛选测试点列表。 还可以通过单击列标题对列表进行排序。
上下文菜单选项
“执行”选项卡中“测试点”节点上的上下文菜单提供以下选项：
- 标记测试结果：与上述相同，可让你快速标记测试点的结果 - 通过、失败、阻止或不适用。
- 运行测试点：与上述相同，允许通过测试运行程序运行测试用例。
- 将测试重置为活动状态：此选项允许将测试结果重置为活动状态，从而忽略测试点的最后一个结果。
- 打开/编辑测试用例工作项窗体：此选项允许使用工作项窗体编辑测试用例，在其中编辑工作项字段，包括测试步骤。
- 分配测试人员：此选项允许将测试点分配给测试人员进行测试执行。
- 查看测试结果：此选项允许查看最新的测试结果详细信息，包括每个测试步骤的结果、添加的注释或提交的 bug。
- 查看执行历史记录：此选项允许查看所选测试点的整个执行历史记录。 此时会打开一个新页面，你可以在其中调整筛选器，查看不仅所选测试点的执行历史记录，还可以查看整个测试用例的执行历史记录。
Test Plans进度报告
此现用报表可帮助你跟踪项目中一个或多个Test Plans的执行和状态。 访问Test Plans>进度报告* 以开始使用报表。
报告的三个部分包括：
- 摘要：显示所选测试计划的合并视图。
- 结果趋势：呈现每日快照，以便提供执行和状态趋势线。 它可以显示 14 天的数据 (默认) 、30 天或自定义范围。
- 详细信息：本部分允许你按每个测试计划向下钻取，并为每个测试套件提供重要的分析。
Artifacts
注意
Azure DevOps Server 2020 不会在数据导入期间导入回收站中的源。 如果要导入回收站中的源，请在开始数据导入之前从回收站还原它们。
许可证表达式和嵌入式许可证
现在，可以在浏览Visual Studio中的包时查看存储在Azure Artifacts中的NuGet包的许可证信息的详细信息。 这适用于使用许可证表达式或嵌入式许可证表示的许可证。 现在，可以在Visual Studio包详细信息页中看到许可证信息的链接， (下图中的红色箭头) 。
单击链接将带你到一个网页，你可以在其中查看许可证的详细信息。 对于许可证表达式和嵌入式许可证，此体验相同，因此可以在一个位置查看存储在 Azure Artifacts 中的包的许可证详细信息， (用于指定许可证信息且受Visual Studio) 支持。
轻型身份验证任务
现在，可以使用轻型身份验证任务通过Azure Pipelines中的常用包管理器进行身份验证。 这包括NuGet、npm、PIP、Twine 和 Maven。 以前，可以使用提供大量功能的任务（包括发布和下载包的功能）对这些包管理器进行身份验证。 但是，对于与包管理器交互的所有活动，这需要使用这些任务。 如果自己的脚本要运行以执行发布或下载包等任务，则无法在 Pipeline 中使用它们。 现在，可以在管道 YAML 中使用自己的设计脚本，并通过这些新的轻型任务执行身份验证。 使用 npm 的示例：
此图中使用“ci”和“publish”命令是任意的，可以使用Azure Pipelines YAML 支持的任何命令。 这使你能够完全控制命令调用，并使它在管道配置中易于使用共享脚本。 有关详细信息，请参阅 NuGet、npm、PIP、Twine 和 Maven 身份验证任务文档。
对源页面加载时间的改进
我们很高兴地宣布，我们改进了源页面加载时间。 平均而言，源页加载时间已减少 10%。 最大的源在 99% 的源加载时间 (加载时间中，所有源中的最大 99%) 下降了 75%。
使用公共源公开共享包
现在可以在公共源中创建和存储包。 存储在公共源中的包可供 Internet 上的所有人使用，无论它们是否在集合中，还是登录到Azure DevOps集合中。 在 源文档中 了解有关公共源的详细信息，或直接跳转到 教程中公开共享包。
在 AAD 租户中的不同集合中配置上游
现在可以在与 Azure Active Directory (AAD) 租户关联的另一个集合中添加源作为Artifacts源的上游源。 源可以从配置为上游源的源中查找和使用包，从而允许在与 AAD 租户关联的集合之间轻松共享包。 了解如何 在文档中设置此设置。
使用 Python 凭据提供程序通过 Azure Artifacts 源对 pip 和 twine 进行身份验证
现在可以安装和使用 Python 凭据提供程序 (项目密钥) 自动设置身份验证，以发布或使用 Python 包到Azure Artifacts源。 使用凭据提供程序时，无需设置任何配置文件 (pip.ini/pip.conf/.pypirc) ，在首次调用 pip 或 twine 时，只需在 Web 浏览器中通过身份验证流。 请参阅 文档中的详细信息。
Visual Studio 程序包管理器中的Azure Artifacts源
我们现在在Azure Artifacts源提供的包的Visual Studio NuGet 程序包管理器中显示包图标、说明和作者。 以前，大部分元数据未提供给 VS。
更新了连接以提供体验
源对话框连接是使用 Azure Artifacts 的入口;它包含有关如何配置客户端和存储库以从Azure DevOps中的源推送和拉取包的信息。 我们更新了对话框，以添加详细的设置信息并扩展了我们提供说明的工具。
公共源现已正式发布，上游支持
公共源的公共预览版得到了很好的采用和反馈。 在此版本中，我们将其他功能扩展到正式发布。 现在，可以从专用源将公共源设置为上游源。 可以通过在专用源和项目范围的源上上游，使配置文件保持简单。
从门户创建项目范围的源
当我们发布公共源时，我们还发布了 项目范围的源。 到目前为止，可以通过 REST API 或创建公共源，然后打开项目专用源来创建项目范围源。 现在，如果拥有所需的权限，可以直接在门户中从任何项目创建项目范围的源。 还可以查看哪些源是项目，哪些源在源选取器中具有集合范围。
npm性能改进
我们对核心设计进行了更改，以改进在Azure Artifacts源中存储和交付npm包的方式。 这有助于我们实现高达 10 倍的延迟减少，一些用于npm的最高使用 API。
辅助功能改进
我们已部署修补程序来解决源页上的辅助功能问题。 修复包括以下内容：
- 创建源体验
- 全局源设置体验
- 连接来提供体验
Wiki
代码 Wiki 页面的丰富编辑
以前，编辑代码 Wiki 页面时，你被重定向到Azure Repos中心进行编辑。 目前，存储库中心未针对 markdown 编辑进行优化。
现在，你可以在 Wiki 内的并行编辑器中编辑代码 Wiki 页面。 这样，便可以使用丰富的 markdown 工具栏创建内容，使编辑体验与项目 Wiki 中的内容相同。 仍可以通过在上下文菜单中选择“在Repos中编辑”选项，选择在存储库中进行编辑。
从 Wiki 页面创建和嵌入工作项
当我们听取你的反馈时，我们听到你使用 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 分钟间隔将页面访问定义为给定用户的页面视图。
报表
管道故障和持续时间报告
指标和见解可帮助你持续提高管道的吞吐量和稳定性。 我们添加了两个新报表，用于提供有关管道的见解。
- 管道故障报告显示生成通过率和失败趋势。 此外，它还会显示任务失败趋势，以提供有关管道中哪些任务导致最大故障数的见解。
- 管道持续时间报告显示管道运行所花费的时间趋势。 它还显示管道中的哪些任务花费的时间最多。
查询结果小组件的改进
查询结果小组件是我们最受欢迎的小组件之一，有充分的理由。 小组件直接在仪表板上显示查询结果，在许多情况下非常有用。
通过此更新，我们包含了许多期待已久的改进：
- 现在可以选择要在小组件中显示的任意数量的列。 不再有 5 列限制！
- 该小组件支持从 1x1 到 10x10 的所有大小。
- 调整列大小时， 将保存列宽。
- 可以将 小组件展开为全屏视图。 展开后，它将显示查询返回的所有列。
潜在顾客和周期时间小组件高级筛选
团队使用潜在顾客和周期时间 来了解工作流经开发管道所需的时间，并最终为客户提供价值。
到目前为止， 潜在顾客和周期时间小组件 不支持高级筛选条件来提问，例如：“我的团队关闭优先级较高的项目需要多长时间？
通过筛选板泳道，可以回答此类更新问题。
我们还包含工作项筛选器，以限制图表中显示的工作项。
内联冲刺烧毁使用故事点
你的冲刺烧毁现在可以被故事烧毁。 这解决了来自开发者社区的反馈。
从冲刺中心选择“分析”选项卡。然后按如下所示配置报表：
- 选择故事积压工作
- 选择以烧毁 故事点的总和
一个冲刺烧毁小组件，其中包含你一直在请求的所有内容
新的 Sprint Burndown 小组件支持按故事点、任务计数或对自定义字段求和来向下燃烧。 甚至可以为功能或史诗创建冲刺烧毁。 小组件显示平均烧毁率、完成百分比和范围增加。 可以配置团队，以便在同一仪表板上显示多个团队的冲刺进度。 通过显示所有这些出色的信息，可以在仪表板上将其大小调整为 10x10。
若要试用，可以从小组件目录中添加它，也可以编辑现有 Sprint Burndown 小组件的配置，并选中“ 立即试用新版本 ”框。
注意
新小组件使用 Analytics。 如果无法访问 Analytics，我们将保留旧版 Sprint Burndown。
内联冲刺烧毁缩略图
冲刺烧毁回来了！ 几个冲刺前，我们从 Sprint Burndown 和 Taskboard 标头中删除了上下文冲刺烧毁。 根据你的反馈，我们改进了并重新引入了冲刺烧毁缩略图。
单击缩略图将立即显示更大的图表版本，并可以选择在“分析”选项卡下查看完整报表。对完整报表所做的任何更改都将反映在标题中显示的图表中。 因此，现在可以将其配置为基于故事、故事点或任务计数（而不是剩余工时量）进行烧毁。
在没有团队的情况下创建仪表板
现在可以创建仪表板，而无需将其与团队关联。 创建仪表板时，选择Project仪表板类型。
Project仪表板类似于团队仪表板，但与团队无关，你可以决定谁可以编辑/管理仪表板。 就像团队仪表板一样，项目中的每个人都可以看到它。
所有需要团队上下文的Azure DevOps小组件都已更新，以便你在其配置中选择团队。 可以将这些小组件添加到Project仪表板，然后选择所需的特定团队。
注意
对于自定义或第三方小组件，Project仪表板会将默认团队的上下文传递给这些小组件。 如果你有依赖于团队上下文的自定义小组件，则应更新配置，以便选择团队。
反馈
我们期待你的宝贵意见和建议！ 你可以报告问题或提供想法，并通过开发者社区跟踪它，并获取有关 Stack Overflow 的建议。