Azure DevOps Server 2019 发行说明

  • 项目

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

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

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

注意

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

安装修补程序

重要

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

配置 TFX

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

使用 TFX 更新任务

文件 SHA-256 哈希
Tasks20231103.zip 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5
  1. 下载并提取 Tasks20231103.zip。
  2. 将目录更改为提取的文件。
  3. 执行以下命令上传任务：
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip

管道要求

若要使用新行为，必须在使用受影响任务的管道中设置变量 AZP_75787_ENABLE_NEW_LOGIC = true 。

  • 在经典上：

    在管道的变量选项卡中定义变量。

  • YAML 示例：

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true

Azure DevOps Server 2019.0.1 修补程序 15 发布日期：2023 年 9 月 12 日

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

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

重要

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

注意

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

安装修补程序

  1. 下载并安装 Azure DevOps Server 2019.0.1 修补程序 15。

更新 Azure Pipelines 代理

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

注意

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

配置 TFX

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

使用 TFX 更新任务

  1. 下载并提取 Tasks_20230825.zip。
  2. 将目录更改为提取的文件。
  3. 执行以下命令上传任务：
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip

管道要求

若要使用新行为，必须在使用受影响任务的管道中设置变量 AZP_75787_ENABLE_NEW_LOGIC = true 。

  • 在经典上：

    在管道的变量选项卡中定义变量。

  • YAML 示例：

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true

Azure DevOps Server 2019.0.1 修补程序 14 发布日期：2022 年 8 月 8 日

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

Azure DevOps Server 2019.0.1 修补程序 13 发布日期：2022 年 5 月 17 日

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

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

Azure DevOps Server 2019.0.1 补丁 12 发布日期：2022 年 1 月 26 日

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

  • 通过从 log4j 二进制文件中删除 jndilookup 类来解决 Elasticsearch 漏洞。

安装步骤

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

注意

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

  1. 使用 修补程序 12 升级服务器。
  2. 检查 HKLM:\Software\Elasticsearch\Version 的注册表值。 如果注册表值不存在，请添加一个字符串值，并将版本设置为 5.4.1 (Name = Version, Value = 5.4.1)。
  3. 将名为 zip 且位于 C:\Program Files\{TFS Version Folder}\Search\zip 中的文件夹的内容复制到 Elasticsearch 远程文件文件夹。
  4. 在 Elasticsearch 服务器计算机上运行 Configure-TFSSearch.ps1 -Operation update。

SHA-256 哈希： 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Azure DevOps Server 2019.0.1 补丁 11 发布日期：2021 年 8 月 10 日

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

  • 修复生成定义 UI 错误。

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

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

若要应用修补程序 10，必须安装任务 AzureResourceGroupDeploymentV2 。

AzureResourceGroupDeploymentV2 任务安装

注意

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

安装

  1. 将 AzureResourceGroupDeploymentV2.zip 包提取到计算机上的新文件夹。 例如： 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>*

Azure DevOps Server 2019.0.1 补丁 9 发布日期：2020 年 12 月 8 日

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

  • CVE-2020-1325：Azure DevOps Server欺骗漏洞
  • CVE-2020-17135：Azure DevOps Server欺骗漏洞
  • CVE-2020-17145 ：Azure DevOps Server 和 Team Foundation Server 欺骗漏洞
  • 修复了 TFVC 未处理所有结果的问题

重要

在安装此修补程序之前，请阅读下面提供的完整说明。

常规修补程序安装

如果Azure DevOps Server 2019.0.1，则应安装 Azure DevOps Server 2019.0.1 补丁 9。

验证安装

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

  • 选项 2：检查以下文件的版本： [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll。 默认情况下，Azure DevOps Server 2019 安装到 c:\Program Files\Azure DevOps Server 2019 。 安装 Azure DevOps Server 2019.0.1 修补程序 9 后，版本将为 17.143.30723.4 。

AzurePowerShellV4 任务安装

注意

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

先决条件

  1. 在专用代理计算机上安装Azure PowerShell Az 模块 Azure Powershell。

  2. 使用 AzurePowerShellV4 任务创建管道。 任务中只会看到一个 “标准错误失败 ”。

安装

  1. 将 AzurePowerShellV4.zip 包提取到名为 AzurePowerShellV4 的文件夹。

  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. 运行以下命令，将任务上传到服务器。 提取的包的路径为 D：\tasks (1) \AzurePowerShellv4。
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019.0.1 补丁 8 发布日期：2020 年 9 月 8 日

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

  • DTS 1713492 - 向安全权限添加 AD 组时出现意外行为。

Azure DevOps Server 2019.0.1 补丁 7 发布日期：2020 年 7 月 14 日

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

  • CVE-2020-1326：跨站点脚本漏洞
  • 选择“其他 Git 源”时，生成管道显示未经授权的用户连接不正确。
  • 修复了在 XAML 生成定义中将“继承”更改为“打开”或“关闭”时的错误。

Azure DevOps Server 2019.0.1 修补程序 6 发布日期：2020 年 6 月 10 日

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

  • CVE-2020-1327：确保Azure DevOps Server清理用户输入
  • 在 Azure DevOps 上的 SSH 中添加对 SHA2 的支持

Azure DevOps Server 2019.0.1 补丁 5 发布日期：2020 年 3 月 10 日

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

Azure DevOps Server 2019.0.1 补丁 3 发布日期：2019 年 9 月 10 日

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

Azure DevOps Server 2019.0.1 补丁 2 发布日期：2019 年 8 月 13 日

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

  • 我们向服务连接添加了信息，以阐明默认情况下，它们已授权用于所有管道。

Azure DevOps Server 2019.0.1 补丁 1 发布日期：2019 年 7 月 9 日

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

  • CVE-2019-1072 ：工作项跟踪中的远程代码执行漏洞
  • CVE-2019-1076 ：拉取请求中跨站点脚本编制 (XSS) 漏洞

Azure DevOps Server 2019.0.1 发布日期：2019 年 5 月 21 日

Azure DevOps Server 2019.0.1 是 bug 修复汇总。 它包括以前发布的 Azure DevOps Server 2019 修补程序中的所有修补程序。 可以直接安装 Azure DevOps Server 2019.0.1，也可以从 Azure DevOps Server 2019 或 Team Foundation Server 2012 或更高版本升级。

注意

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

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

Azure Boards

  • 配置计划时，“此计划的字段条件有错误。” 通过 开发者社区 报告。
  • 当查询多次具有相同列时，apiwitcontroller.executequery 会引发异常。
  • 在使用 vso.work_full oauth 作用域的客户端对象模型中，WorkItemServer.DownloadFile () 失败。
  • 将嵌入图像从工作项字段复制到另一个项目中的另一个工作项字段可能会造成图像损坏。

Azure Repos

  • “TF401019：GitRepositoryNotFoundException”。

Azure Pipelines

  • “测试分析”选项卡具有star (*) ，指示预览，即使此功能不是预览版。
  • 在“ 发布 ”选项卡上，管理安全性的操作现在向所有用户显示，无论他们是否可以更改权限。
  • 在“发布”登陆页上，“开始草稿发布”操作正在创建新版本，但现在开始草稿发布。

Azure Test Plans

  • TestRuns 和 TestResults CompletedDate 上的 1 小时筛选器太精细。
  • 在 “测试用例 ”工作项类型中，不应本地化类型“测试用例”。
  • 测试用例不会显示在 MTM 或浏览器中。
  • 从测试计划运行自动测试时，出现“验证阶段：你无权在关联的发布管道上触发发布”错误。 通过 开发者社区 报告。
  • 使用 删除测试用例 API，可以从其他项目中删除测试用例。 通过 开发者社区 报告。
  • 单击测试运行程序中的工作项链接将打开测试运行程序内的工作项 URL，而不是默认浏览器。
  • 对于注销测试运行程序的用户，测试用例状态不会更新。
  • 用户名和电子邮件地址不会显示在测试运行程序的用户下拉列表中。

Azure Artifacts

  • 上移 和 下移 未在上游本地化。

Analytics

  • 分析报告可能会显示不完整的数据，因为模型在实际完成之前被标记为“就绪”。
  • 速度、进度和烧毁小组件为不同时区的用户显示不同的计划工时。
  • 在执行维护时，可能会暂停分析数据引入，这可能会导致报表过时。

常规

  • 当没有足够的空间时，左侧导航项在 IE 上被挤压。

管理

  • 添加到集合升级的其他日志记录以帮助调试问题。
  • 当 TfsConfig offlineDetach 失败时，错误消息不可操作。
  • TfsJobAgent 服务崩溃。
  • 配置完成后，不会安装搜索扩展。
  • 配置 DB 损坏时，管理控制台将无响应。
  • 服务挂钩可能无法正确处理通知。
  • 配置搜索后，代码搜索索引不会启动。
  • 搜索结果中存在未本地化的字符串。

此版本包括以下更新：

Visual Studio 测试任务中对 Visual Studio 2019 (VS2019) 的支持

我们已在管道中的 Visual Studio 测试任务中添加了对 Visual Studio 2019 的支持。 若要使用 Visual Studio 2019 的测试平台运行测试，请从“测试平台版本”下拉列表中选择 “最新 ”或“ Visual Studio 2019 ”选项。

“执行选项”部分的屏幕截图，其中显示了“测试平台版本”下拉列表，其中选择了“最新 Visual Studio 2019”选项。

Azure DevOps Server 2019 补丁 2 发布日期：2019 年 5 月 14 日

我们发布了 Azure DevOps Server 2019 的安全修补程序，用于修复以下 bug。 有关详细信息，请参阅博客文章。

Azure DevOps Server 2019 修补程序 1 发布日期：2019 年 4 月 9 日

我们发布了 Azure DevOps Server 2019 的安全修补程序，用于修复以下 bug。 有关详细信息，请参阅博客文章。

Azure DevOps Server 2019 发布日期：2019 年 3 月 5 日

注意

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

RC2 发布日期：2019 年 1 月 22 日

Azure DevOps Server 2019 RC2 中的新增功能摘要

我们已将以下功能添加到 RC2：

RC1 发布日期：2018 年 11 月 19 日

Azure DevOps Server 2019 RC1 中的新增功能摘要

Azure DevOps Server 2019 引入了新的导航体验和许多新功能。 其中一些要点包括：

还可以跳转到各个部分以查看新功能：

常规

宣布推出 Azure DevOps Server

在 9 月 10 日，我们宣布推出 Azure DevOps 作为 Visual Studio Team Services 和 Team Foundation Server 的演变。 Azure DevOps Server 2019 是我们第一个使用此新品牌的本地版本。 可以在我们的博客文章中找到详细信息。

新的导航体验

我们引入了新的导航来实现用户体验现代化。 此新的导航已向 Azure DevOps 服务推出，现在可在 Azure DevOps Server 2019 中可用。 有关详细信息 ，请参阅我们的博客 。

新导航

项目和Release Management部署管道许可的更改

根据用户反馈，我们将对 2019 Azure DevOps Server 许可证进行两项关键更改。 首先，客户不再需要购买项目扩展来使用项目。 项目许可证的使用现在将包含在基本许可证中。 分配有基本许可证的所有用户现在都可以使用项目。 其次，客户不再需要购买Release Management部署管道。 与生成管道一样，Release Management部署管道现在包含在 Azure DevOps Server 2019 中。

Azure SQL 数据库支持

为了简化在 Azure 中运行 Azure DevOps 2019 的体验，我们实现了 Azure SQL 数据库（常规用途 S3 及更高版本）支持。 这样，就可以利用广泛的备份功能和缩放选项来满足需求，同时减少运行服务的管理开销。 请注意，主机 VM 必须位于数据库所在的同一 Azure 区域中才能使延迟较低。 有关详细信息，请参阅文档。

未来版本中的工作项 & 测试客户端对象模型 SOAP API

Azure DevOps Server 2019 年继续支持工作项跟踪 SOAP API 和客户端对象模型。 但是，它将在将来的 Azure DevOps Server 版本中标记为已弃用。 可以在我们的文档中找到详细信息。

新集合上的进程继承

新集合上现在提供进程继承。 用户需要在创建新集合时确定进程模型。 请参阅 我们的文档 ，了解继承模型是什么以及它与 XML 有何不同。

进程继承

我们了解搜索的重要性，在产品标头上恢复了展开的搜索框。 此外，现在只需在 Azure DevOps 中的任何服务页面上单击“/”，便可以调用搜索框。

下面是默认搜索框：

默认搜索框

输入“/”之后，便会看到展开的搜索框：

展开的搜索框

我的工作浮出控件

我们非常高兴引入的一个新功能是我的工作浮出控件。 我们收到反馈，当用户处于产品的一个部分中，并且希望从另一个部分获得一些信息时，不想失去上下文。 借助这一新功能，可以从产品中的任何位置访问此浮出控件，通过它可以快速浏览重要信息，包括工作项、拉取请求和所有收藏夹。 使用这一新的浮出控件，如果你在存储库埋头编写代码，但是随后要快速检查接下来应处理的工作项，则只需单击此浮出控件，便可查看分配给你的工作项并选取下一项。

在下面可以看到我的工作浮出控件，其中显示分配给我的工作项：

我的工作浮出控件

在此处可以看到第二个透视，它显示分配给我的 PR。 在该浮出控件中，还可通过一次单击访问来查看更多拉取请求：

我的工作浮出控件 PR

在此处可以看到最后一个透视，这是所收藏的所有内容。 这包括收藏的团队、仪表板、板、积压工作 (backlog)、查询和存储库：

我的工作浮出控件收藏夹

Boards

将 GitHub Enterprise 用于代码并且需要丰富项目管理功能的团队现在可以将其存储库与 Azure Boards 集成。 通过连接 GitHub 和Azure Boards，可以获得积压工作、开发板、冲刺计划工具、多个工作项类型等所有功能，并且仍具有与 GitHub 中的开发人员工作流集成的工作流。

可轻松地将提交和拉取请求链接到工作项。 使用以下语法提及工作项：

AB#{work item ID}

在提交消息、拉取请求标题或拉取请求说明中提及工作项，Azure Boards 会创建该项目的链接。 例如，请考虑提交消息如下所示：

Adds support for deleting connections. Fixes AB#20.

这会创建从工作项 #20 到 GitHub 中的提交的链接，该链接会出现在工作项的“开发”部分中。 ​

Azure DevOps 的屏幕截图，其中调出了“开发”部分。

如果字词“fix”、“fixes”或“fixed”在提及工作项之前出现（如上所示），则当提交合并到默认分支时，工作项会转变为已完成状态。

使用 Azure Pipelines 在 GitHub 中生成代码的团队还会在生成摘要中看到链接到其 GitHub 提交的工作项。

新的工作项中心

工作项中心是用于容纳工作项的新中心！ 在此处你可获得为你缩小了范围的许多不同的工作项列表视图。 可以查看分配到我以快速浏览分配给你的所有工作，或是向你显示项目中最近更新的所有工作项的最近更新。 可以在下面看到所有列表选项：

工作项中心

如果甚至要进一步缩小列表范围，则能够对类型、分配对象、状态、区域、标记和关键字进行筛选。 获得所需列表视图之后，随后只需单击列标题，便可以对工作项进行排序。 如果某列太窄，无法该列的完整内容，则可以在标题区域中轻松调整该列大小。 可以在下面看到这些体验：

工作项中心列表

新的板、积压工作 (backlog) 和冲刺 (sprint) 中心

积压工作 (backlog) 中心划分为三个不同的中心，以改进用户体验。 尽管功能强大，不过旧的积压工作 (backlog) 中心容纳了太多功能。 这样通常难以找到用户寻求的特性或功能。 为了解决此问题，我们将积压工作 (backlog) 中心拆分为：

  • 积压工作 (backlog) 中心现在仅容纳项目的积压工作 (backlog)。 积压工作 (backlog) 是设置了优先级的团队工作列表。 积压工作 (backlog) 提供了计划工具，如工作项层次结构、预测和新的冲刺 (sprint) 计划体验。
  • 新的板中心容纳项目的所有看板。 板用于传达状态和流。 卡（工作项）通过团队定义的列，在板中从左到右移动。
  • 新的冲刺 (sprint) 中心容纳用于计划和执行工作增量的功能。 每个冲刺 (sprint) 包含一个冲刺 (sprint) 积压工作 (backlog)、一个任务板以及一个用于为团队管理和设置容量的视图。

Boards 中心

新的查询中心

新的查询中心使用更现代的外观简化了旧中心的许多现有查询功能，并提供新功能以便更方便地获得对你十分重要的查询。 新体验的一些亮点包括：

  • 具有上次修改者信息和查询搜索功能的目录页面
  • 具有用于向重要查询组添加书签的唯一文件夹 URL 的痕迹导航
  • 从结果页面对收藏夹查询进行的快速访问

在我们的 DevOps 博客上详细了解这些令人兴奋的更新。

将工作项移动到另一个项目并更改工作项类型

现在可以 更改工作项类型 或 将工作项移动到 项目集合中的另一个项目。 这些功能需要禁用数据仓库。 在禁用了数据仓库的情况下，可以使用 Analytics Service 为报告需求提供支持。 若要详细了解如何禁用数据仓库，请参阅禁用数据仓库和多维数据集。

冲刺 (sprint) 计划功能

新的冲刺 (sprint) 计划功能可帮助加快并改进冲刺 (sprint) 计划体验。

  • 直接从 Sprints 中心创建下一个冲刺或订阅现有的冲刺计划。
  • 使用积压工作 (backlog) 中新的计划窗格将工作项拖放到将来的冲刺 (sprint) 中。 计划窗格包括冲刺 (sprint) 日期、工作项计数和计划工作量。
  • 将要求添加到任务板顶部或使用快速创建添加到冲刺 (sprint) 积压工作 (backlog) 的顶部、底部或所选行。
  • 对被分派人、工作项类型、状态和标记使用筛选器以按照需求定制视图。

冲刺 (sprint) 规划

新的目录页面

所有新的中心（包括积压工作 (backlog)、板和冲刺 (sprint)）现在具有使用以下部分进行组织的新目录页面：

  • 从离开的位置继续 这一新部分提供直接指向你所处的最后一个（板 | 积压工作 (backlog) |冲刺 (sprint)）的快速链接。
  • 收藏夹 在所有团队间收藏的所有板、冲刺 (sprint) 和积压工作 (backlog)。
  • 我的 你所属团队的所有板、积压工作 (backlog)和冲刺 (sprint)。
  • 全部 所有板、积压工作 (backlog)和冲刺 (sprint) 的完整列表。

目录页

新的“视图选项”菜单

新中心（包括积压工作 (backlog)、板和冲刺 (sprint)）具有新的视图选项菜单。 这是容纳用于自定义布局和页面内容的所有操作的新位置。 使用视图选项可启用其他视图（如显示积压工作 (backlog) 中的层次结构或更改任务板上的分组依据选项）以打开侧面板来映射和计划冲刺 (sprint)，或浏览工作详细信息图表。

查看选项

在我们的 DevOps 博客上详细了解这些令人兴奋的更新、新的团队配置文件窗格和收藏夹。

卡注释包括 bug 和自定义工作项类型

卡注释由于其直观的检查列表视图和交互而深受人们喜爱。 以前，卡注释限制为默认积压工作 (backlog) 级别类型，不支持 Bug 或自定义类型。 在新版本中，我们移除了对工作项类型的限制，并添加了将 Bug 和任何自定义工作项类型显示为卡注释的功能。

卡注释的板设置已扩展为包括可用于该积压工作 (backlog) 级别的所有工作项类型。

批注设置

启用了工作项的注释时，对该工作项类型的计数会作为单独检查列表包含在卡中。

批注工作项

还可通过卡上下文菜单快速创建已启用的工作项类型。

批注快速创建

使用建议的区域和迭代移动工作

可能常常在相同区域或迭代中工作并在四处移动工作项时重复浏览层次结构。 区域和迭代路径控件现在以建议的形式包含最近使用的值的列表，从而使你可以快速访问以进行设置并继续处理。

区域下拉列表

此外，迭代日期包含在名称右侧，以便可以快速判断何时应传递工作项。

迭代下拉列表

使用 +/- 跨迭代计划查询工作 @CurrentIteration

@CurrentIteration帮助团队根据迭代计划跟踪工作的宏现在支持整数偏移量。 轻松跟踪未使用 @CurrentIteration - 1 结束的工作，或者查看计划用于未来迭代 @CurrentIteration 的工作+1。 有关详细信息，请参阅 Microsoft DevOps 博客上的 @CurrentIteration文章 。

使用 @CurrentIteration Team 参数阐明查询迭代计划

如果过去一直在查询中使用宏， @CurrentIteration 你可能已经注意到，如果团队上下文在具有不同迭代计划的 Teams 中更改，结果可能会有所不同。 现在，使用 @CurrentIteration 宏创建或修改查询时，还需要选择具有与查询相关的迭代计划的 Team。 使用 Team 参数，可以在同一查询中使用宏， @CurrentIteration 但跨团队使用宏。 一个示例可能是使用不同迭代名称（甚至还有计划）对两个不同团队项目中的工作项进行的查询。 这意味不必再随着冲刺 (sprint) 更改而更新查询！ 有关详细信息，请参阅 Microsoft DevOps 博客上的 @CurrentIteration文章 。

Team 参数

使用新 @TeamAreas 宏在团队的“区域路径”中执行查询

在团队设置中，可以关联一个或多个区域路径，这可帮助侧重于积压工作 (backlog)、板、计划，甚至是仪表板，以便仅为该团队而工作。 不过，如果要为团队编写查询，则必须在查询子句中列出该团队的特定区域路径。 现在，可以使用新的 @TeamAreas 宏轻松引用指定团队拥有的区域路径。

查询编辑器中的团队区域宏

对空格式文本字段的查询

使用新的 IsEmpty 查询运算符可查找具有空格式文本字段（例如“说明”）的工作项。

采用链接和提及体验轻松地查找现有工作项和

要将两个现有工作项链接在一起时，现在可以使用我们的新工作项搜索控件轻松地查找对你十分重要的项。 查询选择器已替换为基于最近访问的工作项的内联建议，以及用于按 ID 或标题搜索特定工作项的入口点。

工作项链接

以前，如果工作项预览窗格已关闭，则无法从搜索结果页面打开工作项。 这样便难以深入了解搜索结果。 现在你可以单击工作项标题以在模式窗口中打开工作项。

Repos

改进的分支选取器

Azure Repos 中的大多数体验要求选择一个存储库，然后选择该存储库中的一个分支。 为了为具有大量分支的组织改进此体验，我们推出了新的分支选取器。 现在通过选取器可以选择收藏夹分支或快速搜索分支。

分支选取器

绕过拉取请求策略时收到通知

对于使用拉取请求 (PR) 和分支策略的团队，有时人们需要替代并绕过这些策略（例如，在午夜部署生产问题的修补程序时）。 信任开发人员执行正确的操作以及保守地使用替代功能十分重要。 同时，团队需要一种方法来验证是否在适当的情况下使用这些策略替代。 为了对此提供支持，我们添加了新的通知筛选器以允许用户和团队在每次绕过策略时都会收到电子邮件警报。 首先使用创建或更新拉取请求模板，从筛选器的列表中选择策略绕过。 选择已绕过策略作为值，每当 PR 完成并绕过策略时，你都会收到通知。

绕过策略通知

允许绕过分支策略而不放弃推送保护

在许多情况下，偶尔需要绕过分支策略 - 还原导致生成中断的更改、在半夜应用修补程序等。以前，我们提供了一个权限 (“免除策略强制”) ，以帮助团队管理哪些用户被授予在完成拉取请求时绕过分支策略的能力。 但是，该权限还授予了直接推送到分支的功能，完全绕过 PR 过程。

为了改进此体验，我们拆分了旧权限以向授予绕过权限的团队提供更多控制。 有两个新权限可以替换旧权限：

  1. 完成拉取请求时绕过策略。 具有此权限的用户能够对拉取请求使用“替代”体验。
  2. 推送时绕过策略。 具有此权限的用户将能够直接推送到配置了所需策略的分支。

通过授予第一个权限并拒绝第二个权限，用户能够在需要时使用绕过选项，但仍然受到保护，以免意外推送到具有策略的分支。

注意

此更改不引入任何行为更改。 以前针对“免除策略实施”被授予了允许的用户会针对这两个新权限被授予允许，因此他们能够同时替代 PR 完成时和直接推送到具有策略的分支。

有关详细信息，请参阅 设置分支权限 文档。

使用提交消息快速描述拉取请求

编写描述性提交消息可任何 Git 存储库的历史记录增加价值。 为了鼓励编写高质量提交消息，具有多个提交的新拉取请求 (PR) 要求参与者手动输入标题。

拉取请求描述在默认情况下会继续为空，但通过一个新功能可更轻松地将来自 PR 提交的提交消息合并到 PR 描述中。 若要添加提交消息，只需单击添加提交消息以将提交消息追加到 PR 描述文本末尾。

创建未将默认团队作为审阅者的拉取请求

首次启动拉取请求 (PR) 体验时，我们认为将所有 PR 都分配给创建 PR 时选择的团队上下文会十分有意义。 此行为一直令人沮丧，因为很多人未注意到团队上下文与 PR 分配之间的连接。

作为新导航更改的一部分，我们抓住机会更改了与团队之间的这一默认关联。 你会注意到两个更改：

  1. 创建 PR 时，默认情况下不添加任何审阅者。 审阅者列表具有一个功能，通过它可更轻松地添加最近添加到 PR 的个人和组。 所需的审阅者策略还可以帮助希望确保添加特定审阅者来评审其代码的团队。
  2. 拉取请求中心具有一个新的可自定义部分。 默认情况下，此部分显示“分配给我的团队”的 PR，提供与旧部分等效的功能。 但是，如果你属于多个团队，则此部分会显示分配给你的所有团队的 PR。 此部分也可自定义（只需单击此部分标题附近的“自定义此视图”操作）。

使用模板标准化拉取请求描述

编写良好的拉取请求描述是帮助审阅者了解审阅代码时的预期内容的好办法。 它们也是帮助跟踪应对每个更改执行的操作（如测试、添加单元测试和更新文档）的好办法。 你们中的许多人一直要求我们添加拉取请求模板，以便团队更轻松地编写出色的说明，现在我们添加了该功能。

除了支持默认 PR 描述模板，团队可以添加多个模板，这些模板会在创建 PR 页面上的菜单中提供给你。 只需单击添加模板按钮即可从存储库中的任何模板进行选择，以将它追加到 PR 描述中。

为 PR 添加模板

如果要将 PR 的不同模板应用到特定分支或分支文件夹中，则也支持特定于分支的模板。 例如，如果要使用特定于开头为“hotfix/”的所有分支的模板，则可以将用于所有 PR 的模板添加到这些分支中。

请参阅 拉取请求模板 文档，详细了解如何创建和使用模板。

更改拉取请求的目标分支

对于大多数团队，几乎所有拉取请求都针对同一分支，例如 main 或 develop。 但是，在需要面向不同分支的情况下，很容易忘记更改默认的目标分支。 借助用于更改活动拉取请求的目标分支的新功能，现在这是简单的操作。 只需单击拉取请求标头中目标分支名称旁的铅笔图标。

更改目标分支

不仅仅是更正错误，通过用于更改目标分支的功能还可在合并或删除了目标分支时轻松地“重定向”拉取请求。 请考虑这样一个情况：你的一个 PR 面向的功能分支包含更改所依赖的某些功能。 你希望独立于功能分支中的其他更改来查看依赖性更改，因此你最初以 为目标features/new-feature。 审阅者因而可以仅查看你的更改，并留下相应的注释。

现在，请考虑一下，如果功能分支也具有活动的 PR，并在更改之前合并到 中main，会发生什么情况？ 以前，必须放弃更改，在 中创建 main一个新的 PR，或者将 PR 合并到 features/new-feature，然后创建另一个 PR 从 features/new-feature 到 main。 通过此新操作来更新目标分支，只需将 PR 的目标分支从 features/new-feature 更改为 main，从而保留所有上下文和注释。 更改目标分支甚至会创建 PR 的新更新，这样可以在目标分支更改之前轻松地回溯之前的差异。

目标分支更新

扩展创建者可以查询有关当前存储库的上下文

版本控制扩展创建者面临的一个挑战是获取向用户显示的存储库上下文，如名称、ID 和 URL。 为了帮助应对此挑战，我们添加了 VersionControlRepositoryService 作为扩展可访问的服务。 扩展创建者使用此服务可以查询有关 Web UI 中当前 Git 存储库上下文的信息。 它当前具有一个方法，即 getCurrentGitRepository()。

  • 如果选择了 Git 存储库，则会返回 GitRepository 对象以及有关该存储库的基本数据（名称、ID 和 URL）
  • 如果选择了 TFVC 存储库或在 Azure Repos 页面外部访问该服务，则会返回 null。

下面是使用此服务 的示例扩展 。

管道

使用新的“生成”页管理生成管道

我们进行了几处改进，推出了新版本的生成页面。 这一新版本合并了所有生成管道的目录和当前生成的列表，以便可以在项目的生成间快速导航以查看其状态。 它还包括所选管道的测试分析的预览。

“新建生成”页

使用改进的格式设置更好地管理生成和部署完成电子邮件

生成和部署完成电子邮件进行了更新，可在更大程度上按电子邮件规则进行筛选。 主题行现在一目了然地包含更多相关信息，正文包含更多详细信息，并且其样式使用最新品牌进行了刷新。

新格式的元素为：

  • [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
  • [Deployment result] [pipeline name] > [release name] : [stage name]

以下是一些示例：

  • [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
  • [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

遵循新的统一 Azure Pipelines 术语

在整个生成和发布中，历史上对相似概念使用了不同术语。 在其他情况下，术语的含义模糊不清。 例如，判断代理池与代理队列之间的差异。

在 Azure Pipelines 中统一了术语以阐明其概念。 现在你会看到以下统一术语：

旧术语 统一术语 含义
托管代理 Microsoft 托管代理 在由 Microsoft 管理的云托管基础结构上运行的生成/发布代理。
专用代理 自托管代码 在由你提供并管理的计算机上运行的生成/发布代理。
代理池 代理池 可以运行生成或发布的组织级别的代理计算机集。
代理队列 代理池 可以运行生成或发布的项目级别的代理计算机集。 它链接到组织级别的代理池。
生成定义 生成管道 应用程序的端到端生成步骤集。
生成 生成 正在运行或已运行的生成管道的实例。
阶段 作业 在代理上按顺序或并行运行的一系列任务。 生成或发布管道可以包含一个作业或多个作业组成的图。
发布定义 发布管道 要跨各个阶段部署的应用程序的端到端发布步骤集。
发布 发布 正在运行或已运行的发布管道的实例。
环境 阶段 一个逻辑和独立实体，表示要在其中部署从发布管道生成的发布。
并发作业/管道 并行作业 并行作业使你能够在组织中一次运行单个生成或发布作业。 有多个并行作业可用时，可以同时运行多个生成和发布作业。
服务终结点 服务连接 用于连接到外部服务以在生成或发布中执行任务的一组设置，如凭据。

有关详细信息，请参阅 概念 文档。

使用新的“发布”页面管理发布管道

发布登陆页面提供了经过完全重新设计的新用户体验。 可查看你发布的发布管道的列表（通常在左侧）。 还可以搜索你的管道并收藏它们。

发布登陆页面

更改为文件夹视图以便为组织和安全性创建文件夹。 可以在文件夹级别设置安全性。

释放文件夹

直观显示发布进度

新的发布进度视图可提供部署进度的实时更新，单击一次即可访问更多详细信息。 新视图直观显示发布管道以便更容易了解发生的情况，并在发布的不同阶段展现相应的详细信息和操作。

发布管道视图

管道、发布详细信息和环境

管道视图显示发布项目以及部署位置的环境。 发布区域提供发布详细信息，如发布触发器、项目版本和标记。

环境采用可帮助了解其状态以及详细进度的方式进行建模。 在任何时候，都可以通过单击环境中的状态链接来获取日志。

环境

预先部署和后期部署

如果为环境设置了预先部署或后期部署条件，则会在环境中通过审批和入口的存在进行指示。 审批和入口的进度也会显示在环境的状态中。 可以通过单击在环境右侧或左侧挂起的环境条件图标来执行操作或查看进一步详细信息。

发布环境操作

提交和工作项

对于每个新发布，可以通过单击环境来单独查看每个环境的关联提交和工作项的列表。 如果列表太长，可使用筛选器查找感兴趣的提交或工作项。

发布提交和工作项

部署进度和日志

环境会显示正在进行的部署的实时更新，包括已完成和正在运行的阶段和任务数量。 单击环境状态可打开一个包含日志的视图（侧重于当前处于活动状态的内容）。

可以在日志中单击以进入集中视图。

发布日志详细信息

升级到 Azure DevOps Server 2019 对任务的影响：目标计算机上的 Windows 计算机文件复制和 PoweShell

TFS 2017 RTM 中 已弃用 测试中心下的计算机组。 Azure DevOps Server 2019 年，计算机组服务不再可用。 这将影响“Windows 计算机文件复制”任务版本 1.* 和“目标计算机上的 PowerShell”任务版本 1.*的用户。 使管道继续工作，

  • 必须切换到“Windows 计算机文件复制”任务版本 2.* 并为目标计算机提供完整的 fqdn，而不仅仅是计算机名称。
  • 切换到“目标计算机上的 Powershell”任务版本 2.* 或更高版本，并提供计算机或计算机名称的完整 fqdn，后跟 Windows 远程管理端口 (http/https) 。 例如，targetMachine：5985 或 targetMachine：5986

测试结果和扩展性

还会为每个环境展现测试执行的结果。 单击测试结果可打开一个包含测试详细信息的视图，其中包括来自参与处理的其他扩展的结果。

发布测试结果

现有扩展在此新视图进行工作，并且有新的扩展点可允许扩展表现甚至更多的环境信息。 有关详细信息，请参阅 贡献和扩展 文档。

使用 YAML 配置生成

Azure DevOps Server 中提供了基于 YAML 的生成管道。 使用签入到存储库中的 YAML 文件可自动执行持续集成管道。 在此处可以找到 YAML 架构的完整参考。

为了更加无缝地支持基于 YAML 的生成管道，我们将你创建的所有新资源（如服务连接、变量组、代理池和安全文件）的默认行为更改为可在该项目的所有管道中使用。 如果要对资源进行更紧密的控制，则可以禁用默认授权模型（请参阅下图）。 执行此操作时，具有使用资源的权限的人员必须在将资源引用添加到 YAML 文件之后，在 Web 编辑器中显式保存管道。

YAML

大型产品具有多个相互依赖的组件。 这些组件通常独立生成。 当上游组件（例如库）发生更改时，下游依赖项必须重新生成并重新验证。 团队通常手动管理这些依赖项。

现在可以在一个生成成功完成时触发另一个生成。 上游生成生成的项目可以在以后的生成中下载和使用，还可以从以下变量中获取数据：Build.TriggeredBy.BuildId、Build.TriggeredBy.DefinitionId、Build.TriggeredBy.BuildDefinitionName。 有关详细信息，请参阅 生成触发器 文档。

设置生成链接

请记住，在某些情况下，单个 多阶段生成 可以满足你的需求。 但是，如果要求包括不同配置设置、选项或拥有依赖进程的不同团队，则生成完成触发器十分有用。

本地更新代理

有时从库安装的任务需要较新版本的管道代理。 如果 Azure DevOps Server 可以连接到 Internet，则会自动下载较新版本。 如果未自动下载，则必须手动升级每个代理。 从此发布开始，可以配置 Azure DevOps Server 以查找其本地磁盘上（而不是来自 Internet）的代理包文件。 这使你可以具备灵活性并控制你提供的代理版本，而不必向 Internet 公开 Azure DevOps Server。

新的生成状态徽章 URL

嵌入在存储库主页中的生成徽章是显示存储库运行状况的常用方法。 尽管我们到目前为止已有了生成徽章，但是存在几个问题：

  • URL 不直观
  • 徽章不特定于某个分支
  • 用户无法单击徽章以将用户转到该定义的最新生成

我们现在针对生成徽章推出了一个解决这些问题的新 API。 新 API 使用户可以发布每个分支状态，可以将用户转到所选分支的最新生成。 可以通过在“新建生成”页中选择“状态锁屏提醒”菜单操作来获取新状态锁屏提醒 URL 的 Markdown。

为了向后兼容，我们将继续同样接受较旧生成徽章 URL。

将自定义生成计数器添加到生成

生成计数器提供对生成进行唯一编号和标记的方法。 以前可以使用 $(rev:r) 特殊变量来实现此目的。 现在可以在生成定义中定义自己的计数器变量，这些变量在每次运行生成时自动递增。 可在定义的变量选项卡上执行此操作。 这一新功能在以下方面为你提供更强大的功能：

  • 可以定义自定义计数器并设置其种子值。 例如，可以在 100 处启动计数器。 $ (rev：r) 始终从 0 开始。
  • 可以使用自己的自定义逻辑重置计数器。 $ (rev：r) 绑定到生成内部版本号，每当内部版本号中有新前缀时，它会自动重置。
  • 对每个定义可以定义多个计数器。
  • 可以查询生成之外的计数器值。 例如，可以使用计数器对自上次重置以来运行的生成数进行计数。

有关生成计数器的详细信息，请参阅 有关用户定义的变量 的文档。

管道中的 Azure Policy 合规性和安全性验证

我们希望在开发过程中尽早确保软件的稳定性和安全性，同时将开发、安全性和操作整合在一起。 为此，我们添加了对Azure Policy的支持。

可以借助 Azure Policy，通过策略定义来对资源强制实施规则并施加影响，以便管理和预防 IT 问题。 使用Azure Policy时，资源始终符合公司标准和服务级别协议。

为了在发布过程中遵守合规性和安全性指导原则，我们增强了我们的 Azure 资源组部署体验。 现在，如果在部署 ARM 模板期间发生任何违规，则我们会使存在与相关策略有关的错误的 Azure 资源组部署任务失败。

Azure Policy

此外，我们添加了 Azure Policy 发布定义模板。 这使用户可以创建 Azure 策略并通过发布定义本身将这些策略分配给资源、订阅或管理组。

Azure Policy模板

Linux/ARM 和 Windows 32 位平台上的生成

64 位 (x64) Windows、macOS 和 Linux 始终支持 Azure Pipelines 开放源代码跨平台代理。 在此版本中，我们将引入两个新的受支持平台： Linux/ARM 和 Windows/32 位。 这些新平台使你可以在不太常见，但并不是不重要的平台（如 Raspberry Pi、Linux/ARM 计算机）上进行生成。

改进了管道中的测试体验

测试选项卡现在具有现代体验，可针对管道提供丰富的上下文中测试信息。 新体验提供正在进行的测试视图、整页调试体验、上下文中测试历史记录、报告已中止测试执行以及运行级别摘要。

新建测试中心

查看正在进行的测试的执行

测试（如集成和功能测试）可能会长时间运行，因此可在任何给定时间查看测试执行会十分重要。 借助正在进行的测试视图，不必再等待测试执行完成即可了解测试结果。 结果会在运行时近乎实时地提供，从而帮助更快地执行操作。 可以调试失败或中止、对 bug 归档或中止管道。 该功能当前可用于多代理阶段中使用 VS 测试任务的生成和发布管道、使用发布测试结果任务或是使用 API 发布测试结果。 我们计划将来对使用单个代理的测试执行扩展此体验。

下面的视图显示新发布进度视图中正在进行的测试摘要，报告给定时间点的总测试计数和测试失败数。

正在进行的测试视图

通过单击上面的正在进行的测试摘要，可以在测试计划中查看详细测试摘要以及失败或已中止测试信息。 测试摘要基于新结果的可用性以定期间隔进行刷新，能够按需刷新详细信息视图。

详细的测试摘要

以整页查看测试运行调试详细信息

错误消息和堆栈跟踪本质上很长，需要足够空间才能在调试过程中查看详细信息。 若要获得沉浸式调试体验，现在可以将测试或测试运行视图展开为整页视图，同时仍然能够对当前测试结果执行所需的上下文中操作（如 bug 创建或要求关联）。

整页调试

查看上下文中测试历史记录

在历史上，团队必须转到运行中心，才能查看测试结果的历史记录。 借助新体验，我们直接在测试计划选项卡的上下文中提供生成和发布的测试历史记录。 以渐进式方法提供测试历史记录信息，从所选测试的当前生成定义或环境开始，接下来分别是生成和发布的其他分支和环境。

上下文中测试历史记录

查看已中止的测试

测试执行可能会由于多种原因（如错误测试代码、进行测试的源代码和环境问题）而中止。 无论是何种中止原因，诊断行为并确定根本原因都十分重要。 现在可以在测试计划中查看已中止的测试和测试运行以及已完成的运行。 该功能当前可用于多代理阶段中使用 VS 测试任务的生成和发布管道或是使用 API 发布测试结果。 我们计划将来对使用单个代理的测试执行扩展此体验。

查看已中止的测试

测试历史记录中的测试可跟踪性和发布环境支持

我们添加了支持来查看按在其中运行测试的各种发布环境分组的自动测试历史记录。 如果将发布环境建模为发布管道或测试环境，并在这类环境间运行测试，则可以发现测试是否在开发环境中通过，但在集成环境中失败。 可以发现它是否在英语区域设置中通过，但在具有土耳其语区域设置的环境中失败。 对于每个环境中，会找到最新测试结果的状态，并且如果测试在该环境中失败，则还会找到测试开始失败时的第一个发布。

查看汇总测试结果

在测试执行期间，测试可能会生成多个测试实例，它们都会参与形成整体结果。 一些示例包括：由于失败而重新运行的测试、由其他测试的有序组合构成的测试（例如顺序测试）或是具有基于所提供输入参数的不同实例的测试（数据驱动测试）。 由于这些测试相关，因此需要与基于单个测试结果派生的整体结果一起进行报告。 在此更新中，我们引入了改进版本的测试结果，它们在发布的测试选项卡中显示为层次结构。 接下来举例说明。

之前，我们引入了在 VS 测试 任务中重新运行失败的测试的功能。 但是，我们仅报告了测试的最近一次尝试，这在某种程度上限制了此功能的有用性。 我们现在将此功能扩展为将测试执行的每个实例作为一次尝试进行报告。 此外，测试管理 API 现在支持发布和查询分层测试结果的功能。 有关详细信息，请参阅 测试结果 API 文档。

测试摘要调试

注意

测试摘要部分中的指标（例如测试总数、已通过等）使用层次结构的根级别（而不是测试的每个单独迭代）进行计算。

查看管道中的测试分析

随时间推移跟踪测试质量并改进测试附属品是维护正常管道的关键。 利用测试分析功能可以近乎实时地了解用于生成和发布管道的测试数据。 该功能可通过识别重复且严重影响质量的问题来帮助提高管道效率。

可以按各种元素对测试结果进行分组、标识分支或测试文件的关键测试或深化到特定测试以查看趋势并了解质量问题（如信号不可靠）。

查看 生成 和 发布的测试分析，下面预览：

测试分析

有关详细信息，请参阅文档。

使用多个无代理任务简化定义

无代理阶段中的任务由服务器进行安排并在服务器上执行。 无代理阶段不需要代理或任何目标计算机。 与代理阶段不同，只能将一个任务添加到定义中的每个无代理阶段。 这意味着在过程中存在多个无代理任务时必须添加多个阶段，从而使定义十分庞大。 我们放宽了此限制，使你可以在无代理阶段中维护多个任务。 相同阶段中的任务会按顺序执行，如同针对代理阶段一样。 有关详细信息，请参阅 服务器阶段 文档。

使用发布入口逐渐公开部署并划分阶段

使用发布入口可以指定在将发布提升到下一个环境之前必须满足的应用程序运行状况条件。 所有指定入口都会在任何部署之前或之后定期进行评估，直到它们全部成功。 现成提供四种类型的入口，你可以从 市场添加更多入口。 你能够审核是否满足了部署的所有必需条件。 请参阅发布入口文档获取详细信息。

“发布入口”面板

保持部署，直到入口一致地成功

通过发布入口可以在将发布提升到下一个环境之前自动评估运行状况条件。 默认情况下，发布会在收到所有入口的一个成功示例之后前进。 即使入口不稳定，并且收到的成功示例是噪声，发布也会前进。 若要避免这些类型的问题，现在可以配置发布以在前进之前验证最小持续时间内的运行状况一致性。 在运行时，发布会在允许提升之前确保入口的连续评估成功。 评估的总时间取决于“重新评估之间的时间”，通常多于配置的最小持续时间。 有关详细信息，请参阅 使用入口发布部署控制 文档。

入口保持设置

自动部署到部署组中的新目标

以前，当新目标添加到部署组时，需要进行手动部署以确保所有目标都具有相同发布。 现在可以配置环境以将最近的成功发布自动部署到新目标。 有关详细信息，请参阅 部署组 文档。

部署组

持续部署标记进行后期生成处理的生成

持续部署触发器在生成完成时创建发布。 但是，有时生成会进行后期处理，只应在该处理完成之后才发布生成。 现在可以在发布的触发器筛选器中利用生成标记（在后期处理过程中分配）。

生成标记触发器

在发布时设置变量

在发布定义中，现在可以选择要在创建发布时设置的变量。

Release 变量

在创建发布时为变量提供的值仅用于该发布。 此功能可帮助避免用于以草稿状态创建、更新草稿中的变量以及使用变量触发发布的多个步骤。

发布中的发布变量

将环境变量传递给任务

CI/CD 任务作者可以在 task.json 中设置新属性 showEnvironmentVariables，以将环境变量传递给任务。 执行此操作时，会在生成编辑器中的任务上呈现一个额外控件。 此可用于 Powershell、Cmd 和 Bash 任务。

传递环境变量

这可实现两个方案：

  • 一个任务需要变量名称保留大小写的环境变量。 例如在上面的示例中，传递给任务的环境变量是“foo”而不是“FOO”。
  • 它允许以安全方式将机密值传递给脚本。 这优先于将机密作为参数传递给脚本，因为代理上的操作系统可能会记录进程调用（包括其参数）。

克隆变量组

我们添加了对克隆变量组的支持。 每当要复制变量组并且只更新少数变量时，无需完成逐个添加变量的冗长过程。 现在可以快速复制变量组，相应地更新值，然后将它保存为新变量组。

克隆变量组

注意

在克隆变量组时不会复制机密变量值。 需要更新加密变量，然后保存克隆的变量组。

忽略部署的发布入口

通过发布入口可以在将发布提升到下一个环境之前自动评估运行状况条件。 默认情况下，发布管道仅当所有入口同时正常时才会前进。 在某些情况下（例如在加快发布时或是在手动检查运行状况之后），审批者可能要忽略某个入口并允许发布前进，即使该入口尚未评估为正常也是如此。 有关详细信息 ，请参阅发布入口 文档。

忽略门

使用拉取请求发布触发器执行附加测试

你已能够基于拉取请求 (PR) 触发生成并暂时在合并之前获取该快速反馈。 现在还可以为发布配置 PR 触发器。 发布的状态会回发到代码存储库，可以直接在 PR 页面中查看。 如果要在 PR 工作流中执行附加功能或手动测试，则会很有帮助。

发布中的 PR 触发器

使用通过证书进行身份验证的服务主体创建 Azure 服务连接

现在可以使用服务主体和身份验证证书定义 Azure 服务连接。 Azure 服务连接现在支持使用证书进行身份验证的服务主体，现在可以部署到配置了 AD FS 的Azure Stack。 若要使用证书身份验证创建服务主体，请参阅有关如何创建使用证书进行身份验证的服务主体的文章。

通过服务主体进行连接

从 Azure 应用服务部署中支持的包运行

Azure 应用服务部署任务 (4.*) 版本现在支持 RunFromPackage (以前称为 RunFromZip。

应用服务支持多种不同的技术来部署文件，如 msdeploy（又称为 WebDeploy）、git、ARM 等。 但所有这些技术都有一个限制。 文件部署在 wwwroot 文件夹（具体而言是 d:\home\site\wwwroot）下，运行时随后从其中运行文件。

借助“从包运行”功能，不再需要将各个文件复制到 wwwroot 的部署步骤。 而是只需将它指向到一个 zip 文件，该 zip 会作为只读文件系统装载在 wwwroot 上。 这样做有以下几个好处：

  • 减少文件副本锁定问题的风险。
  • 可部署到生产应用（需重启）。
  • 可以确定哪些文件在应用中运行。
  • 提高 Azure 应用服务部署的性能。
  • 可以减少冷启动时间，特别是对于具有大型 npm 包树的 JavaScript 函数。

使用应用服务器部署任务部署 Linux 容器

4.* 版本的 Azure 应用服务部署任务现在支持将自己的自定义容器部署到 Linux 上的 Azure Functions。

Azure Functions 的 Linux 托管模型基于 Docker 容器，这些容器在打包和利用应用特定依赖项方面可提供更高灵活性。 Linux 上的 Functions 可以采用 2 种不同模式进行托管：

  1. 内置容器映像： 你带来了函数应用代码，Azure (内置映像模式) 提供和管理容器，因此不需要与 Docker 相关的特定知识。 这在现有版本的应用服务部署任务中受支持。
  2. 自定义容器映像：我们增强了 App 服务 部署任务，以支持将自定义容器映像部署到 Linux 上的 Azure Functions。 当函数需要特定语言版本或需要内置映像中未提供的特定依赖项或配置时，可以使用 Azure Pipelines 生成自定义映像并部署到 Linux 上的 Azure Functions。

Xcode 任务支持新发布的 Xcode 10

通过与 Apple 的 Xcode 10 发布保持一致，现在可以将项目设置为专门使用 Xcode 10 进行生成或测试。 管道还可以与 Xcode 版本的 矩阵 并行运行作业。 可以使用 Microsoft 托管的 macOS 代理池运行这些生成。 请参阅有关在 Azure Pipelines 中使用 Xcode 的 指南 。

Xcode 10

使用 Helm 简化到 Kubernetes 的部署

Helm 是一种简化 Kubernetes 应用程序的安装和管理的工具。 它也在上一年获得了大量人气和社区支持。 Release 中的 Helm 任务现在可用于将 Helm 图表打包并部署到 Azure 容器服务 (AKS) 或任何其他 Kubernetes 群集。

随着此 Helm 任务的添加，现在可以设置基于 Helm 的 CI/CD 管道以便将容器传送到 Kubernetes 群集中。 有关详细信息，请参阅 使用 Kubernetes 部署到 Azure 容器服务 文档。

helm 任务

控制在发布中使用的 Helm 版本

Helm 工具安装程序任务从 Internet 或工具缓存获取特定版本的 Helm，并将它添加到代理（托管或专用）的路径。 使用此任务可更改在后续任务（如 .NET Core cli 任务）中使用的 Helm 版本。 在生成或发布定义中于 Helm 部署任务之前添加此任务可确保使用正确的 Helm 版本对应用进行打包和部署。 此任务还可帮助有选择地安装 kubectl 工具，后者是 Helm 正常运行的先决条件。

持续部署到 Azure Database for MySQL

现在可以持续部署到 Azure Database for MySQL - Azure 的 MySQL 数据库即服务。 可在版本控制中管理 MySQL 脚本文件，并使用本机任务（而不是 PowerShell 脚本）作为发布管道的一部分持续部署。

使用改进的 Windows 远程基于 PowerShell 的任务

可使用新的和改进的 Windows 远程基于 PowerShell 的任务。 这些改进包括几个性能修复以及支持实时日志和控制台输出命令，如 Write-Host 和 Write-Output。

目标任务上的 PowerShell (版本：3.*) ：可以添加内联脚本、修改 PSSession 选项、控制“ErrorActionPreference”，并在出现标准错误时失败。

Azure 文件复制任务 (版本：2.*) ：随附了解决 GitHub 问题的最新 AzCopy (v7.1.0) 。

为 GitHub Enterprise 或外部 Git 项目筛选分支

从 GitHub Enterprise 或外部 Git 存储库发布时，现在可以配置将发布的特定分支。 例如，你可能要只将来自特定分支的生成部署到生产。

分支筛选器

生成以 Go 编写的应用程序

使用 Go 工具安装程序任务可动态安装一个或多个版本的 Go 工具。 此任务获取项目所需的特定版本 Go 工具，并将它添加到生成代理的路径。 如果代理上已安装了目标 Go 工具版本，则此任务会跳过下载并再次安装它的过程。

Go 任务可帮助下载依赖项、生成或测试应用程序。 还可以使用此任务运行所选择的自定义 Go 命令。

在管道中运行内联或基于文件的 Python 脚本

新的 Python 脚本 任务简化了管道中 Python 脚本的运行。 该任务会从存储库中的 Python 文件 (.py) 运行脚本，你也可以在任务设置中手动输入脚本以保存为管道的一部分。 该任务将使用路径中的 Python 版本，也可以指定要使用的 Python 解释器的绝对路径。

利用来自 xcpretty 的改进的 Xcode 生成和测试输出

xcpretty 增强了 xcodebuild 输出的可读性，并生成 JUnit 格式的测试结果。 当代理计算机上有 xcpretty 可用时，Xcode 生成任务现在会自动使用 xcpretty，因为它处于托管 macOS 代理上。 尽管 xcpretty 输出与 xcodebuild 输出相比可能有所不同并且没那么详细，但是我们会随每个生成提供完整 xcodebuild 日志。

Test Plans

测试运行程序 (Azure Test Plans) 客户端为桌面应用程序运行手动测试

现在，可以使用测试运行程序 (Azure Test Plans) 客户端为桌面应用程序运行手动测试。 这会帮助你从 Microsoft 测试管理器迁移到 Azure Test Plans。 请在此处参阅我们的指南。 使用测试运行程序客户端，可以运行手动测试并记录每个测试步骤的测试结果。 还可获得数据收集功能，如屏幕截图、图像操作日志和音频视频录制。 如果在测试时发现问题，请使用测试运行程序创建 bug，bug 中会自动包含测试步骤、屏幕截图和注释。

测试运行器 (Azure Test Plans) 需要一次性下载并安装运行器。 选择为桌面应用程序运行，如下所示。

Azure 测试运行程序

Azure 测试运行程序安装

Artifacts

上游源

Azure DevOps Server 2019 对 Azure Artifacts 源上可用的上游源提供了大量更新：

  • 可以将 nuget.org 上游源添加到以前的 TFS 版本中创建的现有源。 可查找源包上方的横幅以了解详细信息，包括在升级之前应注意的行为更改。
  • 可以将其他 Azure DevOps Server 源作为上游源添加到你的源，这意味着你可以通过你的源使用这些源中的 NuGet 和 npm 包。

我们还在 Azure Artifacts 中引入了一个新角色：“协作者”。 协作者可以保存来自上游源的包，但无法将包直接到发布到源中（例如使用 nuget 发布）。 这使你可以将包发布限制为受信任的用户或生成系统，同时允许你的工程师使用来自上游源的新包。

关注包

我们使直接使用每个包上的新关注按钮设置通知变得更简单。 关注按钮也与发布视图兼容。 如果你关注某个循包，同时通过视图查看它，则你只会获得提升到该视图的新版本的更新。

更改源设置而不必手动保存

源设置页面上的几个交互得到了改进。 现在会立即保存进行的更改（如添加上游或权限）。 这意味着在设置透视之间切换时，不必担心会丢失更改。

使用适用于 NuGet 的新跨平台凭据提供程序简化身份验证

与经过身份验证的 NuGet 源进行的交互刚刚得到了很大改善。 新的基于 .NET Core 的 Azure Artifacts 凭据提供程序 适用于 Windows、macOS 和 Linux 上的 msbuild、dotnet 和 nuget (.exe) 。 每当要使用来自 Azure Artifacts 源的包时，该凭据提供程序会自动获取并存储代表所使用的 NuGet 客户端的令牌。 无需再在配置文件中手动存储和管理令牌。

若要获取新的提供程序，请转到 GitHub 并按照客户端和平台的说明进行操作。

发布到文件共享时压缩符号

我们更新了 索引 & 发布符号任务 ，以支持在符号发布到文件共享时压缩符号。

压缩符号

Wiki

从 Git 存储库将 markdown 文件发布为 Wiki

开发人员可在代码存储库中为“API”、“SDK”和“说明代码的帮助文档”创建文档。 读者随后需要筛查代码以找到正确文档。 现在可以只需从代码存储库发布 markdown 文件并在 Wiki 中托管它们。

将公共代码作为 Wiki 操作

在 Wiki 中，首先单击将代码发布为 wiki。 接下来，可以指定 Git 存储库中应提升的文件夹。

“发布页面”对话框

单击发布之后，所选文件夹下的所有 markdown 文件都会发布为 wiki。 这还会将分支的标头映射到 wiki，以便可立即反映对 Git 存储库进行的任何更改。

有关详细信息，请参阅 产品文档博客文章 。

链接到页面中的标题

现在可以单击 wiki 页面中任何部分标题旁的链接图标，以生成直接指向该部分的 URL。 随后可以复制该 URL 并将它与团队成员共享，以将他们直接链接到该部分。

Wiki 标题 URL

在文件夹中附加文件和图像

在脱机编辑 wiki 页面时，可以更轻松地在 wiki 页面所在的相同目录中添加文件附件和图像。 现在，你可以在 Wiki 中的任何文件夹中添加附件或图像并将其链接到你的页面。

git 存储库文件夹中的 Wiki 图像

在 wiki 中嵌入视频

现在可以通过联机服务（如 Microsoft Stream 和 YouTube）在 wiki 页面中嵌入视频。 可以使用以下语法添加嵌入式视频 URL：

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

在 Wiki 中嵌入视频

重命名 wiki

现在可以在 wiki 用户界面中以及使用 REST API 重命名 wiki。 从更多菜单中，单击重命名 wiki 以向 wiki 提供便于记忆的名称。

重命名 Wiki

在新选项卡中打开页面

现在可以右键单击 wiki 页面并在新选项卡中打开它，或只需在 wiki 页面上按 CTRL + 左键单击以在新选项卡中打开它。

Wiki 新建选项卡

保留 Wiki 页面标题中的特殊字符

现在，可以使用特殊字符（例如 : < > * ? | -）创建 Wiki 页面。 现在，标题为“FAQ？”的页面 或在 Wiki 中创建“设置指南”。 以下字符会转换为其 UTF-8 编码字符串：

字符 编码字符串
: %3A
< %3C
> %3E
* %2A
? %3F
| %7C
- %2D

wiki 中所有未正确链接的链接会采用明显的红色和断开的链接图标进行显示，从而为你提供 wiki 页面中所有断开的链接的视觉线索。

Wiki 断开的链接

断开的页面链接是任何文档解决方案中页面质量不佳的主要原因之一。 以前在 Wiki 中，当移动树结构中的某个页面或重命名某个页面时，它可能是从其他页面和工作项到该页面的断开的链接。 现在可以在链接断开之前检查并修复它们。

重要

请记得对页面中的链接使用 []() markdown 语法，并在工作项中使用 Wiki 页面 链接类型，以允许 Wiki 查找并修复这些可能断开的链接。 此功能不会选取工作项中的纯文本 URL 和超链接。

重命名或移动页面时，系统会提示你检查受影响的绝对链接或相对链接。

“移动页面”对话框

随后会在执行操作之前显示受影响的页面链接和工作项的列表。

移动页面链接

为 wiki 页面创建目录

有时 wiki 页面可能会很长，其内容按多个标题进行组织。 现在，可以使用 语法将目录添加到至少具有一个标题 [[_TOC_]] 的任何页面。

Wiki 目录

还可以在编辑页面时通过单击格式窗格中的相应按钮来插入目录。

插入 Wiki TOC

有关在 Azure DevOps 中使用 Markdown 的详细信息，请参阅 Markdown 指南文档。

使用 YAML 标记展示 wiki 页面和代码预览的元数据

向文档添加元数据可以帮助读者和搜索索引选取并展现有意义的内容。 在此更新中，在文件开头包含 YAML 块的任何文件都会转换为由一个头和一行组成的元数据表。 YAML 块必须采用在三重短划线之间设置的有效 YAML 的形式。 它支持所有将基本数据类型、列表、对象作为值。 Wiki 和代码文件预览中支持该语法。

YAML 标记示例：

---
tag: post
title: Hello world
---

YAML 表

具有列表的 YAML 标记示例：

---
tags:
- post
- code
- web
title: Hello world
---

带有列表的 YAML 表

使用参与权限将代码发布为 wiki

以前，只有对 git 存储库拥有创建存储库权限的用户才能将代码发布为 wiki。 这使得对于将 git 存储库中托管的 markdown 文件发布为 wiki 的任何请求，存储库管理员或创建者都会成为瓶颈。 现在，如果只是对代码存储库具有“参与讨论”权限，则可以将代码发布为 Wiki。

报表

用于报告的 Analytics 市场扩展现已推出

分析市场扩展现在可用于Azure DevOps Server。 Analytics 是未来适用于 Azure DevOps 和 Azure DevOps Server 的报告。 安装 Analytics 扩展可提供 高级小组件、 Power BI 集成和 OData 访问。

有关详细信息，检查什么是分析和报告路线图。 Analytics 处于公共预览版状态。 它当前通过管道包含板和自动测试结果的数据。 请参阅 Analytics Service 中提供的数据。

通过新的生成仪表板小组件调查生成历史记录

我们提供了一个改进的新生成历史记录小组件，你可以将它添加到你的仪表板。 使用此小组件现在可以在仪表板上查看特定分支中的生成的历史记录，并在公共项目中为匿名访问者配置它。

重要

如果你想深入了解你的 XAML 生成，请继续使用较旧的小组件，并阅读从 XAML 生成迁移到新生成。 否则建议你迁移到较新的小组件。

反馈

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

返回页首