Azure DevOps Server 2020 发行说明

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


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

修补程序 7 for Azure DevOps Server 2020.0.1 包括以下内容的修补程序。

  • 以前 Azure DevOps Server 只能创建到 GitHub Enterprise 服务器的连接。 利用此修补程序,项目管理员可以在 GitHub 的 Azure DevOps Server 和存储库之间创建连接。 可以在 " GitHub 连接" 页的 " Project 设置" 下找到此设置。
  • 解决测试计划小组件问题。 测试执行报告在结果上显示了错误的用户。
  • 解决了无法加载 Project 概述摘要 "页的问题。
  • 解决了未发送电子邮件以确认产品升级的问题。

Azure DevOps Server 2020.0.1 Patch 6 发布日期:2021年9月14日

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

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

Azure DevOps Server 2020.0.1 Patch 5 发布日期:2021年8月10日

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

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

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

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

  • 解决数据导入问题。 对于具有大量过时测试用例的客户,数据导入花费了很长时间。 这是因为引用增加了表的大小 tbl_testCaseReferences 。 在此修补程序中,我们删除了对过时的测试用例的引用以帮助加快数据导入过程。

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

我们发布了一个修补程序,用于修补以下 Azure DevOps Server 2020.0.1。

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

如果有 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 Patch 3 后,版本将为18.170.31228.1。

Azure DevOps Server 2020.0.1 Patch 2 发布日期:2021年4月13日

备注

如果你有 Azure DevOps Server 2020,你应该首先更新到 Azure DevOps Server 2020.0.1。 在2020.0.1 上安装 Azure DevOps Server 2020.0.1 Patch 2

我们发布了一个修补程序,用于修补以下 Azure DevOps Server 2020.0.1。

若要实现此修补程序的修补程序,你必须按照下面列出的步骤进行 常规修补程序安装AzureResourceGroupDeploymentV2AzureResourceManagerTemplateDeploymentV3 任务安装。

常规修补程序安装

如果有 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 Patch 2 后,版本将为18.170.31123.3。

AzureResourceGroupDeploymentV2 任务安装

备注

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

安装

  1. AzureResourceGroupDeploymentV2.zip 包提取到计算机上的新文件夹中。 例如: D:\tasks\AzureResourceGroupDeploymentV2

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

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

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

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

~$ tfx login
Copyright Microsoft Corporation

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

  1. 运行以下命令,将任务上传到服务器。 使用从步骤 1 中提取的 .zip 文件的路径。
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

AzureResourceManagerTemplateDeploymentV3 任务安装

备注

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

安装

  1. AzureResourceManagerTemplateDeploymentV3.zip 包提取到计算机上的新文件夹中。 例如:D:\tasks\AzureResourceManagerTemplateDeploymentV3

  2. 下载并安装 Node.js 14.15.1 和 npm (随附 Node.js 下载) 适用于你的计算机。

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

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

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

~$ tfx login
Copyright Microsoft Corporation

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

  1. 运行以下命令,将任务上传到服务器。 使用从步骤 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 修补程序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 之前,修复非简体中文集合的 OutOfMemoryException 异常。 解决了此开发人员 Community 反馈票证中报告的问题。
  • 因缺少 Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll 而导致的服务失败。 解决了此开发人员 Community 反馈票证中报告的问题。
  • 升级到 Azure DevOps Server 2020 时,修复分析中的列名称无效错误。 解决此开发人员反馈票证中Community的问题
  • 在测试用例结果中显示测试用例步骤时存储的 XSS。
  • 将结果数据迁移到 TCM 时升级步骤失败。

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

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

  • 测试运行详细信息不显示使用 OpsHub 迁移迁移的测试数据的测试步骤详细信息
  • "Microsoft.TeamFoundation.TestManagement.Server.TCMLogger"的初始值创建程序异常
  • 迁移到 2020 年 1 月后,将立即删除Azure DevOps Server生成
  • 修复数据提供程序异常

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 修复的汇总。 它包含之前发布的 2020 RC2 Azure DevOps Server的所有功能。

备注

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 。 如果缺少文件,可以运行修复来还原缺少的文件。

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

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

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

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

我们重新发布了 2020 RC1 Azure DevOps Server,以修复此开发人员Community反馈票证

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

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

2020 年 Azure DevOps Server 新增功能摘要

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

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


常规

Azure DevOpsCLI 通用

2 月,我们引入了 Azure DevOps 的 Azure CLI。 通过扩展,你可以Azure DevOps命令行中的对象进行交互。 我们收集了你的反馈,帮助我们改进了扩展并添加更多命令。 现在,我们很高兴地宣布该扩展已正式发布。

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

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

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

Boards

将"父工作项"筛选器添加到任务板和冲刺 (sprint)积压工作

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

显示新的"父工作项"筛选器的屏幕截图。

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

过去,如果从看板将工作项从一列移到另一列(其中状态更改触发了字段规则)中,卡片将只显示一条红色错误消息,这将强制你打开工作项以了解根本原因。 在冲刺 170 冲刺 170 中,我们改进了体验,因此现在可以单击红色错误消息以查看错误的详细信息,而无需打开工作项本身。

显示单击红色错误消息时出现的"缺少字段"对话框的屏幕截图。

工作项实时重载

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

显示工作项实时重载工作原理的简短视频。

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

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

作为列选项的工作项父列

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

积压工作 (其中已列选项选项)的屏幕截图。

更改项目使用的进程

工具应随着团队的变化而改变,现在可以将项目从任何现成流程模板切换到任何其他现成流程。 例如,可以将项目从使用敏捷更改为 Scrum,或将"基本"更改为"敏捷"。 可在此处找到完整的分步 文档

"项目"选项卡的屏幕截图,其中已调用"更改过程"选项。

隐藏布局中的自定义字段

现在可以在自定义过程时从窗体布局中隐藏自定义字段。 字段仍可从查询和 REST API 获得。 当你与其他系统集成时,这非常方便地用于跟踪额外的字段。

显示"从布局中隐藏"选项的屏幕截图。

使用三个新报表获取团队运行状况Azure Boards见解

无法修复看不到的问题。 因此,你需要密切注意其工作流程的状态和运行状况。 借助这些报表,我们可让你更轻松地跟踪重要指标,只需Azure Boards。

这三个新的交互式报表包括:燃尽累积 Flow 关系图 (CFD) 和 速度。 可以在 "新建分析" 选项卡中查看报告。

"冲刺(sprint)燃尽、工作流和团队速度" 等指标使你可以查看团队的进度,并帮助回答以下问题:

  • 此冲刺(sprint)中剩余多少工作? 我们是否在跟踪来完成它?
  • 开发过程的哪一步的时间最长? 我们能做些什么呢?
  • 根据之前的迭代,我们应该为下一个冲刺(sprint)计划多少工作量?

备注

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

新报告是完全交互的,可让你根据需要进行调整。 可以在每个集线器中的 " 分析" 选项卡 下找到新报表。

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

    "分析" 选项卡上燃尽图的屏幕截图。

  • 可以通过单击相关卡 Boards积压 工作(backlog)下的 "分析" 选项卡 访问 "CFD" 和 "速度" 报表。

    "分析" 选项卡上的累积 Flow 关系图报表和速度报表的屏幕截图。

使用新的报表,你可以更好地控制和了解团队信息。 下面是一些示例:

  • "冲刺(Sprint)燃尽" 和 "速度" 报表可设置为使用工作项计数或剩余工作的总和。
  • 你可以在不影响项目日期的情况下调整冲刺(sprint)燃尽的时间范围。 因此,如果您的团队通常花费每个冲刺(sprint)计划的第一天,则您现在可以匹配该图表以反映这一情况。
  • 现在,燃尽图显示了周末。
  • CFD 报表允许您删除板列(如 "设计"),以更关注团队控制的流。

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

"分析" 选项卡上的累积 Flow 关系图的屏幕截图。

现在可以跟踪所有积压工作(backlog)级别的速度图表。 例如,现在可以添加功能和长篇故事,但之前的图表仅支持要求。 下面是功能积压工作(backlog)的最后6次迭代的速度报表示例。

"分析" 选项卡上速度图的屏幕截图。

自定义任务板列

我们很高兴地宣布,我们添加了一个选项,让你在任务板上自定义列。 现在可以对列进行添加、删除、重命名和重新排序。

若要配置任务板上的列,请参阅 列选项

任务板选项的屏幕截图,其中列选项选项称为 out。

此功能的优先顺序基于开发人员 Community 的建议

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

很多时候,在优化积压工作(backlog)时,只需查看尚未完成的项。 现在,可以显示或隐藏积压工作(backlog)上已完成的子项。

如果开启切换,您将看到所有子项处于 "已完成" 状态。 如果切换功能处于关闭状态,则已完成状态的所有子项将从积压工作(backlog)中隐藏。

显示如何显示或隐藏积压工作(backlog)上的子项的简短视频。

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

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

显示标记工作项时显示的最新已用标记的屏幕截图。

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

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

显示 "条件" 部分和 "操作" 部分的 "新建工作项规则" 对话框的屏幕截图。

自定义系统选择列表值

你现在可以自定义任何系统选择列表的值 (除了 "原因" 字段) 例如严重性、活动、优先级等。选择列表自定义项的作用域,以便您可以为每个工作项类型的相同字段管理不同的值。

显示如何自定义系统选择列表值的简短视频。

新建工作项 URL 参数

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

与之共享链接的任何人都将与共享链接时所用的上下文相同!

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

当我们听取你的反馈时,我们听说你希望能够在工作项描述 (区域中提及人员、工作项和 Pr,而不只是在注释中) 。 有时,您与某个工作项上的某人合作,或想要突出显示您的工作项说明中的 PR,但没有添加该信息的方法。 现在,你可以在工作项的所有长文本字段中提及人员、工作项和 Pr。

可在此处查看示例。

显示您可以在 "工作项说明" 区域中提及人员、工作项和 Pr 的屏幕截图。

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

讨论评论的反应

我们的主要目标之一是使工作项更适合团队。 最近,我们已 在 Twitter 上进行了一次投票,找出你想要在工作项上讨论哪些协作功能。 对注释进行的反应赢得了投票,因此我们添加它们! 下面是 Twitter 轮询的结果。

Azure DevOps twitter 轮询的屏幕截图,其中显示了35% 的被调查者需要反应注释功能。

您可以向任何注释添加反应,还可以通过两种方式添加反应–任何注释右上角的笑脸图标以及任何现有反应旁的注释底部。 您可以根据需要添加全部六项反应,或只添加一个或两个反应。 若要删除响应,请单击注释底部的 "反应",它将被删除。 在下面可以看到添加反应的体验,以及注释上的反应外观。

屏幕截图,显示你可以通过两种不同的方式将反应添加到注释。

将 Azure Boards 报表固定到仪表板

在冲刺(Sprint)155更新中,我们提供 了 CFD 和速度报表的更新版本。 这些报告在 Boards 和积压工作(backlog)的 "分析" 选项卡下提供。 现在,可以直接将报表固定到仪表板。 若要固定报表,请将鼠标悬停在报表上,选择省略号 "..."菜单,并 将其复制到仪表板

显示 "复制到仪表板" 选项的屏幕截图。

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

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

例如,在这里,我们将显示 工作项的进度,这些工作项 根据已关闭的后代项的百分比显示祖先工作项的进度栏。 长篇故事的子代项包含所有子功能及其子工作项或子工作项。 功能的子代项包括所有子用户情景及其子工作项。

积压工作(backlog)中的工作项的屏幕截图。

任务板实时更新

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

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

现在可以对任何字段(包括自定义字段)执行汇总操作。 添加汇总列时,仍可以从 "快速" 列表中选取汇总列,但是,如果您希望在不属于现成过程模板的数字字段上进行汇总,则可以按如下所示配置您自己的:

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

    "添加汇总列"下拉列表的屏幕截图。

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

列选项面板的屏幕截图,其中显示了新的自定义列。

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

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

我们已将新规则添加到继承的规则引擎,以允许隐藏工作项窗体中的字段。 此规则将基于用户组成员身份隐藏字段。 例如,如果用户属于"产品所有者"组,可以隐藏开发人员特定的字段。 有关更多详细信息,请参阅此处 的文档

自定义工作项通知设置

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

以前,如果要跟踪工作项并获取有关任何更改的通知,你可收到针对该工作项进行的任何更改和所有更改的电子邮件通知。 在考虑你的反馈后,我们将使所有利益干系人能够更灵活地遵循工作项。 现在,将在工作项右上角的"关注"按钮旁边看到一个新的设置按钮。 这会将你打开一个弹出窗口,用于配置以下选项。

工作项右上角的屏幕截图,其中光标悬停在齿轮图标上。

"通知设置" 中,可以从三个通知选项中进行选择。 首先,可以完全取消订阅。 其次,可以完全订阅,可在其中获取所有工作项更改的通知。 最后,可以选择接收有关一些顶级和关键工作项更改事件的通知。 只能选择一个或全部三个选项。 这样,团队成员可以更高级别地关注工作项,而不要被进行的每一项更改都分散注意力。 借助此功能,我们将消除不必要的电子邮件,并让你专注于当前的重要任务。

"通知更改设置对话框的屏幕截图,其中显示了已选择"自定义"单选按钮以及"状态已更改"选项和"迭代更改"选项。

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

显示工作项窗体上的"部署"控件的屏幕截图。

从 CSV 文件导入工作项

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

演示如何从 CSV 文件导入工作项的简短视频。

将父字段添加到工作项卡

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

显示工作项卡的屏幕截图,其中已调用"父"选项。

向积压工作与查询添加父字段

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

"列选项"部分屏幕截图,其中已调用"父"选项。

Repos

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

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

显示可以在拉取请求和拉取请求视图中查看更改的代码覆盖率指标的屏幕截图 (PR) 视图。

拉取请求差异的屏幕截图,其中显示了添加到文件的新代码行。

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

"添加状态策略"选项的屏幕截图,以及选择该选项时出现的"添加状态策略"部分。

筛选拉取请求的注释通知

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

显示如何筛选拉取请求的注释通知的屏幕截图。

显示"筛选条件"页和"字段"下拉列表内容的屏幕截图。

拉取请求注释的服务挂钩

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

"新建服务挂钩订阅"向导的屏幕截图。

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

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

屏幕截图显示了"策略"部分,其中"文件名验证"选项设置为"打开"。

使用关键字词通过提交解决工作项

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

自动审阅者的粒度

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

显示"自动包括审阅者"对话框的屏幕截图。

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

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

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

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

显示项目中 Markdown 文件的屏幕截图,其中已调用"视图"和"预览"选项。

手动生成生成策略过期

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

"添加生成策略"对话框的屏幕截图,其中显示了"生成过期"部分。

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

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

显示 "提交作者电子邮件验证" 选项设置为 "打开" 的 "策略" 选项卡上的所有 Git 存储库策略的屏幕截图。

此功能的优先级取决于开发人员 Community 的建议,以提供类似的体验。 我们会继续保持该票证处于打开状态,并鼓励用户告诉我们你想要查看的其他类型的推送策略。

将文件标记为在拉取请求中查看

有时,您需要查看包含大量文件更改的拉取请求,这可能很难跟踪您已经查看的文件。 现在,你可以将文件标记为在拉取请求中查看。

您可以使用文件名旁边的下拉菜单或通过悬停并单击文件名来将文件标记为已查看。

备注

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

屏幕截图:显示项目并在文件资源管理器中显示视图,并将其标记为查看的选项。

此功能的优先顺序基于开发人员 Community的建议。

Azure Repos 登陆页面的新 Web UI

你现在可以在 Azure Repos 中试用新的新式、快速且易于移动的登陆页面。 这些页面作为新的 Repos 登陆页面 提供。 登录页面包含除 "拉取请求详细信息"、"提交详细信息" 和 "分支比较" 之外的所有页面。

Web

Azure Repos 登陆页面的新 web UI 的屏幕截图。

移动

Azure Repos 登陆页面的新移动 UI 的屏幕截图。

跨存储库分支策略管理

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

"添加分支保护" 对话框的屏幕截图。

新的 web 平台转换登录页

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

Web 体验:

Web 平台转换登录页的屏幕截图。

移动体验:

"移动平台转换文件" 页的屏幕截图。

移动平台转换提交页的屏幕截图。

支持 Kotlin 语言

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

UI 中显示的 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。

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

{
  "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 计划诊断错误。

显示运行管道菜单的屏幕截图,其中的计划运行选项称为 out。

更新到服务连接 UI

我们一直在努力管理你的服务连接的最新用户体验。 这些更新使服务连接体验现代化,并与 Azure DevOps 的方向一致。 我们在今年早些时候推出了用于服务连接的新 UI 作为预览功能。 感谢大家尝试新体验并向我们提供有价值的反馈。

"新建服务连接" 对话框的屏幕截图。

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

屏幕截图:显示 YAML 管道中的 "编辑" 菜单,并显示 "批准" 和 "检查" 选项。

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

备注

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

跳过 YAML 管道中的阶段

当你开始手动运行时,有时可能需要跳过管道中的几个阶段。 例如,如果您不希望部署到生产环境,或者您想要跳过部署到生产环境中的几个环境。 你现在可以通过 YAML 管道完成此操作。

更新的运行管道面板显示了 YAML 文件中的阶段列表,您可以选择跳过这些阶段中的一个或多个阶段。 跳过阶段时必须小心谨慎。 例如,如果第一个阶段产生后续阶段所需的某些项目,则不应跳过第一个阶段。 当跳过具有下游依赖项的阶段时,"运行" 面板将显示一般警告。 对于这些依赖项是真正的项目依赖项,还是只为部署的排序方式提供这些依赖项。

显示 "运行管道" 部分的屏幕截图,其中包含要运行的用于运行选项的选项。

跳过阶段等效于 rewiring 阶段之间的依赖关系。 所跳过的阶段的任何即时的下游依赖项都将依赖于跳过的阶段的上游父项。 如果运行失败,如果尝试重新运行失败的阶段,则该尝试也将具有相同的跳过行为。 若要更改要跳过的阶段,则必须启动新的运行。

显示 "要运行的阶段" 部分的屏幕截图,其中选择了 dev 选项和 "部署" 选项。

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

有一个新的服务连接用户界面。 这一新的 UI 基于新式设计标准,随附了各种关键功能,以支持多阶段 YAML CD 管道,如批准、授权和跨项目共享。

"运行管道" 对话框的屏幕截图。

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

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

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

"要运行的阶段" 对话框的屏幕截图。

azCLI 对 Azure Pipelines 的改进

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

您可以根据需要手动设置管道变量和变量组,将基于 YAML 的管道从一个项目移植到另一个项目。 但是,对于 "管道 变量组 " 和 " 变量 管理" 命令,你现在可以编写对管道变量和变量组的设置和管理的脚本,这些变量和变量组会反过来受版本控制,从而使你可以轻松地共享说明,以便从一个项目移动到另一个项目并设置管道。

运行 PR 分支的管道

创建 PR 时,验证所做的更改是否可能会中断目标分支上的管道运行可能会很困难。 但是,若要为 PR 分支触发管道运行或对生成进行排队,你现在可以通过对目标管道运行所做的更改来验证和直观显示这些更改。 有关详细信息,请参阅 az 管道运行az 管道生成队列 命令文档。

跳过第一个管道运行

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

服务终结点命令增强

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

部署作业

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

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

  • timeoutInMinutes -在自动取消之前运行作业的时间长度
  • cancelTimeoutInMinutes -在终止任务之前,为 "始终运行(即使已取消)任务" 指定多长时间
  • 条件 -按条件运行作业
  • 变量 -可以直接添加或 变量组,可以引用 由 Azure key vault 支持的可变组 ,也可以引用 文件中定义的一组变量。
  • continueOnError -如果将来的作业应运行,即使此部署作业失败,默认值为 "false"

有关部署作业的详细信息以及用于指定部署作业的完整语法,请参阅 部署作业

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

我们添加了对 CD YAML 管道的支持,其中 CI 管道称为管道资源。 在 CI 管道的 "运行" 视图中,你现在会看到一个新的 "关联管道" 选项卡,你可以在其中找到使用管道的所有管道和项目。

显示 CI 管道中关联的 CD 管道信息的屏幕截图。

对 YAML 管道中 GitHub 包的支持

我们最近引入了一种名为 的新资源类型,它添加了对从 GitHub 作为 YAML 管道中的资源使用 NuGetnpm 包的支持。 作为此资源的一部分,你现在可以指定要从 GitHub 使用的包类型 (NuGet 或 npm) 。 你还可以在发布新包版本时启用自动管道触发器。 现在,支持仅可用于从 GitHub 使用包,但在不断发展的情况下,我们计划扩展支持以使用其他包存储库中的包,如NuGetnpmAzureArtifacts等。 有关详细信息,请参阅下面的示例:

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 边栏选项卡。 这适用于映射到 Azure Kubernetes Service 群集中的命名空间的环境。

Kubernetes 环境资源视图的屏幕截图,其中包含称为 "Azure Kubernetes Service 群集" 的链接。

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

文件夹允许组织管道以便于发现和安全控制。 通常,可能需要为所有发布管道配置自定义电子邮件通知,该通知由文件夹下的所有管道表示。 以前,必须配置多个订阅,或在订阅中包含复杂的查询,才能获得重点电子邮件。 使用此更新,现在可以将 release folder 子句添加到 部署已完成批准挂起 事件,并简化订阅。

通知订阅中发布文件夹筛选器的屏幕截图。

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

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

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

重试失败的阶段

多阶段管道中最常请求的功能之一是能够重试失败的阶段,而无需从头开始。 在此更新中,我们将添加此功能的一个重要部分。

你现在可以在执行失败时重试管道阶段。 在第一次尝试中失败的作业,以及那些依赖于这些失败作业的可传递的作业都将重试。

这可以通过多种方式帮助你节省时间。 例如,当你在一个阶段中运行多个作业时,你可能希望每个阶段在不同的平台上运行测试。 如果某个平台上的测试在其他人通过时失败,则可以通过不重新运行通过的作业来节省时间。 作为另一个示例,部署阶段可能由于不可靠网络连接而失败。 重试该阶段将有助于节省时间,而无需生成另一个生成。

此功能有几个已知的空白部分。 例如,你不能重试已明确取消的阶段。 我们正在努力在未来的更新中关闭这些缺口。

多阶段 YAML 管道中的审批

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

"添加资源" 菜单的屏幕截图,其中包含带下划线的 "检查" 选项。

管道将运行部署,以在阶段开始时停止进行审批。

显示部署正在等待批准的屏幕截图。

提高入口超时限制和频率

以前,release 管道中的入口超时限制为三天。 在此更新中,超时限制增加到了 15 天 ,允许具有更长时间的入口。 我们还将门的频率提高到了 30 分钟

Dockerfile 的新生成映像模板

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

Docker 对话框的屏幕截图。

用于配置 Azure App Service 应用设置的新任务

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

显示 Azure App Service 设置 "对话框的屏幕截图。

Azure App Service 现在支持带预览的交换

Azure App Service 现在支持在其部署槽上 交换和预览 。 这是使用生产配置验证应用的好方法,在实际将应用从过渡槽交换到生产槽之前。 这还将确保目标/生产槽不会遇到停机。

Azure App Service 任务现在通过以下新操作支持此多阶段交换:

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

显示 "Azure App Service 管理" 对话框的屏幕截图,其中包含 "操作" 下拉列表中的新多阶段交换设置。

Azure 容器注册表和 Docker 中心项目的阶段级筛选器

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

显示可在临时级别使用正则表达式的屏幕截图。

YAML 管道中的批准的增强功能

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

经验类似于为环境配置审批。 当在某一阶段引用的某个资源的审批处于挂起状态时,管道的执行将等待,直到手动批准该管道。

显示 "策略" 选项卡的屏幕截图,其中包含 "使用手动批准" 页和 "创建" 选项可见。

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

应用程序中的容器的使用不断增加,因而需要进行可靠的测试和验证。 Azure Pipelines 现在为 容器结构测试 引入了支持。 此框架提供了一种方便且功能强大的方法来验证容器的内容和结构。

可以根据可一起运行的四个测试类别来验证映像的结构:命令测试、文件存在测试、文件内容测试和元数据测试。 您可以使用管道中的结果来做出走即用决策。 测试数据在管道运行中提供,并显示错误消息,以帮助你更好地排除故障。

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

显示容器结构测试页的屏幕截图。

测试数据和摘要

显示摘要和测试数据可用的屏幕截图。

Release 管道的管道修饰器

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

我们支持修饰器和 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 的环境安排有的部署策略

持续交付应用程序更新的主要优点之一是能够快速将更新推送到特定微服务的生产环境中。 这使你能够快速响应业务需求的变化。 环境 已作为一流的概念引入,实现了部署策略的业务流程,并简化了零停机时间。 以前,我们支持按顺序执行步骤的 runOnce 策略。 由于支持多阶段管道中的 "缩小" 策略,因此你现在可以通过慢慢地将更改过渡到小型子集来降低风险。 当你在新版本中获得更多的信心时,你可以开始将其放到基础结构中的更多服务器上,并将更多用户路由到该服务器。

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 的策略将首先部署包含10% 箱的更改,后跟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

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

我们增强了 评估项目检查 功能,使你可以更轻松地从现成的策略定义列表添加策略。 将自动生成策略定义并将其添加到 检查配置 中(如果需要)。

屏幕截图,显示 "使用模板" 选项带下划线的 "评估项目" 对话框。

显示 "配置项目策略" 对话框的屏幕截图,其中选择了 "白名单源" 选项和 "Azure 管道生成映像" 选项。

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

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

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

  • 对于 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 模板部署任务中筛选服务连接。 如果选择较低的作用域服务连接来执行更广泛的作用域,这可能会导致部署失败。 现在,我们添加了对服务连接的筛选,以根据所选的部署范围筛选出更低范围的服务连接。

环境中的 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 门户的部署策略

利用此功能,我们使你可以更轻松地配置使用所选部署策略的 管道,例如****滚动、未线或 蓝绿色。 使用这些现成的策略,你可以安全地推出更新,并缓解相关的部署风险。 若要访问此项,请在 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 管道的存储库之外,还可以提取和签出其他存储库。

例如,如果你有一个包含 YAML 管道的名为 MyCode 的存储库和另一个称为 " 工具"的存储库,则 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集合,并且具有可以访问另一个项目中的存储库的凭据。 repos 和 self otherrepo 最终都会签出。

重要

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

突出显示了"Project 设置/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 保持不变。 Kustomize 选项已添加到 KubernetesManifest 任务的烘培操作下,因此,包含 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 任务使用群集用户凭据进行部署。 这导致基于 RBAC 的群集的交互式登录提示Azure Active Directory管道失败。 为了解决此问题,我们添加了一个复选框,允许使用群集管理员凭据而不是群集用户凭据。

"打包和部署 Helm 图表"的屏幕截图,其中显示了"使用群集管理员凭据"复选框。

任务中的Docker Compose输入

在任务中引入了一Docker Compose字段,以允许添加参数(如 --no-cache )。 运行生成等命令时,任务将向下传递 参数。

显示新Docker Compose"文本框的"参数"任务的屏幕截图。

GitHub发布任务增强功能

我们对"发布"任务进行了GitHub增强功能。 现在,通过指定标记正则表达式,可以更好地控制使用标记模式字段的发布创建,并且只有在使用匹配字符串标记触发提交时,才创建发布。

屏幕截图显示了GitHub发布任务,其中已调用"任务版本"和"标记模式"部分。

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

屏幕截图显示了GitHub任务,其中突出显示了"与"和"更改日志类型"部分。

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

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

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

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

支持任务中的 PowerShell Azure CLI脚本

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

任务屏幕截图Azure CLI Powershell 和 Powershell Core 是"脚本类型"下拉列表中的选项。

KubernetesManifest 任务中基于服务网格接口的 Canary 部署

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

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

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

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

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

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

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

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

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

  • 源的文件名/路径中的通配符符号
  • 在未提供参数的情况下,根据文件扩展名推断内容类型
  • 通过传递参数定义日志文件的日志详细程度

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

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

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

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

    备注

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

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

  • 限制生成服务 repos 范围访问

    在通过限制访问令牌范围提高管道安全性的基础上,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组管理服务连接安全性。

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

显示服务连接的基于角色的访问的屏幕截图。

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

服务连接的跨项目共享

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

显示服务连接的跨项目共享的屏幕截图。

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

管道和 ACR 资源的可跟踪性

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

在管道运行摘要视图中,可以看到:

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

    显示管道已自动触发的屏幕截图。

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

    显示"当前管道"部分中的提交的屏幕截图。

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

  • 可供 运行使用的项目。

    显示管道Artifacts页的屏幕截图。

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

"按部署"部分屏幕截图,其中显示了"Workitems"选项卡。

支持大型测试附件

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

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

显示日志中返回的 403 错误的屏幕截图。

若要解决此问题,建议将出站请求 的防火墙更新为 https://*.vstmrblob.vsassets.io 。 您可以在 此处的文档中找到疑难解答信息。

备注

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

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

以前,当您使用矩阵展开作业或变量来标识池时,有时会在日志页中解析错误的池信息。 已解决了这些问题。

新分支的 CI 触发器

创建新的分支时,如果创建了一个新的分支,但该分支没有发生更改,则该请求将是一个长时间挂起的请求。 请开考虑以下示例:

  • 使用 web 接口可基于现有分支创建新分支。 如果分支筛选器与新分支的名称匹配,则会立即触发新的 CI 生成。 这是不需要的,因为在与现有分支进行比较时,新分支的内容是相同的。
  • 你有一个包含两个文件夹的存储库-应用和文档。为 CI 设置路径筛选器以匹配 "app"。 换言之,如果已将更改推送到文档,则不希望创建新的生成。你可以在本地创建一个新分支,对文档进行一些更改,然后将该分支推送到服务器。 用于触发新的 CI 生成。 这是不需要的,因为你显式要求不要查找文档文件夹中的更改。 不过,由于我们处理了一个新的分支事件,因此看起来就像更改了应用文件夹一样。

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

作业可以从前面几个阶段访问输出变量

现在,可以在基于 YAML 的管道中的各个阶段使用输出变量。 这可帮助你将有用的信息(例如,开始/不走向决策或生成的输出的 ID)传递到下一个阶段。 此外,还提供了前一阶段的结果 (状态) 。

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

备注

默认情况下,管道中的每个阶段都依赖于在 YAML 文件中的每个阶段。 因此,每个阶段都可以使用前一阶段的输出变量。 您可以更改依赖项关系图,该关系图还会改变可用的输出变量。 例如,如果第3阶段需要第1阶段的变量,则需要在阶段1声明显式依赖项。

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

目前,管道代理会在需要时自动更新到最新版本。 出现这种情况时,通常会出现一项新功能或任务,要求更新的代理版本才能正常工作。 在此更新中,我们添加了在池级别禁用自动升级功能。 在此模式下,如果没有正确版本的代理连接到池,则管道将失败并出现一条清晰的错误消息,而不是请求代理进行更新。 此功能主要用于具有自承载池的客户和非常严格的更改控制要求。 默认情况下启用自动更新,不建议大多数客户禁用它们。

默认设置页的 Sceenshot,其中启用了 "代理更新设置" 选项并将其调用。

代理诊断

我们为许多常见代理相关问题添加了诊断,例如许多网络问题和升级失败的常见原因。 若要开始使用诊断,请使用 run.sh (诊断运行) Windows 上的诊断。

YAML 管道的服务挂钩

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

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

新服务挂钩订阅向导的屏幕截图,其中显示了此类型的事件下拉列表上包含 "运行阶段" 选项的触发器。

Optimizely 集成

Optimizely 是一个功能强大的 A/B 测试和功能标记平台,适用于产品团队。 将 Azure Pipelines 与 Optimizely 试验平台集成使产品团队能够以更快的速度测试、学习和部署,同时从 Azure Pipelines 获取所有 DevOps 权益。

Azure DevOps 的 Optimizely 扩展将试验和功能标志推出步骤添加到生成和发布管道,以便您可以使用 Azure Pipelines 连续循环访问、滚动功能并将其回滚。

此处了解 Azure DevOps Optimizely 扩展的详细信息。

Optimizely

添加 GitHub 版本作为项目源

现在,你可以将 GitHub 版本作为项目源链接到 Azure DevOps 版本管道中。 这将允许你在部署过程中使用 GitHub 版本。

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

"添加项目" 对话框的屏幕截图,其中已选择 "GitHub 发布" 选项并调用。

Terraform 与 Azure Pipelines 的集成

Terraform 是一种开源工具,用于安全有效地开发、更改和版本化基础结构。 Terraform 整理 Api 转换为声明性配置文件,使你能够使用高级配置语言定义和预配基础结构。 可以使用 Terraform 扩展跨所有主要基础结构提供程序创建资源: Azure、Amazon Web Services (AWS) 和 Google Cloud Platform (GCP) 。

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

Terraform 与 Azure Pipelines 的集成的屏幕截图。

与 Google Analytics 的集成

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

适用于 Azure DevOps 的 Google Analytics 试验扩展增加了生成和发布管道的试验步骤,因此,你可以在更快的时间内定期管理试验,同时以更快的速度进行循环访问、学习和部署,同时从 Azure Pipelines 获取所有 DevOps 权益。

你可以从 Marketplace 下载 Google Analytics 试验扩展

显示 Google Analytics 试验任务的屏幕截图。

已更新 ServiceNow 与 Azure Pipelines 的集成

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

从 VSCode 创建 Azure Pipelines

我们向 VSCode 的 Azure Pipelines 扩展添加了一种新功能。 现在,可以直接从 VSCode 创建 Azure Pipelines,而无需离开 IDE。

在右下角带有警报的 VS Code 屏幕截图显示:已成功设置管道。

不可靠 bug 管理和解决

我们引入了不可靠测试管理,支持检测、报告和解决的端到端生命周期。 为了进一步增强,我们添加了不可靠测试 bug 管理和解决方法。

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

解决或关闭 bug 报告时,将自动取消标记为 "unflaky" 的测试。

如果未运行最小数量的测试,请将 Vstest.console.exe 任务设置为失败

Vstest.console.exe 任务发现并使用用户输入 (测试文件、筛选条件等) ,以及特定于所使用的测试框架的测试适配器来运行测试。 对用户输入或测试适配器进行更改时,可能会出现以下情况:未发现测试,且仅运行了预期测试的一个子集。 这可能会导致管道成功,因为将跳过测试,而不是由于代码的质量较高而导致的。 为了帮助避免这种情况,我们在 Vstest.console.exe 任务中添加了一个新选项,该选项允许你指定要通过的任务必须运行的最小测试数。

显示 "未运行的测试数最少" 选项的屏幕截图。

Vstest.console.exe TestResultsDirectory 选项可在任务 UI 中使用

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

显示"测试结果文件夹"文本框的屏幕截图。

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

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

显示自动测试错误消息中的 Markdown 支持的屏幕截图。

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

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

此外,部署作业可以作为容器作业以及服务并行运行(如果已定义)。

Test Plans

"新建测试计划"页

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

屏幕截图显示了两个共享后端存储的名为 的、名为 的测试计划。

帮助我了解新页面

测试计划概述页

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

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

下面介绍这些新部分的广泛笔划视图。

1.测试计划标头

测试计划标头页

任务

使用"测试计划"标头可以执行以下任务:

  • 将测试计划标记为收藏
  • 取消标记收藏的测试计划
  • 轻松地在喜欢的测试计划之间导航
  • 查看测试计划的迭代路径,该路径清楚地指示测试计划是"当前"还是"过去"
  • 使用导航到报表的链接查看测试进度报表的快速摘要
  • 导航回"全部/Test Plans页

上下文菜单选项

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

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

复制测试计划 (新功能)

复制测试计划页

建议根据冲刺 /发布创建新的测试计划。 执行此操作时,通常可以复制上一周期的测试计划,并且复制的测试计划已做好新周期准备的一些更改。 为了方便此过程,我们在新页上启用了"复制测试计划"功能。 利用它,可以复制或克隆测试计划。 此处介绍了REST API支持 功能 ,API 还允许跨项目复制/克隆测试计划。
有关使用Test Plans指南,请参阅此处

2.测试套件树

测试套件树页

任务

使用 Test suite 标头可以执行以下任务:

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

上下文菜单选项

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

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

3.定义选项卡

定义选项卡页

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

"定义"选项卡和某些操作仅适用于具有基本+ Test Plans访问级别或等效项的用户。 具有"基本"访问级别的用户应可管理其他所有内容。

任务

使用"定义"选项卡可以执行以下任务:

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

上下文菜单选项

定义选项卡上下文菜单页

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

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

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

"定义选项卡复制测试用例" 页

对于要复制/克隆测试用例的情况,可以使用 "复制测试用例" 选项。 您可以指定要在其中创建复制/克隆的测试用例的目标项目、目标测试计划和目标测试套件。 此外,还可以指定是否要包含流入克隆副本的现有链接/附件。

查看链接项 (新功能)

"定义选项卡视图链接项" 页

测试项目、要求和 bug 间的可追溯性是 Test Plans 产品的关键价值主张。 使用 "查看链接项" 选项,您可以轻松查看与此测试用例关联的所有链接要求、使用此测试用例的所有测试套件/测试计划,以及已在测试执行过程中归档的所有 bug。

4. 执行选项卡

"执行" 选项卡页

"定义" 选项卡允许您对测试套件的测试用例进行排序、添加和管理。 而 "执行" 选项卡用于分配测试点并执行。

什么是测试点? 测试用例本身不是可执行文件。 向测试套件添加测试用例后,将生成) (的测试点。 测试点是测试用例、测试套件、配置和测试人员的唯一组合。 示例:如果将测试用例设置为 "测试登录功能",并将两个配置作为 Edge 和 Chrome 添加到该测试用例,则会产生2个测试点。 现在可以执行这些测试点。 执行时,将生成测试结果。 通过测试结果视图 (执行历史记录) 你可以查看测试点的所有执行。 测试点的最新执行是您在 "执行" 选项卡中看到的内容。
因此,测试用例是可重复使用的实体。 通过将它们包含在测试计划或套件中,将生成测试点。 通过执行测试点,可以确定要开发的产品或服务的质量。

新页的一个主要优点是,用户经常执行测试执行/跟踪 (只需具有 "基本" 访问级别) ,套件管理的复杂性不会失控 ("定义" 选项卡对于此类用户) 是隐藏的。

"定义" 选项卡和某些操作仅适用于具有 "基本" 和 " Test Plans " 访问级别或等效项的用户。 所有其他操作(包括 "执行" 选项卡)应由具有 "基本" 访问级别的用户 exercisable。

任务

"执行" 选项卡允许您执行以下任务:

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

上下文菜单选项

"执行" 选项卡上下文菜单页

"执行" 选项卡中 "测试点" 节点上的上下文菜单提供以下选项:

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

Test Plans进度报告

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

"进度报告" 选项突出显示的 "Test Plans" 部分的屏幕截图。

报表的三个部分包括:

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

进度报表的屏幕截图。

Artifacts

备注

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

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

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

newtonsoft.json NuGet 包的屏幕截图,其中包含一个指向包许可证的红色箭头。

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

Dispalying MIT 许可文本的浏览器窗口的屏幕截图

轻型身份验证任务

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

轻型身份验证任务示例的屏幕截图。

此图中的 "ci" 和 "发布" 命令的使用是任意的,你可以使用 Azure Pipelines YAML 支持的任何命令。 这使您能够完全控制命令调用,并使您能够轻松地在管道配置中使用共享脚本。 有关详细信息,请参阅NuGetnpmPIPTwineMaven authentication 任务文档。

对源页面加载时间的改进

我们很高兴地宣布,我们改进了源页面加载时间。 平均情况下,源页面加载时间已减少10%。 最大的源已发现,99% 百分位源页面加载时间在所有源的最高99% 中 (加载时间,) 降低75%。

通过公共源公开共享包

你现在可以创建包并将其存储在公共源内。 存储在公共源中的包可供 internet 上的所有人使用,无论它们是在你的集合中还是登录到 Azure DevOps 集合中。 在我们的 源文档 中详细了解公共源,或直接转到本 教程公开共享包的教程

显示包的 "PublicFeed" 页的屏幕截图。

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

现在可以将源添加到与租户关联的另一个Azure Active Directory (AAD) 作为上游源添加到Artifacts源。 源可以从配置为上游源的源中查找和使用包,从而轻松地跨与源租户关联的集合AAD包。 请参阅文档 中的设置

使用Python Credential Provider对 pip 进行身份验证,并使用源Azure Artifacts孪生

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

Azure Artifacts源Visual Studio 程序包管理器

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

更新连接源体验

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

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

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

从门户创建项目范围的源

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

npm 性能改进

我们对核心设计进行了更改,以改进在源中存储和传送 npm Azure Artifacts的方式。 这帮助我们将 npm 的一些最高已用 API 的延迟降低多达 10 倍。

辅助功能改进

我们部署了修补程序来解决源页上的辅助功能问题。 这些修复包括:

  • 创建源体验
  • 全局源设置体验
  • 连接源体验

Wiki

代码 wiki 页面的丰富编辑

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

现在,可以在 wiki 内的并行编辑器中编辑代码 wiki 页。 这样,即可使用丰富的 Markdown 工具栏创建内容,使编辑体验与项目 wiki 中的编辑体验相同。 仍可选择在 repos 中编辑,方法为在上下文菜单中选择"Repos编辑"选项。

显示"编辑"菜单的屏幕截图,其中Repos"编辑"选项。

从 Wiki 页创建和嵌入工作项

当我们倾听你的反馈时,我们听到你使用 wiki 来捕获集体讨论文档、规划文档、关于功能的想法、规范文档、会议分钟数。 现在,无需离开 wiki 页面,即可直接从计划文档轻松创建功能和用户情景。

若要创建工作项,请在要嵌入工作项的 wiki 页中选择文本,然后选择"新建工作项"。 这可节省时间,因为无需先创建工作项,请转到编辑,然后找到要嵌入的工作项。 它还减少了上下文切换,因为不会超出 wiki 范围。

显示如何从 Wiki 页创建和嵌入工作项的简短视频。

若要详细了解如何从 wiki 创建和嵌入工作项,请参阅此处 的文档

Wiki 页面中的注释

以前,你无法与 Wiki 内的其他 Wiki 用户进行交互。 这使得协作处理内容并回答问题是一项挑战,因为对话必须通过邮件或聊天通道进行。 通过注释,现在可以直接在 Wiki 中与他人协作。 可以利用注释 @mention 中的用户功能来吸引其他团队成员的注意。 此功能已根据此建议票证 设置优先级。 有关注释的更多内容,请参阅此处 的文档

显示如何在 wiki 页上添加注释的屏幕截图。

隐藏以""开始的文件夹和文件。 在 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}

这是欢迎使用 Wiki 页面的新 URL Azure DevOps 示例:

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

这是根据开发人员团队的此功能建议票证Community。

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

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

Wiki 工具栏的屏幕截图,其中已调用同步滚动图标,其上方有"禁用同步滚动"切换按钮。

备注

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

Wiki 页面的页面访问次数

现在可以深入了解 Wiki 页面的页面访问次数。 通过REST API,可以访问过去 30 天内的页面访问信息。 可以使用此数据为 Wiki 页面创建报表。 此外,可以将此数据存储在数据源中,并创建仪表板,获取特定见解,例如查看最多的前 n 页

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

显示 Wiki 页面以前访问次数的屏幕截图。

备注

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

报表

管道故障和持续时间报告

指标和见解可帮助你持续提高管道的吞吐量和稳定性。 我们添加了两个新报表,用于提供有关管道的见解。

  1. 管道失败报表显示生成通过率和失败趋势。 此外,它还将显示任务失败趋势,以提供有关管道中哪个任务导致最大失败次数的见解。

显示"分析"选项卡的屏幕截图,其中显示了"管道通过率"徽章、"测试通过率"徽章和"管道持续时间"徽章。

显示"管道失败"报告的屏幕截图。

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

查询结果小组件改进

查询 结果小 组件是我们最常用的小组件之一,这是有原因的。 小组件直接在仪表板上显示查询结果,在许多情况下非常有用。

在此更新中,我们包含了许多等待等待的改进:

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

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

团队使用 潜在顾客和周期时间来查看工作通过其开发管道流动,并最终为客户提供价值所花的时间。

到目前为止,潜在顾客 周期时间小组件不支持高级筛选条件来提问以下问题:"我的团队需要多久才能关闭优先级较高的项目?"

使用此更新时,可以通过筛选棋盘泳道来回答类似这样的问题。

显示"配置"对话框的屏幕截图,其中已调用"泳道"部分。

我们还包括了工作项筛选器,以限制显示在图表中的工作项。

显示"配置"对话框的屏幕截图,其中标出了"字段条件"部分。

使用情景点进行内联冲刺冲刺 (内联冲刺 )燃尽

冲刺 (冲刺 )的燃尽现在可以通过情景进行燃尽。 这解决了开发人员团队的反馈Community。

从冲刺 (冲刺 )中心选择"分析"选项卡。然后配置报表,如下所示:

  1. 选择情景积压工作
  2. 选择""以在" 情景点之和"上进行倒计时

屏幕截图显示了使用情景点进行内联冲刺冲刺 (内联冲刺 )的燃尽。

冲刺 (冲刺 )"倒计时"小组件,提供你一直在要求的所有内容

新的冲刺 (冲刺 )倒计时小组件支持按情景点、任务计数或对自定义字段求和来减少。 甚至可以为"功能"或"长篇故事"创建冲刺冲刺 (sprint)燃尽。 小组件显示平均燃尽、完成百分比和范围增加。 可以配置团队,使你可以在同一仪表板上显示多个团队的冲刺冲刺 (冲刺 )倒计时。 通过显示所有这些出色的信息,我们可让你在仪表板上重设大小,大小高达 10x10。

显示新的冲刺 (冲刺 )燃尽小组件的结果。

若要试用,可以从小组件目录添加它,或者编辑现有冲刺 (冲刺 )燃尽小组件的配置并选中"立即试用新版本 "框

备注

新小组件使用 Analytics。 我们保留了旧的冲刺 (Sprint)燃尽功能,以防你无法访问 Analytics。

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

冲刺 (冲刺 )倒计时已恢复! 数个冲刺 (冲刺 )之前,我们删除了冲刺 (冲刺 )的冲刺 (冲刺 )燃尽和任务板标头中的上下文内冲刺 (sprint)燃尽。 根据你的反馈,我们改进了冲刺 (冲刺 )燃尽缩略图并重放了该缩略图。

显示内联冲刺 (冲刺 )燃尽缩略图的屏幕截图。

单击缩略图会立即显示较大版本的图表,并可选择在"分析"选项卡下查看完整报表。对完整报表进行的任何更改都将反映在标题中显示的图表中。 因此,现在可以将其配置为基于情景、情景点或任务计数进行倒计时,而不只是剩余工作量。

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

现在可以创建仪表板,而无需将其与团队相关联。 创建仪表板时,选择Project 仪表板 类型。

显示"创建仪表板"对话框的屏幕截图,其中Project"仪表板"选项并调用。

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

所有Azure DevOps团队上下文的所有小组件已更新,让你能够选择其配置中的团队。 可以将这些小组件添加到Project仪表板,并选择想要的特定团队。

"团队"下拉列表的屏幕截图。

备注

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


反馈

我们期待你的宝贵意见和建议! 可以报告问题或提供想法并通过开发人员团队进行跟踪Community获取有关问题Stack Overflow。


返回首页