Azure DevOps Server 2019 Update 1 发行说明
| 开发者社区System 要求 | 许可条款 | 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 2010 或更低版本上进行 TFS 部署，需要先执行一些中间步骤，再升级到 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 修补程序 9 发布日期：2024 年 5 月 28 日
| 文件 | SHA-256 哈希 |
|---|---|
| devops2019.1.2patch9.exe | 4A3F41BBE00174DE964667878766EBF7F4D292526CBC1D885180B55D994B4D81 |
我们发布了 Azure DevOps Server 2019 Update 1.2 的修补程序 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 | 67E78EA7D67A09A6企业版06309614F92E6D8495DEF52FF442E4E7C7979244FAD20A |
我们发布了 适用于 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 ，其中包括以下修补程序：
- 修复了代理缓存文件夹使用的磁盘空间不正确且文件夹未正确清理的 bug。
- 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 任务允许对 Enable shell 任务参数参数验证的字符列表。
注意
若要实现此修补程序的修补程序，必须执行许多步骤来手动更新任务。
安装修补程序
重要
我们发布了 Azure Pipelines 代理的更新，修补程序 5 于 2023 年 9 月 12 日发布。 如果未按照修补程序 5 的发行说明中所述安装代理更新，建议在安装修补程序 6 之前安装这些更新。 安装 Patch 5 后的新版本为 3.225.0。
配置 TFX
- 遵循将任务上传到项目集合文档中的步骤进行安装，然后使用 tfx-cli 登录。
使用 TFX 更新任务
| 文件 | SHA-256 哈希 |
|---|---|
| Tasks20231103.zip | 389BA66企业版BC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5 |
- 下载并提取 Tasks20231103.zip。
- 切换到解压缩后的文件所在的目录。
- 执行以下命令以上传任务：
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 特权提升漏洞。
重要
请将修补程序部署到测试环境，并确保环境的管道按预期工作，然后将修复应用于生产环境。
注意
若要实现此修补程序的修复，必须执行许多步骤来手动更新代理和任务。
安装修补程序
- 下载并安装 Azure DevOps Server 2019 Update 1.2 修补程序 5。
更新 Azure Pipelines 代理
- 从以下位置下载代理：https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
- 使用自托管 Windows 代理文档中所述的步骤部署代理。
注意
必须将 AZP_AGENT_DOWNGRADE_DISABLED 设置为“true”以防止代理降级。 在 Windows 上，可以在管理命令提示符下使用以下命令，然后重启。 setx AZP_AGENT_DOWNGRADE_DISABLED true /M
配置 TFX
- 遵循将任务上传到项目集合文档中的步骤进行安装，然后使用 tfx-cli 登录。
使用 TFX 更新任务
- 下载并解压 Tasks_20230825.zip。
- 切换到解压缩后的文件所在的目录。
- 执行以下命令以上传任务：
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 年或更早版本升级时干扰推送包的 bug。
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 漏洞。
安装步骤
- 使用 Patch 13 升级服务器。
- 检查
HKLM:\Software\Elasticsearch\Version的注册表值。 如果注册表值不存在，请添加一个字符串值，并将版本设置为 5.4.1 (Name = Version, Value = 5.4.1)。 - 按照自述文件中的说明运行 update 命令
PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update。 它可能会返回类似于下面的警告：无法连接到远程服务器。 请勿关闭窗口，因为更新正在执行重试，直到完成。
注意
如果 Azure DevOps Server 和 Elasticsearch 安装在不同的计算机上，请按照下面概述的步骤进行操作。
- 使用 Patch 13 升级服务器。
- 检查
HKLM:\Software\Elasticsearch\Version的注册表值。 如果注册表值不存在，请添加一个字符串值，并将版本设置为 5.4.1 (Name = Version, Value = 5.4.1)。 - 将名为 zip 且位于
C:\Program Files\{TFS Version Folder}\Search\zip中的文件夹的内容复制到 Elasticsearch 远程文件文件夹。 - 在 Elasticsearch 服务器计算机上运行
Configure-TFSSearch.ps1 -Operation update。
SHA-256 哈希： 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 计算机上执行
安装
将 AzureResourceGroupDeploymentV2.zip 包解压缩到计算机上的新文件夹中。 例如： D：\tasks\AzureResourceGroupDeploymentV2。
根据需要下载并安装 Node.js 14.15.1 和 npm（随Node.js下载一起）。
在管理员模式下打开命令提示符，并运行以下命令以安装 tfx-cli。
npm install -g tfx-cli
创建具有完全访问特权的个人访问令牌并复制它。 运行 tfx login 命令时将使用此个人访问令牌。
从命令提示符下运行以下命令。 出现提示时，输入服务 URL 和个人访问令牌。
~$ tfx login
Copyright Microsoft Corporation
> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully
- 运行以下命令，将任务上传到服务器。 使用从步骤 1 中提取的 .zip 文件的路径。
~$ tfx build tasks upload --task-path *<Path of the extracted package>*
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 计算机上执行
先决条件
使用 AzurePowerShellV4 任务创建管道。 任务中只会看到一个 “标准错误 失败”。
安装
将 AzurePowerShellV4.zip 包提取到名为 AzurePowerShellV4 的文件夹。
根据计算机的要求下载并安装 Node.js 14.15.1 和 npm（包含在 Node.js 下载项中）。
在管理员模式下打开命令提示符，并运行以下命令以安装 tfx-cli。
npm install -g tfx-cli
创建具有完全访问特权的个人访问令牌并复制它。 运行 tfx login 命令时将使用此个人访问令牌。
从命令提示符下运行以下命令。 出现提示时，输入服务 URL 和个人访问令牌。
~$ tfx login
Copyright Microsoft Corporation
> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully
- 运行以下命令，将任务上传到服务器。 提取的包的路径为 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 生成定义中将“继承”更改为“开”或“关”时出现的错误。
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 发布大约三周后，数据迁移工具将可用。 可在此处查看当前支持导入的版本的列表。
此版本包含对以下 bug 的修复：
Azure Boards
- 在从产品积压工作中创建新工作项时，未使用过程模板中的默认值初始化“标题”字段。
- 使用 Azure Boards 时速度缓慢并超时。
- 工作项链接上的 Revised By 值不正确。
Azure Pipelines
- 在 Pipelines 通知中，“持续时间”等字段在某些区域设置中可能为 null。
- 模板路径可能不会指向包含 Azure 资源组部署的管道中的有效 JSON 文件。
- 集合级别保留设置页将显示在项目设置页中。
Azure Test Plans
- 在 Test Plans 中编辑字段的速度缓慢。
- 在测试用例中，从 Boards（而非 Test Plans）打开时，共享步骤详细信息不会打开。
常规
- 集合不按字母顺序排序。
管理
- 内存使用率较高。
- 具有负载平衡器配置的服务器必须将其公共源显式添加到 AllowedOrigins 注册表项。
- 在 SQL Azure 上安装的客户不会看到“完成试用”对话框。
- 安装扩展会显示错误“错误消息缺少贡献（ms.vss-仪表板s-web.widget-sdk-version-2）。
- 设置弹性搜索时，出现错误：“用户未授权”。
- 从 TFS 2018 Update 2 或更高版本升级时，弹性搜索中的索引编制和查询将失败。
- 配置 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 扩展
还可以跳转到各个部分，查看这些新功能：
常规
深色主题
深色主题是 Azure DevOps Services 上的一项常用功能，现在 Azure DevOps Server 中已提供此功能。 可以通过从每个页面右上角的虚拟形象下方的菜单中选择“主题”来打开深色主题。
Boards
新基本流程
Agile 一直以来都是新项目的默认流程，它提供一组可靠且灵活的工作项类型和状态，以满足各种项目交付方法的需要。 对于那些更熟悉其他工具或者正在不断发展并希望采用功能更强大的工具集的团队，他们想要使用更熟悉的术语来快速上手。
新基本流程提供三种工作项类型（长篇故事、问题和任务）来计划和跟踪工作。 我们建议使用问题来跟踪用户情景、bug 和功能等事项，使用长篇故事将问题组合到较大的工作单元中。 当你在工作上取得进展时，请按照“待办”、“正在进行”和“已完成”的简单状态工作流移动项目。
请参阅跟踪问题和任务文档，以帮助你开始新项目。
工作项表单上的状态值顺序
以前，工作项表单上的状态值按字母顺序排序。 通过此更新，我们更改了状态值的排序方式，以与流程设置中的工作流顺序相匹配。 你也可以在状态自定义设置的每个类别中更改状态顺序。
功能启用不再可用
客户将需要手动更新每个项目的 XML，以便在升级其集合后启用新功能。
请参阅文档以了解如何启用特定功能。
使用更丰富的工作项附件组织参考资料
通过将文件附加到工作项，你和你的团队可以集中参考材料，以便在你需要时它们总是触手可及。 现在只需将文件拖放到工作项表单上的任何位置，即可轻松添加新附件。 可以继续以列表形式查看附件，或切换到网格视图以显示缩略图预览。 双击该文件以打开预览，然后循环浏览这些内容以快速找到所需信息。
使用徽章共享团队面板
项目团队通常可通过存储库的 README，获取有关如何贡献和使用解决方案的信息。 现在，就像你可以在 Azure Pipelines 中使用生成或部署状态一样，你可以在 Azure Boards 中为你的团队面板，将徽章添加到 README 中。 可以将锁屏提醒配置为仅显示“正在进行”列或所有列，甚至可以在项目开放源代码时公开显示锁屏提醒。
如果你的 README 基于 Markdown，只需从状态徽章设置页面复制示例 Markdown，并将其粘贴到文件中即可。
查询从某日、周、月或年开始的工作
尽管团队时常专注于接下来要做的工作或基于冲刺 (sprint) 迭代的工作，但从日历角度回顾工作，报告上个月或今年第一季度发生的所有工作，这通常是有趣的。 现在，可以使用以下新的@StartOf宏集以及任何基于日期的字段根据日期、星期、月或年的开始时间进行查询：
- @StartOfYear
- @StartOfMonth
- @StartOfWeek
- @StartOfDay
其中的每个宏还接受一个新的修饰符字符串，可让你按不同的日期单位来移动数据。 例如，可以通过查询状态更改日期 = @StartOfYear 和状态更改日期 ><= @StartOfYear(“+3M” 来编写查询以查找今年第一季度完成的所有工作项。 有关详细信息，请参阅查询宏文档。
编辑和删除讨论注释
我们非常高兴地宣布推出开发者社区功能，你可在 Azure Boards 的工作项讨论中编辑和删除注释。 若要编辑批注，只需将鼠标悬停在拥有的任何批注上，你将看到两个新按钮。 如果单击铅笔图标，你将进入编辑模式，只需进行编辑并按“更新”按钮即可保存编辑内容。
单击溢出菜单时，将显示删除注释的选项。 单击此选项后，系统将再次提示你确认要删除此注释，然后该注释将被删除。
你可在工作项表单上的“历史记录”选项卡中完整跟踪所有已编辑和已删除的注释。 你还会发现，我们已更新讨论体验的 UI，使其更具现代感和交互性。 我们在注释周围添加了气泡，以使各注释的开始和结束更加清晰。
将查询结果导出到 CSV 文件
你现在可以将查询结果从 Web 直接导出到 CSV 格式文件。
直接从任何 GitHub 注释中的提及导航到 Azure Boards 工作项
现在，当你使用AB#{work item ID}语法在 GitHub 中提及问题注释、拉取请求或提交工作项时，这些提及将成为超链接，你可以单击这些超链接直接导航到提及的工作项。
这并不会为每个相关对话创建正式链接，将 Azure Boards 中的工作项弄乱，而是为你的团队提供一种方法以在讨论代码或客户报告的问题时，提供有关工作项的更多详细信息。 有关详细信息，请参阅 Azure Boards GitHub 集成文档。
在 Azure Boards 中计划时，接受并执行 GitHub 中的问题
现在你可将 Azure Boards 中的工作项链接到 GitHub 中的相关问题。 通过这种新型链接，现在可以实现几种其他方案。 如果你的团队想要继续接受来自用户的 bug 报告，例如，就像 GitHub 中的问题一样，但在 Azure Boards 中从整体上关联和组织团队的工作，现在你可以实现这一点。
你的团队用于提交和拉取请求的相同提及语法仍然适用，当然也可使用问题 URL 在 Azure Boards 中手动链接。 有关详细信息，请参阅 GitHub & Azure Boards 文档。
从看板面板快速查看链接的 GitHub 活动
当你自己或团队查看看板时，你经常有问题，例如“此项目是否尚未开始开发？”或“此项目是否尚未审阅？”通过看板上的新 GitHub 批注，现在可以快速了解项的位置，并直接导航到 GitHub 提交、拉取请求或问题以获取更多详细信息。 有关此注释以及任务和测试的其他注释的详细信息，请参阅自定义卡片文档。
Repos
草稿拉取请求
为了防止拉取请求在准备就绪之前完成，并方便创建可能不涉及每个人的正在进行的工作，我们现在支持草稿拉取请求。
在创建拉取请求时，可以通过从创建按钮下拉列表中选择创建为草稿来创建草稿拉取请求。
创建草稿拉取请求后，标题旁边将显示一个指示其状态的徽章。
默认情况下，草稿拉取请求不包括审阅者或运行生成，但允许你手动添加审阅者和运行生成。 若要将拉取请求提升为普通拉取请求，只需单击拉取请求详细信息页中的“发布”按钮即可。
为自动完成拉取请求重新运行过期的生成
Azure Repos 现在会自动将已由拉取请求策略触发的过期生成排入队列。 这适用于已通过所有其他策略并设置为自动完成的拉取请求。
以前，如果拉取请求具有必需审阅者等策略，审批过程可能需要很长时间，并且关联的生成可能会在审阅者批准拉取请求之前过期。 如果拉取请求设置为自动完成，则在用户手动排队过期的生成之前，该拉取请求将保持阻止状态。 通过此更改，生成将自动排入队列，以便在成功生成后可以自动完成拉取请求。
注意
对于一个拉取请求，此自动化最多只能将五个过期生成排入队列，并且将仅尝试对每个生成进行一次重新排队。
仅查看拉取请求中的左侧文件或右侧文件
现在，在拉取请求中查看文件更改时，可以使用并行差异或内联差异模式。 我们收到了一些反馈，其中很多人只是想要查看原始文件或已更改的文件，而无需比较这些文件，因此我们添加了一个新选项，允许单独查看左侧文件或右侧文件。
用于完成拉取请求的新合并类型
现在，在将拉取请求中的更改合并到目标分支时，你有更多选项。 我们在开发者社区添加了对两个最请求的功能的支持：快速向前合并和半线性合并（也称为“重新基和合并”）。
现在，你将在“ 完成拉取请求 ”对话框中看到这些新选项：
通过更新后的策略管理页面，管理员可以控制分支或分支的文件夹上允许哪些合并策略。
注意
仍会强制实施现有策略。 例如，如果你的分支目前已有“仅 Squash 合并”策略，则必须编辑该策略，才能使用新的合并策略。
出现以下几种情况时，不可能在拉取请求完成过程中实现变基：
- 如果目标分支上的策略禁止使用变基策略，你将需要“替代分支策略”权限。
- 如果拉取请求的源分支具有策略，则无法对其执行变基。 变基将修改源分支，而无需经过策略审批过程。
- 如果你已使用合并冲突扩展解决合并冲突。 对三向合并应用的冲突解决很少成功（甚至有效），每次重新处理一个拉取请求中的所有提交。
在所有这些情况下，你仍可以选择在本地重新对分支进行重新分组并推送到服务器，或者在完成拉取请求时将更改合并。
在拉取请求 (PR) 中按目标分支进行筛选
拉取请求允许团队查看代码，并在将更改合并到主分支之前提供有关更改的反馈。 它们已成为许多团队工作流的重要组成部分，因为你可以逐步完成建议的更改、留下注释并投票批准或拒绝代码更改。
为了方便你查找拉取请求，我们添加了筛选选项，使你可使用目标分支搜索 PR。
还可以使用目标分支筛选来自定义“我的”选项卡中的“拉取请求”视图。
允许扩展添加语法突出显示和自动完成
目前，我们针对 Monaco 编辑器支持的语言子集发布语法突出显示。 但是，你们当中的许多人想为我们未提供支持的语言创建自己的语法突出显示。
通过此更新，我们添加了一个扩展点，以允许扩展将语法突出显示和自动完成添加到文件资源管理器和拉取请求视图中。
你可在此处找到一个演示此功能的扩展示例。
此外，我们还添加了对 Kusto 语言语法突出显示的支持。
存储库创建扩展点
我们添加了一个扩展点，用于将新项添加到存储库选取器。 此扩展点允许你将自定义操作（重定向、弹出窗口等）添加到存储库选取器菜单，实现备用存储库创建方案等流。
改进的编码支持
以前，在 Web 上编辑和保存文件只会保存为 UTF-8 编码，并且当文件编码发生更改时，我们不会提示你。 现在，当你尝试通过 Web（仅支持 UTF 编码）保存非 UTF 编码的文件时，我们会向你发出一个警告。 此外，我们还通过 Web 推送终结点添加了对 UTF-16 和 UTF-32 编码的支持。 这意味着我们将保留该编码类型，因此你不必将其重写为 UTF-8。
下面的屏幕截图显示了一个对话框示例，当你通过 Web 推送引入编码更改时将显示此对话框。
Azure Repos 中的 go get 命令支持
Go 是一种开源编程语言，也称为 Golang。 在 Go 中 ，可以使用 get 命令 下载和安装包和依赖项。 通过此更新，我们添加了对 go get Azure DevOps 存储库中的支持。 使用 go get，你将能够下载包及其依赖项（由导入路径命名）。 可以使用 import 关键字指定导入路径。
管道
包含用于 YAML 管道的 IntelliSense 的 Web 编辑器
如果你使用 YAML 来定义管道，则现在可利用此版本中引入的新编辑器功能。 无论你是创建新的 YAML 管道还是编辑现有的 YAML 管道，都可以在管道 Web 编辑器中编辑 YAML 文件。 编辑 YAML 文件时，请使用 Ctrl+Space 获取 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，则会取消拉取请求 (PR) 触发的管道。 这在大多数情况下都是可取的，因为通常你不需要继续针对过期代码运行管道。 如果不希望此行为，可以将 autoCancel：false 添加到 PR 触发器。
pr:
branches:
include:
- main
- releases/*
autoCancel: false
在 YAML 管道中选择已签出代码的目录
以前，我们检查到 s $（Agent.BuildDirectory）下的目录的存储库。 现在，你可以选择要签出用于 YAML 管道的 Git 存储库。
使用path关键字 (keyword)checkout，你将控制文件夹结构。 下面是可用于指定目录的 YAML 代码示例。
steps:
- checkout: self
path: my-great-repo
在此示例中，代码将检查到my-great-repo代理工作区中的目录。 如果未指定路径，则存储库将继续检查到名为s目录的目录。
针对 YAML 优化的新 Azure App Service 任务
我们现在支持四项新任务，这些任务提供了一种简单而有效的 Azure 应用服务部署方法，适合现代开发人员。 这些任务具有经过优化的 YAML 语法，使你可以简单直观地创作到 Azure AppServices 的部署，包括 Windows 和 Linux 平台上的 WebApps、FunctionApps、WebApps for Containers 以及 FunctionApp for Containers。
我们还支持一个新的实用工具任务，可用于文件转换以及对 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 文件中引用受保护资源（例如服务连接、变量组、代理池、安全文件）时提供安全性。 同时，我们想让你更轻松地设置和使用将这些类型资源用于非生产方案的管道。 先前，我们添加了一个设置，可将资源标记为“已授权在所有管道中使用”。
此次更新后，你可以更轻松地解决资源授权问题，即使你未将资源标记为待授权。 在新体验中，当生成因资源授权错误而失败时，你将看到一个选项：显式授权在管道中使用这些资源，然后继续。 具有授权资源权限的团队成员能够直接从失败的生成中完成此操作。
“管道测试”选项卡中的新扩展贡献点
我们在管道的“测试结果”选项卡中添加了两个新的贡献点，使扩展框架的功能更强大。 这样一来，市场扩展可提供更加个性化的报告体验并进一步提升可交互性。
这两个贡献点为：
工具栏中的“自定义操作”按钮
有时，你可能想要执行类似使用测试结果中的元数据更新 API 的数据或运行自定义工具的操作。 利用此贡献点，你可以创建使用所选测试结果的直接上下文的扩展，将自定义操作添加到 *自定义操作按钮。
详细信息窗格中的“自定义详细信息”选项卡
你可能有各种不同的测试报告使用工作流，并想要查看对应于失败测试的不同数据点，以进行调试和分析。 通过使用此贡献点，你的团队可以在细节窗格中添加新的选项卡，在数据网格中选择任何测试结果行时都会显示该选项卡。 此新选项卡可以显示具有静态内容的视图或使用内部或外部 API 获取的动态数据。
运行一次代理
如果要使用基础结构（如 Azure 容器实例）来运行弹性专用代理，通常需要每个代理在关闭之前只接受一个作业。 此前，这并不容易，因为必须终止代理（可能导致报告故障）或接受代理可能在关闭之前接收其他作业的风险。 通过此更新，我们向代理配置添加了 --once 标志。 当你以这种方式配置代理时，它将只接受一个作业，然后自行关闭。
代理池用户界面更新
项目设置中代理池管理页的用户界面已更新。 现在，你可以轻松地查看正在池中运行的所有作业。 此外，还可以了解作业未运行的原因。
部署到部署组中已失败的目标
默认情况下，重新部署以前失败的运行时， Azure Pipelines 用于重新运行所有作业。 现在，可以通过在部署时配置 部署选项 来替代此行为。 通过在部署组选项中选择“所有作业”和“限制为失败的目标”，重新运行将运行所有作业，并将部署跳过到已更新的目标。
失败时自动重新部署
当部署到阶段失败时， Azure Pipelines 现在可以自动重新部署最后一个成功的部署。 可以通过在部署后条件中配置自动重新部署触发器，将阶段配置为自动部署上次成功发布。 我们计划在将来的冲刺 (sprint) 中为自动重新部署配置添加其他触发的事件和操作。 有关详细信息，请参阅部署组文档。
Grafana 批注服务挂钩
现在，我们支持一个新的服务挂钩，可用于将部署已完成事件的 Grafana 注释添加到 Grafana 仪表板。 这使你可以将部署关联到在 Grafana 仪表板中可视化的应用程序或基础结构指标更改。
查询 Azure Monitor 警报任务
以前版本的 查询 Azure Monitors 任务 仅支持针对经典监视体验查询警报。 通过该任务的这一新版本，你可以在 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 对象，以叠加有关发起组织、项目、管道和运行的可跟踪性信息。
烘焙清单 - 任务的烘焙操作允许将 Helm 图表烘焙到 Kubernetes 清单文件中，以便可以将其应用于群集。
部署策略 - 选择具有部署操作的 Canary 策略会导致创建后缀为 -baseline 和 -canary 的所需工作负荷百分比，以便在使用任务的提升/拒绝操作完成要保留的版本之前，可以在任务期间
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”等最新版本字符串和 semver 版本字符串被接受为 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 提供了一组可用于从命令行管理 Azure 资源的 cmdlet。 去年 12 月，我们发布了 Azure PowerShell Az 模块，它现在是预期用于管理 Azure 资源的模块。
以前，我们未在托管代理中为 Azure PowerShell Az 模块提供支持。 在生成和发布管道中新的 Azure PowerShell 任务版本 4.* 中，我们为所有平台添加了对新 Az 模块的支持。 Azure PowerShell 任务版本 3.* 将继续支持 AzureRM 模块。 但是，若要及时了解最新的 Azure 服务和功能，建议尽快升级到 Azure PowerShell 任务版本 4.*。
Az 模块提供了一个兼容模式，方便你在将现有脚本更新到新语法期间使用它们。 若要为 Az 模块启用兼容性，请使用 Enable-AzureRmAlias 命令。 使用别名可以将旧的 cmdlet 名称用于 Az 模块。 若要详细了解如何从 Azure RM 模块迁移到 Azure PowerShell Az 模块，请前往此处。
注意
如果使用的是专用代理，则需要在代理计算机上安装 Az 模块。
有关 Azure PowerShell Az 模块的详细信息，请参阅此处的文档。
对 Azure SQL 任务的 Azure Active Directory (AD) 身份验证支持
我们增强了 Azure SQL 任务，除了现有对 SQL Server 身份验证外的支持外，还使其支持使用 Azure AD（集成和密码）和连接字符串连接到数据库。
发布包含长文件路径的生成项目
此前存在一项限制，使得无法上传路径长度超过 233 个字符的生成项目。 因此，你可能无法从 Linux 和 macOS 版本上传文件路径超过限制的代码覆盖率结果。 现已更新该限制，支持长路径。
跳过提交的持续集成 (CI)
你现在可以使 Azure Pipelines 忽略提交，并跳过运行提交通常会触发的管道。 只需包含在 [skip ci] HEAD 提交提交消息中，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 时，观看者将在全屏视图中看到测试运行结果。
Artifacts
具有 SemVer 2.0.0 版本号的 NuGet 包
以前，Azure Artifacts 不支持具有 SemVer 2.0.0 版本号的 NuGet 包（通常，包含版本生成元数据部分的版本号，由 a +表示）。 现在，你可以从包含生成元数据的 nuget.org 保存包，并推送你自己的包含生成元数据的包。 根据 SemVer 规范和 NuGet.org 策略，生成元数据不能用于订购包。 因此，不能同时 1.0.0+build1 发布和 1.0.0+build2 发布到 Azure Artifacts（或 nuget.org），因为这些版本将被视为等效版本，因此会受到 不可变性约束的约束。
包的来源信息
通过此更新，我们使你可以更轻松地了解你的包的来源：其发布者及其源代码提交方式。 对于使用 Azure Pipelines 中的 NuGet、npm、Maven 和 Twine 身份验证（适用于 Python）任务发布的所有包，将自动填充此信息。
包使用量统计信息
此前，Azure Artifacts 未提供度量包使用量或热度的方法。 通过此更新，我们在包列表和包详细信息页中添加了“下载”和“用户”计数。 可以在其中任一页面的右侧查看这些统计信息。
对 Python 包的支持
Azure Artifacts 现在可以托管 Python 包：你自行生成的包和从公共 PyPI 保存的上游包。 有关更多详细信息，请参阅公告博客文章和文档。
现在，你可以在同一源中托管所有 NuGet、npm、Maven 和 Python 包。
Maven 的上游源
上游源现可用于 Maven 源。 这包括主要的 Maven 中央存储库和 Azure Artifacts 源。 若要将 Maven 上游添加到现有源，请访问源设置，选择上游源透视，然后选择“添加上游源”。
对 Artifacts 相关任务的代理支持
此前，许多 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] Installer”）
版本中支持的所有 Artifacts 包类型
到目前为止，在管道版本的 Azure Artifacts 项目类型中仅支持 NuGet 包。 通过此更新，支持所有 Azure Artifacts 包类型 - Maven、npm 和 Python。
各版本中支持的 Artifacts 视图
以前，仅当将新的包版本发布到源时，Azure Artifacts 项目类型才能触发。 现在，我们还添加了对视图的支持，让你可以在将源中已有的包升级为视图时触发版本。
保留策略可以跳过最近下载的包
此前，Azure Artifacts 源提供了基本的保留策略，当达到“每个包的最大版本数”时，将开始删除旧的包版本。 通过此更新，我们添加了在执行此清理时跳过最近下载的包的功能。 若要启用，请编辑源并检查最近检查框中下载的 Skip 包。
委托可以管理源的人员
迄今为止，在 Azure Artifacts 中，项目集合管理员 (PCA) 一直能够管理 Azure DevOps 服务器中的所有源。 通过此更新，PCA 还可将此功能提供给其他用户和组，从而委托管理源的能力。
Wiki
用于公式和视频的 Markdown 模板
在编辑 Wiki 时，不再需要记住用于添加公式、视频和 YAML 标记的 markdown 语法。 你现在可以单击工具栏中的上下文菜单，然后选择相应的选项。
在 Wiki 中嵌入 Azure Boards 查询结果
你现在可以在 wiki 页面中以表的形式嵌入 Azure Boards 查询结果。 下图显示了 wiki 页面的示例，其中包含已发布的所有功能，以及 wiki 中嵌入的当前冲刺 (sprint) 中所有活动 bug 的列表。 页面中显示的内容使用现有的工作项查询。 利用这项新功能，你可以创建动态内容，而不用费心手动更新 wiki 页面。
可以通过两个步骤来添加查询结果：
- 单击编辑工具栏中的“查询结果”按钮。
- 选择所需的查询，然后单击“插入”按钮。
现在可以在保存页面后以表的形式查看查询结果。
Wiki Markdown 编辑器的等宽字体
随着 wiki Markdown 编辑器中等宽字体的引入，可读性不再是一种挑战。 Markdown 源看起来干净且易于阅读。 此功能基于此建议工单确定优先级。
Wiki 页面的固定链接
此前，如果重命名或移动了链接页，共享 Wiki 页面链接将中断。 现在，我们通过将页 ID 添加到 URL，引入了固定链接。 这可确保在 wiki 发生变化时，共享的链接不会被破坏。
此功能基于此建议工单确定优先级。
在 Wiki 页面中显示工作项状态
在此更新中，我们通过将工作项的状态及其 ID 和标题添加到页面，在 Wiki 页面中更多地提及了工作项。
拉取请求注释和 Boards 讨论中的工作项引用也将显示状态。
@mention 用户和组
现在可以 @mention 在 Wiki 页面中使用用户和组。 这可以让团队的联系页面、指南文档和知识文档等文档更丰富。 下图显示了一个示例，其中显示了包含任务和负责人的冲刺 (sprint) 追溯。
@提及用户和组。” />
此外，还可以通过在 wiki 编辑页中键入“@”，从自动提示中选择用户或组。 提及的人员还将收到邮件通知。
@提及。” />
最后，还可以单击@mentioned用户以查看配置文件信息卡。 此功能基于此功能建议确定优先级。
Wiki 页面上的通知
此前，你没有办法知道 wiki 页面上的内容何时发生了更改。 现在，你可以关注 wiki 页面，以便在有人编辑、删除或重命名页面时通过电子邮件接收通知。 若要跟踪对 Wiki 所做的更改，请从 Wiki 页面中选择“ 关注 ”按钮。
此功能基于此建议工单确定优先级。 若要了解详细信息，请参阅此处的文档。
支持 HTML 标记
现在，可以使用 HTML 标记在 wiki 中创建更丰富的内容。 可使用 HTML 标记执行的操作如下所述。
现在，可以使用详细信息和摘要标记在 Wiki 页面中创建可折叠的分区。 可以添加 打开 的属性，以默认保持详细信息的展开状态。
有关详细信息标记的详细信息，请查看此处的文档。
此功能基于此建议工单确定优先级。
注意
Edge 和 Internet Explorer 浏览器不支持此标记。
改进了表创建和编辑
此前，在 wiki 中创建和编辑表非常困难。 我们进行了一些更改，让你可以更轻松地在 wiki 中添加和管理表。
从网格创建表
不再需要记住 markdown 表的语法。 现在，可以通过从 15 X 15 网格中进行选择来轻松创建 markdown 表。 选择所需的列数和行数后，只需单击一下即可插入表。
此功能基于以下建议工单确定优先级：
提升表的可读性
现在可以为编辑器切换 换 行，以便更好地阅读表格。 禁用自动换行将添加一个滚动条，通过它可以更轻松地查看大型表的内容。
自动设置 markdown 表的格式
你不必再添加空格来对齐 markdown 列。 使用“ 格式表 ”按钮，Markdown 表格会自动设置格式，方法是向单元格添加空格以对齐列。 如果有大型表，请将其与禁用换行结合使用，使表格更易于阅读。
还可以使用 Ctrl + Shift + F 快捷方式设置表格的格式。
正在报告
使用 Analytics 不再需要 Analytics 扩展
Analytics 日益成为 Azure DevOps 体验不可或缺的一部分。 对于客户来说，这是一项重要的功能，可以帮助他们做出数据驱动的决策。
关于 Update 1，我们很高兴地宣布，客户不再需要 Analytics 扩展就可以使用 Analytics 了。 客户现在可以在“项目集合”设置下启用 Analytics。 这是一个在产品内部执行的简单操作。
下面介绍客户如何启用 Analytics：
- 导航到项目集合设置：
- 单击“启用分析”
大功告成！ 随即将为集合开启由 Analytics 提供支持的体验。
Update 1 中创建的新集合和安装了已升级的 Analytics 扩展的 Azure DevOps Server 2019 集合将默认启用 Analytics。
若要了解有关 Analytics 及其带来的体验的详细信息，请执行以下操作：
- 详细了解如何启用 Analytics。
- 阅读 Analytics 概述文档。
- 了解关键功能： 分析小组件、 最高失败测试报告、 Power BI 集成和 OData 终结点。
- 观看 Azure DevOps Analytics 上的此第 9 频道视频。
反馈
我们期待你的宝贵意见和建议！ 你可以报告问题或提供想法并通过开发者社区跟踪它，并获取有关 Stack Overflow 的建议。