Azure DevOps Server 2019 Update 1 发行说明

开发者社区 | 系统要求 | 许可条款 | 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。

---

安全地从 Azure DevOps Server 2019 升级到 Azure DevOps Server 2020

Azure DevOps Server 2020 引入了新的管道运行（生成）保留模型，该模型基于 项目级 设置工作。

Azure DevOps Server 2020 根据管道级保留策略以不同的方式进行生成保留处理。 某些特定的策略配置会导致升级后管道运行被删除。 升级后，手动保留或通过发布保留的管道运行不会被删除。

请阅读我们的 博客文章，详细了解如何安全地从 Azure DevOps Server 2019 升级到 Azure DevOps Server 2020。

Azure DevOps Server 2019 Update 1.2 修补程序 10 发布日期：2025 年 3 月 11 日

文件	SHA-256 哈希
devops2019.1.2patch10.exe	EDCE91E3F92A2E60FB9BA9BE6977B47BC794817A13766C728B97D4B83039B789

我们已经发布了适用于 Azure DevOps Server 2019 Update 1.2 的第 10 号补丁 ，其中包括以下内容：

• 因 Edgio CDN 的弃用而更新任务。 有关详细信息，请查看 切换 CDN 提供程序博客文章。

Azure DevOps Server 2019 Update 1.2 修补程序 9 发布日期：2024 年 5 月 28 日

文件	SHA-256 哈希
devops2019.1.2patch9.exe	4A3F41BBE00174DE964667878766EBF7F4D292526CBC1D885180B55D994B4D81

我们发布了 Azure DevOps Server 2019 Update 1.2 Patch 9，其中包括以下内容：

• 简化以前修补程序（修补程序 5 和 6）中的代理和任务更新的部署。

注意

无需遵循修补程序 5 和 6 中的步骤;可以跳过这些修补程序，并可以改为应用此修补程序。

安装补丁

重要

 此修补程序更新可用的管道代理，安装修补程序 9 后的代理新版本将为 3.225.0。

管道要求

若要应用新行为来验证命令行参数，必须在使用受影响任务的管道中设置变量 AZP_75787_ENABLE_NEW_LOGIC = true。 有关启用的行为的详细信息，请参阅此处 ：

• 在经典版本上：

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

• YAML 示例：

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2019 Update 1.2 修补程序 8 发布日期：2024 年 3 月 12 日

文件	SHA-256 哈希
devops2019.1.2patch8.exe	67E78EA7D67A09A6EE06309614F92E6D8495DEF52FF442E4E7C7979244FAD20A

我们 发布了适用于 Azure DevOps Server 2019 Update 1.2 的补丁 8，其中包括以下内容的修复：

• 解决了安装 Patch 7 后代理服务器停止工作的问题。

Azure DevOps Server 2019 Update 1.2 Patch 7 发布日期：2024 年 2 月 13 日

文件	SHA-256 加密哈希
devops2019.1.2patch7.exe	8C67C72A83C9215302BDEFB752A7C4E3F876D4D17FCFA63A02B955FCFB5455AA

我们发布了 Azure DevOps Server 2019 Update 1.2 的 修补程序 7，其中包括以下修复：

• 修复了一个问题，该问题导致代理缓存文件夹使用的磁盘空间计算错误，并且文件夹未被正确清理。
• CVE-2024-20667：Azure DevOps Server 远程代码执行漏洞。

Azure DevOps Server 2019 Update 1.2 Patch 6 发布日期：2023 年 11 月 14 日

我们发布了用于 Azure DevOps Server 2019 Update 1.2 的补丁，其中包括对以下问题的修复。

• 扩展了 PowerShell 任务中允许的字符列表，以便针对 启用 shell 任务参数验证的功能进行验证。

备注

要应用此修补程序，必须执行多个步骤来手动更新任务。

安装补丁

重要

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

我们发布了用于 Azure DevOps Server 2019 Update 1.2 的补丁，其中包括对以下问题的修复。

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

重要

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

注意

若要应用此修补程序，需要执行多个步骤来手动更新代理程序和任务。

安装补丁

1. 下载并安装 Azure DevOps Server 2019 Update 1.2 修补程序 5。

更新 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 Update 1.2 修补程序 4 发布日期：2023 年 8 月 8 日

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

• CVE-2023-36869：Azure DevOps Server 欺骗漏洞。
• 更新 SSH 服务以支持 SHA2-256 和 SHA2-512。 如果 SSH 配置文件硬编码为使用 RSA，则应更新为 SHA2 或删除条目。
• 修复了 CronScheduleJobExtension 上的无限循环 bug。

Azure DevOps Server 2019 Update 1.2 Patch 3 发布日期：2023 年 6 月 13 日

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

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

Azure DevOps Server 2019 Update 1.2 Patch 2 发布日期：2022 年 12 月 13 日

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

• 修复了“帐户并行同步分析作业”中的失败。

Azure DevOps Server 2019 Update 1.2 修补程序 1 发布日期：2022 年 7 月 12 日

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

• 在测试运行 API 中，返回的延续令牌大于指定的“maxLastUpdatedDate”值。
• 编辑经典管道时，当放弃其他选项卡上的更改时，保留选项卡变为空白。

Azure DevOps Server 2019 Update 1.2 发布日期：2022 年 5 月 17 日

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

注意

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

此版本涵盖以下问题修复：

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

Azure DevOps Server 2019 Update 1.1 修补程序 13 发布日期：2022 年 1 月 26 日

我们发布了适用于 Azure DevOps Server 2019 Update 1.1 的 补丁，其中包括以下修复。

• 在工作项中使用 @mention 控件时，不会发送电子邮件通知。
• 首选电子邮件地址未在用户配置文件中更新。 这导致电子邮件被发送到之前的电子邮件地址。
• 通过从 log4j 二进制文件中删除 jndilookup 类来解决 Elasticsearch 漏洞。

安装步骤

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

注意

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

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

SHA-256 哈希： DB762E391F9DF8E71E58D6FAA169CA44DFBE996AE6567B55F772CBA9E3DA2AB3

Azure DevOps Server 2019 Update 1.1 修补程序 12 发布日期：2021 年 9 月 15 日

Azure DevOps Server 2019 Update 1.1 的修补程序 12 包含以下内容的修复。

• 修复包含“包含字词”的查询的工作项宏。 以前，查询返回包含换行符的值的错误结果。
• 自定义工作项布局状态的本地化问题。
• 电子邮件通知模板中的本地化问题。
• 为字段定义了多个 NOTSAMEAS 规则时，NOTSAMEAS 规则评估的问题。

Azure DevOps Server 2019 Update 1.1 修补程序 11 发布日期：2021 年 9 月 14 日

Azure DevOps Server 2019 Update 1.1 的补丁 11 包括以下修复。

• 解决 此开发人员社区反馈票证中报告的问题。

Azure DevOps Server 2019 Update 1.1 修补程序 10 发布日期：2021 年 8 月 10 日

Azure DevOps Server 2019 Update 1.1 修补程序 10 包含以下问题的修复。

• 修复了某些工作项类型的电子邮件送达作业的问题。

Azure DevOps Server 2019 Update 1.1 修补程序 9 发布日期：2021 年 6 月 15 日

Azure DevOps Server 2019 Update 1.1 的第 9 号补丁 包括以下修复。

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

Azure DevOps Server 2019 Update 1.1 修补程序 8 发布日期：2021 年 4 月 13 日

我们发布了 Azure DevOps Server 2019 Update 1.1 修补程序，修复了以下内容。

• CVE-2021-27067：信息泄露
• 解决 此开发人员社区反馈票证 中报告的问题 |无法在 Azure DevOps Server 2019 上注册测试结果迭代详细信息

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

常规修补程序安装

如果有 Azure DevOps Server 2019 Update 1.1，则应安装 Azure DevOps Server 2019 Update 1.1 Patch 8。

验证安装

• 选项 1：运行 devops2019.1.1patch8.exe CheckInstall，devops2019.1.1patch8.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.1.1 修补程序 8 后，版本将为 17.153.31129.2。

AzureResourceGroupDeploymentV2 任务安装

注意

以下所有步骤都需要在 Windows 计算机上执行

安装

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

2. 根据您的机器需求，下载并安装 Node.js 14.15.1 和 npm（已包含在 Node.js 下载中）。

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

npm install -g tfx-cli

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

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

~$ tfx login
Copyright Microsoft Corporation

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

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

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

Azure DevOps Server 2019 Update 1.1 修补程序 7 发布日期：2021 年 1 月 12 日

我们发布了 Azure DevOps Server 2019 Update 1.1 修补程序，修复了以下内容。 有关详细信息，请参阅 博客文章。

• 测试运行详细信息不显示通过 OpsHub 迁移的测试数据的测试步骤详细信息。
• “Microsoft.TeamFoundation.TestManagement.Server.TCMLogger” 的初始化程序异常
• 迁移到 Azure DevOps Server 2020 后，立即删除未完成的生成
• 修复数据提供程序异常

Azure DevOps Server 2019 Update 1.1 修补程序 6 发布日期：2020 年 12 月 8 日

我们发布了 Azure DevOps Server 2019 Update 1.1 修补程序，修复了以下内容。 有关详细信息，请参阅 博客文章。

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

重要

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

常规修补程序安装

如果有 Azure DevOps Server 2019 Update 1.1，则应安装 Azure DevOps Server 2019 Update 1.1 Patch 6。

验证安装

• 选项 1：运行 devops2019.1.1patch6.exe CheckInstall，devops2019.1.1patch6.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.1.1 修补程序 6 后，版本将为 17.153.30723.5。

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

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

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

~$ tfx login
Copyright Microsoft Corporation

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

6. 运行以下命令以在服务器上上传任务。 提取的包的路径将 D：\tasks\AzurePowerShellv4。

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

Azure DevOps Server 2019 Update 1.1 修补程序 5 发布日期：2020 年 9 月 8 日

我们发布了 Azure DevOps Server 2019 Update 1.1 修补程序，修复了以下内容。 有关详细信息，请参阅 博客文章。

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

Azure DevOps Server 2019 Update 1.1 修补程序 4 发布日期：2020 年 7 月 14 日

我们发布了 Azure DevOps Server 2019 Update 1.1 修补程序，修复了以下内容。 有关详细信息，请参阅 博客文章。

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

Azure DevOps Server 2019 Update 1.1 修补程序 3 发布日期：2020 年 6 月 9 日

我们发布了 Azure DevOps Server 2019 Update 1.1 修补程序，修复了以下内容。 有关详细信息，请参阅 博客文章。

• CVE-2020-1327：确保 Azure DevOps 服务器清理用户输入。

Azure DevOps Server 2019 Update 1.1 修补程序 2 发布日期：2020 年 4 月 14 日

我们发布了 Azure DevOps Server 2019 Update 1.1 修补程序，修复了以下内容。 有关详细信息，请参阅 博客文章。

• SVN 提交不会触发流水线

• 在 Azure DevOps 上的 SSH 中添加对 SHA2 的支持

Azure DevOps Server 2019 Update 1.1 修补程序 1 发布日期：2020 年 3 月 10 日

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

• CVE-2020-0700：跨站点脚本漏洞

• CVE-2020-0758：特权提升漏洞

• CVE 2020-0815：特权提升漏洞

---

Azure DevOps Server 2019 Update 1.1 RTW 发布日期：2019 年 12 月 10 日

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

注意

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

此版本包括以下错误的修复：

Azure Boards

• 从产品积压工作项创建新工作项时，不会使用流程模板中的默认值初始化“标题”字段。
• 使用 Azure Boards 时出现性能缓慢和超时问题。
• 工作项链接上的“修订者”值不正确。

Azure Pipelines

• 在某些区域设置中，管道通知的持续时间等字段可能为空。
• 在包含 Azure 资源组部署的管道中，模板路径可能不会指向有效的 JSON 文件。
• 集合级保留设置页显示在项目设置页中。

Azure 测试计划

• 测试计划中的编辑字段速度缓慢。
• 在测试用例中，从看板而不是从测试计划打开时，无法查看共享步骤的详细信息。

概述

• 集合不按字母顺序排序。

管理

• 高内存使用率。
• 配置了负载均衡器的服务器必须明确地将其公共地址添加到“AllowedOrigins”注册表项中。
• 在 SQL Azure 上安装的客户看不到“完整试用版”对话框。
• 安装扩展时出现错误信息：“缺少贡献（ms.vss-dashboards-web.widget-sdk-version-2）”。
• 设置弹性搜索时，出现错误：“用户未授权”。
• 从 TFS 2018 Update 2 或更高版本升级时，Elasticsearch 中的索引和查询失败。
• 配置 Azure DevOps Server 时，“创建仓库”步骤失败。

此版本包括以下更新：

• 支持 SQL Server 2019。

---

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

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

• CVE-2019-1306：Wiki 中的远程代码执行漏洞

---

Azure DevOps Server 2019 Update 1 发布日期：2019 年 8 月 20 日

注意

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

---

RC2 发布日期：2019 年 7 月 23 日

RC2 包括自 RC1 以来的多个 bug 修复，也是最终计划的预发行版。

---

RC1 发布日期：2019 年 7 月 2 日

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

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

• 新基本流程
• 查询与一天开始、周开始、月开始或年开始相关的工作
• 在 Azure Boards 中规划的同时，接受和执行 GitHub 上的问题。
• 重新运行已过期构建以自动完成拉取请求
• 用于完成拉取请求的新合并类型
• 使用标签触发 YAML 管道
• 用于编辑 YAML 文件的任务助手
• 适用于 YAML 管道的 IntelliSense Web 编辑器
• 使用管道管理 GitHub 发布
• 测试结果趋势（高级）组件
• 有关 的包 来源信息
• 对 Python 包的支持
• Maven 的上游源
• 在 Wiki 中嵌入 Azure Boards 查询结果
• wiki页面的 永久链接
• wiki 页面上的 通知
• Analytics 扩展不再需要使用 Analytics

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

• 常规
• 看板
• Repos
• 管道
• 测试计划
• 文物
• Wiki
• 报告

---

一般

深色主题

深色主题是 Azure DevOps Services 上的一项常用功能，现已在 Azure DevOps Server 中提供。 可以通过从每个页面右上角的虚拟形象下方的菜单中选择 主题 来打开深色主题。

董事会

新的基本流程

从历史上看，敏捷是新项目的默认过程，提供一组可靠灵活的工作项类型和状态，以满足各种项目交付方法。 对于一些团队来说，不论是那些更熟悉其他工具的团队，还是正在成长并希望采用更强大工具集的团队，他们都希望能够快速开始使用他们更熟悉的术语。

新的基础流程提供三种工作项类型（史诗、问题和任务），以规划和跟踪您的工作。 建议使用问题跟踪用户情景、bug 和功能等内容，同时使用 Epics 将问题组合到更大的工作单元中。 在工作中取得进展时，将事项在简单的状态工作流中移动，从“待办”、“进行中”到“已完成”。

请参阅 跟踪问题和任务 文档，以帮助你开始使用新项目。

工作项窗体上的状态值的排列顺序

以前，工作项窗体上的状态值按字母顺序排序。 通过此更新，我们更改了状态值排序方式，以匹配进程设置中的工作流顺序。 还可以更改状态自定义设置中每个类别中状态的顺序。

功能启用不再可用

客户需要手动更新每个项目的 XML，以便在升级集合后启用新功能。

请参阅 文档 了解如何启用特定功能。

使用更丰富的工作项附件整理参考资料

将文件附加到工作项使你和你的团队能够集中参考资料，以便在需要参考材料时始终接近它们。 现在只需在工作项窗体上拖放文件即可更轻松地添加新附件。 可以继续以列表的形式查看附件，或切换到网格视图以显示缩略图预览。 双击文件以打开预览并循环浏览，快速查找所需的信息。

使用徽章共享您的团队看板

存储库的自述文件通常是项目团队获取关于如何参与和使用该解决方案的主要资源。 现在，正如在 Azure Pipelines 中使用生成或部署状态一样，你可以在自述文件中添加一个用于 Azure Boards 上团队板的徽章。 可以将徽章配置为仅显示 进行中 列或所有列，如果项目是开源的，甚至可以使徽章公开显示。

共享团队的版块

如果您的自述文件是基于 Markdown 的，可以简单地从状态徽章设置页面复制示例 Markdown 并将其粘贴到您的文件中。

查询与一天、一周、一月或一年开始相关的工作

虽然团队通常专注于即将到来的工作或在冲刺迭代的框架内开展工作，但从日历的角度回顾过去的工作以了解上个月或当年第一季度完成的所有任务常常很有意义。 现在，您可以使用以下新的一组 @StartOf 宏，以及任何基于日期的字段，从一天、周、月或年的开始进行查询：

• @StartOfYear
• @StartOfMonth
• @StartOfWeek
• @StartOfDay

其中每个宏还接受新的修饰符字符串，使你可以按不同的日期单位移动数据。 例如，可以通过查询状态更改日期 >= @StartOfYear 和状态更改日期 <= @StartOfYear(“+3M” 来编写查询以查找今年第一季度完成的所有工作项。 有关详细信息，请参阅 查询宏 文档。

编辑和删除讨论批注

我们很高兴地宣布，Azure Boards 中工作项讨论的评论编辑和删除功能现已推出，这是一个在开发者社区中高度受欢迎的功能。 若要编辑批注，只需将鼠标悬停在拥有的任何批注上，你将看到两个新按钮。 如果单击铅笔图标，将进入编辑模式，只需进行编辑，然后按“更新”按钮保存编辑。

显示讨论注释的

单击溢出菜单时，将看到用于删除批注的选项。 单击此项后，系统会再次提示确认要删除此批注，并将删除批注。

你将在工作项窗体的“历史记录”选项卡中完整跟踪所有已编辑和已删除的批注。 你还将看到，我们更新了讨论体验的 UI，使其感觉更现代和交互。 我们添加了注释周围的气泡，以使其更清楚地说明个人评论的开始和结束位置。

将查询结果导出到 CSV 文件

现在可以直接从 Web 将查询结果导出到 CSV 格式化文件。

直接访问在任何 GitHub 注释中提到的 Azure Boards 工作项

现在，当您在 GitHub 中的问题、拉取请求或提交的评论中使用 AB#{work item ID} 语法提及一个工作项时，提到的工作项将变成可点击的超链接，您可以直接导航到该工作项。

这不会创建一个正式链接，用于整理 Azure Boards 中每个相关对话的工作项，而是为团队提供了一种在讨论代码或客户报告问题时提供有关工作项的详细信息的方法。 有关详细信息，请参阅 Azure Boards GitHub 集成 文档。

在 Azure Boards 上进行规划时，接受并处理 GitHub 的问题

现在可以将 Azure Boards 中的工作项与 GitHub 中的相关问题链接。 有了这种新型链接，现在可以使用其他几种方案。 如果你的团队希望继续接受来自用户的 bug 报告，例如，作为 GitHub 中的问题，但在 Azure Boards 中关联和组织团队的工作，现在可以了。

中的相关问题链接工作项

团队用于提交和拉取请求的同一提及语法仍然适用，当然，你可以在 Azure Boards 中手动链接到问题 URL。 有关详细信息，请参阅 GitHub & Azure Boards 文档。

在看板上快速查看已链接的 GitHub 活动

当你自己或团队查看看板时，你经常有问题，例如“此项目是否尚未开始开发？”或“此项目是否尚未审阅？”使用看板上的新 GitHub 批注，现在可以快速了解项的位置，并直接导航到 GitHub 提交、拉取请求或问题以获取更多详细信息。 请参阅 自定义卡片 文档，了解有关此内容的详细信息以及任务和测试的其他批注。

Repos

拉取请求草稿

为了防止拉取请求在尚未准备好时被完成，并能够轻松创建可能不需要涉及所有人的工作，我们现在支持草稿拉取请求。

可以通过在创建拉取请求时，从“创建”按钮的下拉列表中选择创建为草稿来创建草稿拉取请求。

在你创建草稿拉取请求之后，你会看到一个显示状态的徽章，它位于标题旁边。

草稿拉取请求默认不包括审阅者或运行构建，但允许你手动添加审阅者和运行构建。 若要将拉取请求升级为普通拉取请求，只需单击拉取请求详细信息页中的 “发布” 按钮即可。

重新运行过期的构建以自动完成拉取请求

Azure Repos 现在会自动将因拉取请求策略触发的过期的构建排入队列。 这适用于已符合所有其他策略并设置为自动完成状态的拉取请求。

以前，当拉取请求具有所需的审阅者等策略时，审批过程可能会花费过长时间，关联的构建可能会在审阅者批准拉取请求之前过期。 如果拉取请求被设置为自动完成，那么在用户手动排队并处理已过期的构建之前，该请求将保持阻塞状态。 通过此更改，构建将自动排队，以便合并请求可以在成功构建后自动完成。

注意

此自动化只会为每个拉取请求排队最多五个过期的构建，并且只会尝试对每个构建重新排队一次。

在拉取请求中仅查看左侧或右侧文件

目前，在合并请求中查看文件更改时，可以使用 并排显示 或 内联显示 模式。 我们收到了反馈，你中的许多人只想查看原始文件或已更改的文件，而无需对其进行比较，因此我们添加了一个新选项，允许你单独查看左侧文件或右侧文件。

用于完成拉取请求的新合并类型

现在，您在将拉取请求的更改合并到目标分支时有更多选项。 我们在开发人员社区添加了对两项最请求的功能的支持：Fast-Forward 合并 和 Semi-Linear 合并（也称为“重新基和合并”）。

现在，你将在 “完成拉取请求” 对话框中看到这些新选项：

更新的策略管理页允许管理员控制分支或分支文件夹中允许哪些合并策略。

注意

仍强制实施现有策略。 例如，如果你的分支当前有“仅限Squash合并”策略，那么为了使用新的合并策略，你将不得不编辑该策略。

在完成拉取请求时，有一些情况会导致无法进行变基：

• 如果目标分支上的策略禁止使用变基策略，则需要“替代分支策略”权限。
• 如果拉取请求的源分支受策略限制，则无法对其进行变基。 Rebasing 将修改源分支，而无需完成策略审批过程。
• 如果使用 合并冲突扩展 来解决合并冲突。 一次重新处理拉取请求中的所有提交时，应用于三向合并的冲突解决方法很少成功（甚至有效）。

在所有这些情况下，你仍可以选择在本地重新设置分支并推送到服务器，或者在完成拉取请求时将更改合并。

按拉取请求中的目标分支进行筛选 （PR）

拉取请求允许团队查看代码，并在将更改合并到主分支之前提供有关更改的反馈。 它们已成为许多团队工作流的重要组成部分，因为你可以逐步完成建议的更改、留下批注和投票以批准或拒绝代码更改。

为了更轻松地查找拉取请求，我们添加了一个筛选选项，用于使用目标分支搜索 PR。

您还可以通过使用目标分支筛选器来自定义 Mine 选项卡中的拉取请求视图。

允许插件添加语法高亮和自动补全

目前，我们正在发布由摩纳哥编辑器支持的一部分语言的语法高亮显示。 但是，你中的许多人希望为我们不支持的语言创建自己的语法突出显示。

通过此次更新，我们添加了一个扩展点，允许扩展将语法突出显示和自动完成功能添加到文件资源管理器和拉取请求视图。

可以在此处 找到演示此功能的扩展示例。

此外，我们还添加了对 Kusto 语言 语法突出显示的支持。

存储库创建扩展点

我们添加了一个扩展点，允许向存储库选取器添加新项。 通过此扩展点，可用于将自定义动作（重定向、弹出窗口等）添加到仓库选择菜单，从而实现备用存储库创建方案等工作流。

显示存储库创建扩展的屏幕截图

改进的编码支持

以前，在 Web 上编辑和保存文件将仅保存为 UTF-8 编码，我们在文件编码更改时没有提示你。 现在，当您尝试保存未通过 Web 编码的 UTF 的文件（仅支持 UTF 编码）时，我们将提供警告。 此外，我们还通过 Web 推送终结点添加了对 UTF-16 和 UTF-32 编码的支持。 这意味着我们将保留编码类型，因此无需将其重写为 UTF-8。

以下屏幕截图显示了在引入 Web 推送的编码更改时将看到的对话框示例。

在 Azure Repos 中获取命令支持

Go 是一种开源编程语言，也称为 Golang。 在 Go 中，可以使用 get 命令 下载和安装包和依赖项。 通过此更新，我们添加了对 Azure DevOps 存储库中 go get 的支持。 使用 go get，你将能够下载包及其依赖项，这些依赖项由导入路径命名。 可以使用 import 关键字来指定导入路径。

管道

带有适用于 YAML 管道的 IntelliSense 功能的 Web 编辑器

如果使用 YAML 定义管道，现在可以利用此版本引入的新编辑器功能。 无论是创建新的 YAML 管道还是编辑现有的 YAML 管道，都可以在管道 Web 编辑器中编辑 YAML 文件。 在编辑 YAML 文件时，使用 Ctrl+空格 来获得 IntelliSense 的支持。 你将看到突出显示的语法错误，并获取有关更正这些错误的帮助。

用于编辑 YAML 文件的任务助手

我们继续收到大量反馈，要求更轻松地编辑管道的 YAML 文件，因此我们正在向 YAML 编辑器添加任务助手。 因此，与经典编辑器中一样，你将拥有将新任务添加到 YAML 文件中的相同熟悉体验。 此新助手支持大多数常见的任务输入类型，例如选取列表和服务连接。 若要使用新的任务助手，请在基于 YAML 的管道上选择 编辑，然后选择 任务助手。

使用标记触发 YAML 管道

将标记添加到提交时，可以触发 YAML 管道。 对于工作流包括标记的团队来说，这非常有用。 例如，当提交被标记为“最后一个已知状态良好的版本”时，可以启动一个进程。

可以指定要包含和排除的标记。 例如：

trigger:
  tags:
    include:
    - releases/*
    exclude:
    - releases/old*

声明容器资源为内联

以前，我们需要在 YAML 管道中声明容器资源，然后按名称引用它们。 现在，我们提供了一种内联语法，适用于无需多次引用容器的情况。

jobs:
- job: my-container-job
  container:
    image: microsoft/dotnet:latest

设置为在更新拉取请求时自动取消现有管道

默认情况下，如果向同一拉取请求（PR）推送新的提交，则由该拉取请求触发的流水线将被取消。 在大多数情况下，这是可取的，因为通常不希望继续在过时代码上运行管道。 如果您不希望出现这样的行为，可以将 autoCancel: false 添加到您的 PR 触发器中。

pr:
  branches:
    include:
    - main
    - releases/*
  autoCancel: false

在 YAML 管道中选择检出代码的目录

以前，我们在 $（Agent.BuildDirectory）下签出到 s 目录的代码库。 现在，您可以选择要将 Git 存储库签出到的目录，以便与 YAML 管道一起使用。

在 path 上使用 checkout 关键字，你将控制文件夹结构。 下面是可用于指定目录的 YAML 代码示例。

steps:
- checkout: self
  path: my-great-repo

在这个例子中，代码将被检出到代理工作区的 my-great-repo 目录。 如果未指定路径，则代码库将继续签出到一个名为 s的目录。

针对 YAML 优化的新 Azure 应用服务任务

现在，我们支持四个新任务，这些任务提供了一种简单而强大的方法来部署 Azure 应用服务，并考虑到新式开发人员。 这些任务使用优化的 YAML 语法，使得在 Azure AppServices 上进行部署变得简单直观，包括 WebApps、FunctionApps，以及在 Windows 和 Linux 平台上的用于容器的 WebApps 和 FunctionApp。

我们还支持文件转换的新实用工具任务，以及 XML 和 JSON 格式的变量替换。

对新项目的默认权限的更改

迄今为止，项目参与者只有在被显式授予“创建生成定义”权限后，才能创建管道。 对于新项目，团队成员可以轻松创建和更新管道。 此更改将减少加入 Azure Pipelines 的新客户的摩擦。 始终可以更新参与者组的默认权限并限制其访问权限。

通过管道管理 GitHub 发布

GitHub 版本是打包和向用户提供软件的好方法。 我们很高兴地宣布，你现在可以在 Azure Pipelines 中使用 GitHub 发布任务自动执行它。 使用任务可以创建新版本、修改现有草稿/已发布版本或放弃旧版本。 它支持上传多个资产、将发布标记为预发行、将发布保存为草稿等功能。 此任务还有助于创建发行说明。 它还可以自动计算此版本中所做的更改（提交和关联问题），并采用用户友好格式将其添加到发行说明中。

下面是任务的简单 YAML：

task: GithubRelease@0 
displayName: 'Create GitHub Release'      
inputs:
  githubConnection: zenithworks
  repositoryName: zenithworks/pipelines-java
  assets: $(build.artifactstagingdirectory)/*.jar

使用此任务创建的示例 GitHub 版本：

指向生成日志中特定行的链接

现在可以在生成日志中共享指向特定行的链接。 这将帮助你在与其他团队成员协作诊断构建失败时。 只需从结果视图中选择日志行即可获取链接图标。

资源授权改进

在 YAML 文件中引用时，我们需要为受保护的资源（例如服务连接、变量组、代理池、安全文件）提供安全性。 我们希望能够让您更轻松地设置和使用管道，这些管道在非生产环境中使用此类资源。 以前，我们添加了一个设置，用于将资源标记为“已授权在所有管道中使用”。

通过此更新，即使尚未将资源标记为资源，我们也能更轻松地解决资源授权问题。 在新体验中，当构建因资源授权错误而失败时，你将看到一个选项，用于显式授权在管道中使用这些资源，然后继续进行。 有权授权资源的团队成员将能够直接从失败的构建完成这一操作。

“管道测试”选项卡中的新扩展贡献点

我们继续通过在管道中的“测试结果”选项卡中添加两个新的贡献点，使扩展框架更加强大。 这将使 市场扩展 提供更定制的报告体验，并添加进一步的交互性。

这两个贡献点是：

1. 工具栏中的“自定义操作”按钮

   有时，你可能想要执行一项作，例如使用测试结果中的元数据更新 API 数据或运行自定义工具。 使用此贡献值，可以创建扩展，通过所选测试结果的即时上下文将自定义操作添加到 *自定义操作- 按钮。

   

2. 详细信息窗格中的“自定义详细信息”选项卡

   你可能拥有各种各样的测试报告消耗工作流，并且可能希望针对失败的测试查看不同的数据点，以便进行调试和分析。 通过使用此贡献点，你的团队可以向详细信息窗格添加新选项卡，该选项卡将在数据网格中选择任何测试结果行时出现。 此新选项卡可以显示一个视图，其中包含使用内部或外部 API 提取的静态内容或动态数据。

一次性运行代理

如果使用基础结构（例如 Azure 容器实例）来运行弹性专用代理，则通常希望每个代理在离开之前只接受一个作业。 到目前为止，这并不简单，因为你必须关闭代理（可能导致故障被报告），或者接受风险在关闭代理之前，代理可能会收到新的任务。 通过此更新，我们向代理配置添加了 --once 标志。 以这种方式配置代理时，它将只接受一个作业，然后自行关闭。

代理池用户界面更新

项目设置中的代理池管理页已使用新的用户界面进行更新。 现在，您可以轻松查看所有在池中运行的作业。 您还可以了解作业未运行的原因。

向部署组中部署失败的目标进行再次部署

默认情况下，当你重新部署以前失败的运行时，Azure Pipelines 会自动重新运行所有作业。 现在，可以通过在部署时配置 部署选项 来替代此行为。 通过选择 所有作业并限制为部署组中失败的目标对象 选项，重新运行会执行所有作业，并跳过已更新目标的部署。

在失败时自动重新部署

当部署到某个阶段失败时，Azure Pipelines 现在可以自动重新部署最后一次成功的版本。 可以通过在 部署后条件中配置 自动重新部署触发器，将阶段配置为自动部署上次成功发布。 我们计划在未来的冲刺中向自动重新部署配置添加额外的触发事件和动作。 有关详细信息，请参阅 部署组 文档。

Grafana 批注服务接口

现在，我们支持一个新的服务钩子，可用于将 部署已完成 事件的 Grafana 批注添加到 Grafana 仪表板。 这样，就可以将部署与 Grafana 仪表板中可视化的应用程序或基础结构指标中的更改相关联。

查询 Azure Monitor 警报任务

查询 Azure 监视器 任务的早期版本 仅支持针对经典监控体验查询警报。 通过此任务的新版本，您可以查询由 Azure Monitor 最近引入的统一监控体验中的警报。

部署到 Kubernetes 任务中规范文件的内联输入

以前，Kubernetes 部署任务要求你提供配置的文件路径。 现在您还可以内联添加配置。

显示内联配置功能的

Docker CLI 安装程序任务

此任务允许在用户指定的代理上安装任何版本的 Docker CLI。

还原已删除的发布管道

删除未使用的发布管道有助于保持发布管道列表干净，但有时会错误地删除某些内容。 通过此更新，现在可以还原在过去 30 天内删除的发布管道。 我们在“发布”页的左侧面板中添加了一个新选项卡，该选项卡将显示已删除的发布管道列表。 在此视图中，可以通过从列表中选择管道并单击 “还原”按钮来还原已删除的发布管道。

有关发布创建请求失败的通知

可以设置通知，以便在构建、代码库和其他操作发生更改时接收电子邮件。 例如，可以设置一个警报，以便在分配给你的工作项时收到通知。

通过此更新，我们在 版本的 类别中添加了新的通知订阅。 当发布创建请求失败时，此通知将向你发送电子邮件。 在创建发布请求因为工件版本不可用而失败时，这是一个可能很有用的示例场景。 若要了解如何管理通知，请参阅此处 的文档。

在源代码或管道更改时安排发布

以前，如果有计划的发布触发器，即使上游项目或发布定义中未检测到任何更改，也会触发发布。 在计划发布触发器面板中，新增了一个选项，只有在工件版本或发布定义发生更改时才计划发布。

“创建发布”对话框中变量的贡献点

以前，在发布创建期间所需的变量值必须由用户输入，而无需任何帮助或建议。 我们已将贡献点添加到 创建新版本 对话框，以支持扩展功能，这些扩展将在发布创建期间有助于自动填充变量的值。

发布到 Azure 服务总线会话队列

我们扩展了 无代理作业 生成任务，以包括将消息发布到会话队列的功能。 此选项已添加到 发布到 Azure 服务总线 任务。

Kubernetes 服务连接中的新 Azure 订阅选项

生成和版本的服务连接允许连接到外部和远程服务以执行生成或部署的任务。 可以从项目的管理员设置中 定义和管理服务连接。

通过此更新，我们向 Kubernetes 服务连接表单添加了身份验证选项。 现在，可以选择 Azure 订阅 对连接进行身份验证。 这样就可以使用 Azure 订阅和群集名称设置 Kubernetes 连接，轻松部署到特定命名空间。

对于启用基于角色的访问控制（RBAC）的群集，将在所选命名空间中创建ServiceAccount 和 RoleBinding 对象。 RoleBinding 对象将创建的服务帐户的操作限制在所选命名空间。 对于禁用 RBAC 的群集，创建的服务帐户具有跨命名空间的群集范围权限。

Docker 注册表服务连接中的 Azure 容器注册表

现在，可以从项目的设置页创建 Docker 注册表服务连接。 若要创建连接，请在与 Azure Active Directory （AAD） 标识关联的订阅中选择一个 Azure 容器注册表。 需要与容器注册表（如 Docker@2 和 KubernetesManifest@0）建立服务连接的所有任务都将支持指定连接的单一方法。

按发布定义中的文件夹名称进行搜索

可以通过将发布定义存储在文件夹中来组织发布定义。 以前，你没有选择按文件夹执行搜索。 如果创建了大量文件夹，则很难找到特定的发布定义。 现在，可以在发布定义中按文件夹名称进行搜索，以便更轻松地查找要查找的定义。

构建和发布管道中的 Duffle 工具安装程序任务

Duffle 是一种命令行工具，可用于安装和管理云本机应用程序捆绑包（CNAB）。 使用 CNAB，可以捆绑、安装和管理容器原生应用及其服务。

在此更新中，我们添加了用于生成和发布管道的新任务，可用于安装特定版本的 Duffle 二进制文件。

Kubernetes 配置文件任务

我们向发布管道添加了一个新任务，以简化使用清单文件部署到 Kubernetes 群集的过程。 与脚本中 kubectl 二进制文件的用法相比，此任务将提供以下优势：

• 工件替换 - 部署操作接受容器映像列表作为输入，这些映像可以结合其标记或摘要进行指定。 在将清单文件应用到群集之前，会将版本信息替换到清单文件的非模板版本中，以确保群集节点能拉取到映像的正确版本。

• 清单稳定性 - 检查 Kubernetes 对象的发布状态以进行稳定性检查，并在计算任务状态为成功或失败时纳入这些检查。

• 可跟踪性批注 - 将批注添加到已部署的 Kubernetes 对象，以叠加有关发起组织、项目、管道和运行的可跟踪性信息。

• 任务中的“Bake”操作允许将 Helm 图表整合到 Kubernetes 清单文件中，以便可以应用于集群。

• 部署策略 - 选择金丝雀策略进行部署操作会导致创建后缀为 -基线 和 -金丝雀 的指定比例的工作负载，以便在 ManualIntervention 任务期间进行比较，然后利用该任务的促进或拒绝操作来最终确定要保留的版本。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

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

Docker 任务的升级

我们升级了 Docker 任务，以提升管道编写体验的简便性。 buildAndPush 命令现在可用于为特定容器存储库生成多个标记，并在一个步骤中将其推送到多个容器注册表。 该任务可以使用 Docker 注册表服务连接登录到容器注册表。 有关源存储库的可跟踪性元数据、提交和生成来源将作为标签添加到使用此任务生成的映像。

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Kubectl 工具安装程序

我们添加了一个新任务，用于在代理上安装特定版本的 Kubectl 二进制文件。 最新的 和 版本字符串（如“v1.14.0”）被接受为 Kubectl 版本规范中的有效值。

ServiceNow 集成改进

跨团队协作的关键功能是使每个团队能够使用自己选择的服务，并具有有效的端到端交付。 通过此更新，我们增强了 ServiceNow 集成，以支持所有类型的更改（正常、标准和紧急）。 此外，还可以根据组织中遵循的 ITSM 过程指定用于使用现有模板创建新的更改请求的入口。 最后，还可以根据现有更改请求限制发布。 这使你能够采用 CD，而无需更改 IT 团队建议的过程。

对 Red Hat Enterprise Linux 6 的支持

通过此更新，我们添加了对 Red Hat Enterprise Linux 6 的代理支持。 现在可以配置面向 Red Hat Enterprise Linux 6 平台的代理，以便执行生成和发布作业。

提供对 Azure PowerShell Az 模块的支持

Azure PowerShell 提供了一组 cmdlet，可用于从命令行管理 Azure 资源。 去年12月，Azure PowerShell Az 模块可用，现在是用于管理 Azure 资源的目标模块。

以前，我们不支持托管代理中的 Azure PowerShell Az 模块。 我们在生成和发布管道中支持所有平台的新 Az 模块，这是通过新发布的 Azure PowerShell 任务版本 4.* 实现的。 Azure PowerShell 任务版本 3.* 将继续支持 AzureRM 模块。 但是，为了跟上最新的 Azure 服务和功能，建议尽快切换到 Azure PowerShell 任务版本 4.* 。

Az 模块具有兼容性模式，可以帮助你在更新现有脚本以使用新语法的同时继续使用它们。 若要为 Az 模块启用兼容性，请使用 Enable-AzureRmAlias 命令。 别名使您可以在 Az 模块中继续使用旧的 cmdlet 名称。 可以在此处获取有关从 Azure RM 模块迁移到 Azure PowerShell Az 模块的更多详细信息，。

注意

如果使用专用代理，则需要在代理计算机上安装 Az 模块。

有关 Azure PowerShell Az 模块的详细信息，请参阅此处 的文档。

对 Azure SQL 任务的 Azure Active Directory （AD） 身份验证支持

除了对 SQL Server 身份验证的现有支持外，还增强了 Azure SQL 任务，以支持使用 Azure AD（集成 & 密码）和连接字符串连接到数据库。

发布包含长文件路径的构建产物

到目前为止，存在限制，阻止上传路径长度超过 233 个字符的构建工件。 这可能会阻止您从 Linux 和 macOS 构建中上传代码覆盖率结果，因为文件路径超过了限制。 限制已更新，以支持长路径。

跳过对某次提交的持续集成 (CI)

现在可以告诉 Azure Pipelines 忽略提交，并跳过运行提交通常会触发的管道。 只需在 HEAD 提交消息中包含 [skip ci]，Azure Pipelines 将跳过 CI。 还可以使用下面列出的任何变体。 支持提交到 Azure Repos Git 和 GitHub Enterprise Server。

• [skip ci] 或 [ci skip]
• skip-checks: true 或 skip-checks:true
• [skip azurepipelines] 或 [azurepipelines skip]
• [skip azpipelines] 或 [azpipelines skip]
• [skip azp] 或 [azp skip]
• ***NO_CI***

测试计划

测试结果趋势（高级）控件

测试结果趋势（高级）小组件 提供对多个生成和版本的测试数据的近实时可见性。 高级测试结果趋势小组件 显示您的测试结果在单个管道或多个管道中的趋势。 可以使用它来跟踪每日测试计数、通过率和测试持续时间。 随着时间推移跟踪测试质量并改进测试附件是维护正常运行 DevOps 管道的关键。

测试结果趋势（高级）组件 有助于在测试结果中找到离群值，并回答诸如：测试运行花费的时间是否比平常更长？ 哪些测试文件或管道会影响我的总体通过率？ 我的长期运行测试有哪些？

为了帮助您回答这些问题，小组件提供以下功能：

• 显示通过率的趋势，以及测试结果或测试持续时间的计数
• 提供基于多个构建管道或发布管道的测试结果
• 使用组合图表选项在同一趋势中显示两个指标
• 根据测试结果在一段时间内过滤测试计数
• 按分支或测试筛选你的所有测试结果
• 通过测试属性（例如 优先级 或 环境）来堆叠指标
• 在测试文件、所有者或流水线中对数据进行分组

该小组件高度可配置，可以用于各种场景。

通过 URL 共享测试运行结果

可以将自动化测试配置为作为构建或发布的一部分运行。 可以在生成或发布摘要的“测试”选项卡中查看已发布的测试结果。 通过此更新，我们添加了 复制结果 URL 功能，以便你可以与团队中的其他人共享单个测试结果。

共享级别包括：

• 运行级别
• 结果级别
• 在测试运行中选择的单个选项卡
• 共享也与配置的任何扩展选项卡兼容

共享 URL 时，查看者将在全屏视图中看到测试结果。

文物

具有 SemVer 2.0.0 版本号的 NuGet 包

以前，Azure Artifacts 不支持具有 SemVer 2.0.0 版本号的 NuGet 包（通常，包含版本生成元数据部分的版本号，由 +表示）。 现在，您可以保存来自 nuget.org 的包含生成元数据的包，并使用生成元数据推送您自己的包。 根据 SemVer 规范 和 NuGet.org 策略，生成元数据不能用于订购包。 因此，不能同时将 1.0.0+build1 和 1.0.0+build2 发布到 Azure Artifacts（或 nuget.org），因为这些版本将被视为等效版本，因此受 不可变性约束的约束的约束。

包裹的来源信息

通过此更新，我们让您更容易地了解包的出处：哪些人或哪些实体发布了这些包，以及它们来自哪个源代码提交。 使用 NuGet、npm、Maven和 Azure Pipelines 中 Twine Authenticate（用于 Python）任务发布的所有包会自动填入此信息。

包使用情况统计信息

到目前为止，Azure Artifacts 没有提供一种方法来衡量包的使用情况或受欢迎程度。 通过此更新，我们在包列表页面和包详细信息页面中添加了 下载 和 用户 的计数。 可以在任一页面右侧看到统计信息。

对 Python 软件包的支持

Azure Artifacts 现在可以托管 Python 包：包括您自制的包，以及从公共 PyPI 保存的上游包。 有关详细信息，请参阅公告博客文章和 文档。

现在，可以在同一源中托管所有 NuGet、npm、Maven 和 Python 包。

Maven 的上游源

上游数据源现在可用于 Maven 馈送。 这包括主要 Maven Central 存储库和 Azure Artifacts 源。 若要将 Maven 上游添加到现有源，请访问 源设置，选择 上游源透视，然后选择 添加上游源。

工件相关任务的代理支持

到目前为止，许多与 Artifacts 相关的生成任务没有为 Azure Pipelines 的代理基础结构提供完全支持，这导致使用来自本地代理的任务的挑战。 通过此更新，我们向以下任务添加了对代理的支持：

• Npm@1（设计器中的'npm' ）
• NuGetCommand@2（设计器中的“NuGet”）：仅限于恢复和推送命令
• DotNetCoreCLI@2（设计器中的“.NET Core”）：仅用于恢复和 nuget 推送命令
• 在设计器中，NpmAuthenticate@0、PipAuthenticate@0和TwineAuthenticate@0（“[type] 身份验证”）这些任务在获取身份验证令牌期间支持代理，但仍需配置任何后续任务/脚本/工具以使用该代理。 换句话说，这些任务不会为基础工具（npm、pip、twine）配置代理。
• 设计器中的 NuGetToolInstaller@0、NodeTool@0、DotNetCoreInstaller@0（“[type] 安装程序”）

发布版本支持的所有制品包类型

到目前为止，在 Pipelines 发布中，Azure Artifacts 工件类型 仅支持 NuGet 包。 通过此更新，支持所有 Azure Artifacts 包类型（Maven、npm 和 Python）。

发行版中支持的制品视图

以前，Azure Artifacts 的工件类型只会在新包版本发布到包源时触发。 现在，我们还添加了对视图的支持，因此，当软件源中已有的包被提升到某个视图时，可以触发发布。

保留策略可以跳过最近下载的包

到目前为止，Azure Artifacts 提供了基本的保留策略，当达到“每个包的最大版本数”时，这些策略会开始删除旧的包版本。 通过此更新，我们添加了在执行此清理时跳过最近下载的包的功能。 若要启用，请编辑你的订阅源，并选中“跳过最近下载的包”复选框。

可以管理订阅源的委托者

在 Azure Artifacts 中，项目集合管理员（PCA）始终能够管理 Azure DevOps 服务器中的所有供稿。 通过此更新，PCA 还可以向其他用户和组赋予此权限，从而委派管理任何内容源的能力。

维基

公式和视频的 Markdown 模板

编辑 Wiki 时，不再需要记住用于添加 公式、视频 和 YAML 标记 的 markdown 语法。 现在可以单击工具栏中的上下文菜单，然后选择所选的选项。

在 Wiki 中嵌入 Azure Boards 查询结果

现在可以以表格的形式将 Azure Boards 查询结果嵌入 Wiki 页面中。 下图展示了一个维基页面的样本，其中包含在知识库中嵌入的已发布功能列表以及当前冲刺中所有活跃的错误。 页面上显示的内容是通过使用现有的工作项查询获得的。 借助此功能，可以创建动态内容，无需担心手动更新 Wiki 页面。

可以在两个步骤中添加查询结果：

1. 单击编辑工具栏中的“查询结果”按钮。

2. 选择所需的查询，然后单击“插入”按钮。

保存页面后，现在可以以表的形式查看查询结果。

Wiki Markdown 编辑器的单空格字体

随着 Wiki Markdown 编辑器的单空格字体的引入，可读性不再是挑战。 Markdown 源看起来干净且易于阅读。 此功能已根据此建议票证被赋予优先级。

Wiki 页面的永久链接

直到现在，如果链接页面已重命名或移动，共享 Wiki 页面链接将中断。 现在，我们通过向 URL 添加页面 ID 来引入永久链接。 这可确保在 Wiki 随时间变化时共享的链接保持不变。

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

在 Wiki 页面中显示工作项状态

在此更新中，我们通过向页面添加工作项的状态以及其 ID 和标题，增强了 Wiki 页面中的工作项提及。

拉取请求评论和 Boards 讨论中的工作项引用也会显示工作项的状态。

@mention 用户和用户组

现在可以在 Wiki 页面中 @mention 用户和组。 这使得文档（如团队的联系人页面、指导文档和知识文档）更加丰富。 下图是一个示例，展示了包含任务和负责人信息的冲刺回顾。

显示用户和组使用 @mention 时的屏幕截图。 />

此外，还可以通过在 Wiki 编辑页面中键入“@”来从自动建议中选择用户或组。 提及的人员也将通过电子邮件收到通知。

@mention时出现的自动建议。 />

最后，你还可以点击 @mentioned 用户以查看其个人资料信息卡。 此功能的优先级是根据 功能建议 确定的。

Wiki 页面上的通知

到目前为止，你还没有办法知道 Wiki 页面上的内容何时发生更改。 现在，你可以关注Wiki页面，以便在页面被编辑、删除或重命名时通过电子邮件接收通知。 若要跟踪对 Wiki 所做的更改，请在 Wiki 页面中选择 “关注”按钮。

此功能已根据 建议单 确定优先级。 若要了解详细信息，请参阅此处 的文档。

支持 HTML 标记

现在，可以使用 HTML 标记在 Wiki 中创建更丰富的内容。 看看你能用下面的 HTML 标签做些什么。

1. 现在，可以使用 详细信息 和 摘要 标记在 Wiki 页面中创建可折叠的分区。 可以通过添加 开放的 属性来默认展开详细信息。

   

   有关 details 标签的更多信息，请查看这里的文档。

   基于此建议票证进行了优先排序。

   注意

   Edge 和 Internet Explorer 浏览器不支持此标记。

改进了表创建和编辑

到目前为止，在 Wiki 中创建和编辑表格是困难的。 我们进行了更改，以便更轻松地在 Wiki 中添加和管理表。

1. 从网格创建表

   现在您无需再记住 Markdown 表格的语法。 现在，可以通过从 15 X 15 网格中进行选择轻松创建 Markdown 表。 只需单击一下即可选择所需的列数和行以插入表格。

   

   此功能已根据以下建议单确定优先级：

   • 表格视图用于 wiki
   • 使在 wiki 中插入表变得简单

2. 更好的表可读性

   现在您可以为编辑器切换 自动换行功能，以提高表格的可读性。 禁用换行会添加滚动条，使你能够更方便地查看大型表格的内容。

   

3. 自动格式化 Markdown 表格

   现在，您无需添加空格即可自动对齐 markdown 列。 使用 格式表 按钮，可以自动调整 markdown 表格的格式，通过向单元格添加空格，使各列对齐。 如果您有大型表格，请搭配使用 禁用换行 以使表格更易于阅读。

   

   还可以使用 Ctrl + Shift + F 快捷方式设置表格格式。

报告

不再需要 Analytics 扩展即可使用 Analytics

分析正日益成为 Azure DevOps 体验不可或缺的一部分。 这是一项重要功能，能够帮助客户做出数据驱动的决策。

对于 Update 1，我们很高兴地宣布客户不再需要 Analytics 扩展才能使用 Analytics。 客户现在可以在项目集合设置下启用 Analytics。 这是一个简单的过程，就在产品中。

下面是客户如何启用 Analytics：

1. 导航到项目集合设置：

2. 单击“启用分析”

就是这样！ 将为数据集启用由分析驱动的体验。

在 Update 1 中创建的新集合，以及安装了 Analytics 扩展并升级的 Azure DevOps Server 2019 集合，将默认启用 Analytics。

若要详细了解数据分析及其所提供的体验，请执行以下步骤：

• 了解更多关于 如何启用分析功能。
• 请阅读 Analytics 概述文档。
• 了解关键功能：分析小组件、主要失败测试报告、Power BI 集成以及 OData 终结点。
• 在 Azure DevOps Analytics 上观看此第 9 频道视频。

---

反馈

我们很乐意听到你的声音！ 你可以报告问题或提供想法，并通过 开发人员社区 跟踪它，并获取有关 Stack Overflow的建议。

页面顶部

---