Azure DevOps Server 2019 发行说明
| 开发者社区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.0.1 修补程序 16 发布日期：2023 年 11 月 14 日
我们发布了 Azure DevOps Server 2019 Update 1.2 的修补程序，其中包括以下修补程序。
- 扩展了 PowerShell 任务允许对 Enable shell 任务参数参数验证的字符列表。
注意
若要实现此修补程序的修补程序，必须执行许多步骤来手动更新任务。
安装修补程序
重要
我们发布了 Azure Pipelines 代理的更新，修补程序 15 于 2023 年 9 月 12 日发布。 如果未按照修补程序 15 的发行说明中所述安装代理更新，建议在安装 Patch 16 之前安装这些更新。 安装修补程序 15 后的新版本为 3.225.0。
配置 TFX
- 遵循将任务上传到项目集合文档中的步骤进行安装，然后使用 tfx-cli 登录。
使用 TFX 更新任务
| 文件 | SHA-256 哈希 |
|---|---|
| Tasks20231103.zip | 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5 |
- 下载并提取 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.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 Server 特权提升漏洞。
重要
请将修补程序部署到测试环境，并确保环境的管道按预期工作，然后将修复应用于生产环境。
注意
若要实现此修补程序的修复，必须执行许多步骤来手动更新代理和任务。
安装修补程序
更新 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.0.1 修补程序 14 发布日期：2022 年 8 月 8 日
我们发布了 Azure DevOps Server 2019.0.1 的修补程序 ，修复了以下内容。
- CVE-2023-36869：Azure DevOps Server 欺骗漏洞。
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 漏洞。
安装步骤
- 使用 Patch 12 升级服务器。
- 检查
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 12 升级服务器。
- 检查
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 哈希： 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 的修补程序，修复了以下内容。
- CVE-2021-27067：信息泄露
若要应用修补程序 10，必须安装 AzureResourceGroupDeploymentV2 该任务。
AzureResourceGroupDeploymentV2 任务安装
注意
下面提及的所有步骤都需要在 Windows 计算机上执行
安装
将 AzureResourceGroupDeploymentV2.zip 包解压缩到计算机上的新文件夹中。 例如： 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.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 计算机上执行
先决条件
使用 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 （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 的安全修补程序 ，修复了以下内容。 有关详细信息，请参阅博客文章。
- CVE-2020-0700：跨站脚本漏洞
- CVE-2020-0758：特权提升漏洞
- CVE 2020-0815：特权提升漏洞
Azure DevOps Server 2019.0.1 修补程序 3 发布日期：2019 年 9 月 10 日
我们发布了 Azure DevOps Server 2019.0.1 的一个安全修补程序，解决了以下 bug。 有关详细信息，请参阅博客文章。
- CVE-2019-1305：Repos 中的跨站点脚本编制 (XSS) 漏洞
- CVE-2019-1306：Wiki 中的远程代码执行漏洞
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
- “测试分析”选项卡有一个指示预览的星形 ， 即使此功能不在预览中。
- 在“发布”选项卡上，现在向所有用户显示管理安全性的操作，无论他们是否可以更改权限。
- 在“发布”登录页上，“开始制作发布草稿”操作之前会创建新的发布，但现在它会启动发布草稿。
Azure Test Plans
- TestRuns 和 TestResults CompletedDate 上的 1 小时筛选器过于精细。
- 在 测试用例 工作项类型中，不应本地化类型“Test Case”。
- 测试用例不在 MTM 或浏览器中显示。
- “验证阶段：在测试计划中运行自动测试时，你无权触发关联发布管道上的发布”错误。 通过开发者社区报告。
- 使用删除测试用例 API，可以从其他项目中删除测试用例。 通过开发者社区报告。
- 单击 Test Runner 中的工作项链接后，会在 Test Runner 中打开工作项 URL，而不是从默认浏览器中打开。
- 对于要注销 Test Runner 的用户，未更新测试用例状态。
- 用户名和电子邮件地址未显示在 Test Runner 的用户下拉列表中。
Azure Artifacts
- 上 移和 下 移未本地化在上游。
分析
- Analytics 报表可能会显示不完整的数据，因为模型在实际完成之前已标记为“就绪”。
- 速度、燃尽和燃耗小组件针对不同时区的用户显示不同的计划工作。
- 执行维护时，可能会暂停 Analytics 数据引入，这可能会导致报告过时。
常规
- 当没有足够的空间时，左侧导航项会挤在 IE 上。
管理
- 集合升级中添加了更多日志记录，用于帮助调试问题。
- 当 TfsConfig offlineDetach 失败时，错误消息不可操作。
- TfsJobAgent 服务崩溃。
- 配置完成后，未安装搜索扩展。
- 当配置 DB 损坏时，管理控制台无响应。
- 服务挂钩可能无法正确处理通知。
- 配置搜索后，未启动代码搜索索引。
- 搜索页结果中存在未本地化的字符串。
此版本包括以下更新：
在 Visual studio 测试任务中支持 Visual Studio 2019 (VS2019)
我们在管道中为 Visual Studio 测试任务添加了对 Visual Studio 2019 的支持。 若要使用 Visual Studio 2019 的测试平台运行测试，请从“测试平台版本”下拉列表中选择 “最新 ”或 “Visual Studio 2019 ”选项。
Azure DevOps Server 2019 修补程序 2 发布日期：2019 年 5 月 14 日
我们发布了 Azure DevOps Server 2019 的安全修补程序 ，修复了以下 bug。 有关详细信息，请参阅博客文章。
- CVE-2019-0872：Test Plans 中的跨站点脚本编制 (XSS) 漏洞
- CVE-2019-0971：Repos API 中的信息泄漏漏洞
- CVE-2019-0979：用户中心内的跨站点脚本编制 (XSS) 漏洞
Azure DevOps Server 2019 修补程序 1 发布日期：2019 年 4 月 9 日
我们发布了 Azure DevOps Server 2019 的安全修补程序 ，修复了以下 bug。 有关详细信息，请参阅博客文章。
- CVE-2019-0857：在 Wiki 中欺骗漏洞
- CVE-2019-0866：Pipelines 中的远程代码执行漏洞
- CVE-2019-0867：Pipelines 中的跨站点脚本编制 (XSS) 漏洞
- CVE-2019-0868：Pipelines 中的跨站点脚本编制 (XSS) 漏洞
- CVE-2019-0869：管道中的 HTML 注入漏洞
- CVE-2019-0870：Pipelines 中的跨站点脚本编制 (XSS) 漏洞
- CVE-2019-0871：Pipelines 中的跨站点脚本编制 (XSS) 漏洞
- CVE-2019-0874：管道中的跨站点脚本 （XSS） 漏洞
- CVE-2019-0875：Boards 中的特权提升漏洞
Azure DevOps Server 2019 发布日期：2019 年 3 月 5 日
注意
此发布大约三周后可为 Azure DevOps Server 2019 使用数据迁移工具。 可在此处查看当前支持导入的版本的列表。
RC2 发布日期：2019 年 1 月 22 日
Azure DevOps Server 2019 RC2 中的新增功能摘要
我们已将以下功能添加到 RC2：
- 将 GitHub Enterprise 提交和拉取请求链接到 Azure Boards 工作项
- 使用 YAML 配置生成
- 卡注释包含 bug 和自定义工作项类型
- 改进的分支选取器
- 对 Artifacts 和发布管理部署管道许可的更改
RC1 发布日期：2018 年 11 月 19 日
Azure DevOps Server 2019 RC1 中的新增功能的摘要
Azure DevOps Server 2019 引入了新导航体验和许多新功能。 其中一些重要内容包括：
- 新导航体验
- 用于报告的 Analytics 市场扩展现已可用
- 支持 Azure SQL 数据库
- 新集合上的进程继承
- 新的工作项中心
- 新的板中心、积压工作 (backlog) 中心和冲刺 (sprint) 中心
- 新的查询中心
- 使用模板实现拉取请求说明标准化
- 更改拉取请求的目标分支
- 使用新的“生成”页管理生成管道
- 使用新的“发布”页管理发布管道
- 直观显示发布进度
- 本地更新代理
- 使用发布入口逐步公开并分阶段部署
- 上游源
- 为 wiki 页面创建目录
还可以跳转到各个部分，查看这些新功能：
常规
宣布推出 Azure DevOps Server
9 月 10 日，我们宣布推出了 Azure DevOps，它是 Visual Studio Team Services 和 Team Foundation Server 的进化版。 Azure DevOps Server 2019 是我们在该新品牌下发布的第一个本地版本。 你可以在博客文章中找到详细信息。
新导航体验
我们引入了新的导航体验，以使用户体验新式化。 此新导航体验已推出到 Azure DevOps 服务，现可在 Azure DevOps Server 2019 中使用。 有关详细信息，请参阅我们的博客。
对 Artifacts 和发布管理部署管道许可的更改
根据用户反馈，我们将对 Azure DevOps Server 2019 许可进行两项关键更改。 首先，客户不再需要购买 Artifacts 扩展即可使用 Artifacts。 现在，基本许可证中将包含 Artifacts 许可证的使用权限。 分配了基本许可证的所有用户现在都可以使用 Artifacts。 其次，客户不再需要购买发布管理部署管道。 与生成管道一样，发布管理部署管道现在包含在 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 中任何服务页上的“/”，即可调用搜索框。
下面是默认的搜索框：
键入“/”后，随即显示扩展搜索框：
“我的工作”浮出控件
我们非常高兴引入的一个新功能是我的工作浮出控件。 我们听到了这样的反馈，就是当你位于产品的某个部位时，你想获得其他部位显示的一些信息，但你又不想退出当前的上下文。 使用此新功能，你可以从产品的任何位置访问此浮出控件，并可以快速浏览关键信息，包括工作项、拉取请求和所有收藏夹。 使用这一新的浮出控件，如果你在存储库埋头编写代码，但是随后要快速检查接下来应处理的工作项，则只需单击此浮出控件，便可查看分配给你的工作项并选取下一项。
在下面可以看到我的工作浮出控件，其中显示分配给我的工作项：
在这里，你可以看到第二个透视，其中显示了分配给我的拉取请求。 在浮出控件中，你还可以通过一次单击查看更多拉取请求：
在这里，你可以看到最后一个透视，它是已收藏的全部内容。 这包括你收藏的团队、仪表板、板、积压工作 (backlog)、查询和存储库：
Boards
将 GitHub Enterprise 提交和拉取请求链接到 Azure Boards 工作项
使用 GitHub Enterprise 编写代码并希望拥有丰富的项目管理功能的团队现在可以将其存储库与 Azure Boards 集成。 通过连接 GitHub 和 Azure Boards，你可以获得所有相关功能，如积压工作 (backlog)、板、冲刺 (sprint) 计划工具、多种工作项类型，并可适应与 GitHub 中的开发人员工作流集成的工作流。
将提交和拉取请求链接到工作项非常简单。 使用以下语法提及工作项：
AB#{work item ID}
在提交消息、拉取请求标题或拉取请求说明中提及某个工作项，Azure Boards 就会创建指向该项目的链接。 例如，请考虑如下所示的提交消息：
Adds support for deleting connections. Fixes AB#20.
这会创建工作项 #20 与 GitHub 中提交之间的链接，该链接将显示在工作项的“开发”部分中。
如果在工作项提及之前添加“修复”或“已修复”字样（如上所示），当提交合并到默认分支时，工作项将转换到“完成”状态。
使用 Azure Pipelines 在 GitHub 中生成代码的团队还可以在生成摘要中看到链接到其 GitHub 提交的工作项。
新的工作项中心
“工作项”中心是我们作为“工作项之家”的新中心！ 这里提供许多不同的工作项列表视图，并已划分好范围。 可以查看分配到我以快速浏览分配给你的所有工作，或是向你显示项目中最近更新的所有工作项的最近更新。 下面列出了所有列表选项：
如果要将进一步细化列表范围，可以按类型、分配对象、状态、区域、标记和关键字进行筛选。 获得所需的列表视图后，只需单击该列的标头即可对工作项进行排序。 如果一列太窄，无法查看列的全部内容，可以在标头区域中轻松地调整列的大小。 这些体验如下所示：
新的板中心、积压工作 (backlog) 中心和冲刺 (sprint) 中心
积压工作 (backlog) 中心划分为三个不同的中心，以改进用户体验。 虽然其功能强大，但旧的积压工作 (backlog) 中心的功能过多。 用户通常很难找到想要的功能。 为了解决此问题，我们将积压工作 (backlog) 中心拆分为：
- 积压工作 (backlog) 中心现在仅容纳项目的积压工作 (backlog)。 积压工作 (backlog) 是按优先级排序的一系列团队工作。 积压工作 (backlog) 提供计划工具，如工作项层次结构、预测和新的冲刺 (sprint) 计划体验。
- 新的板中心容纳项目的所有看板。 板用于传达状态和流信息。 卡（工作项）通过团队定义的列在板上从左向右移动。
- 新的冲刺 (sprint) 中心容纳用于计划和执行工作增量的功能。 每个冲刺 (sprint) 都包含一个冲刺 (sprint) 积压工作 (backlog)、一个任务板和一个用于管理和设置团队容量的视图。
新的查询中心
新的查询中心简化了旧中心的许多现有查询功能，具有更新式的外观，并提供了新功能，使你可以更轻松地找到对你来说很重要的查询信息。 新体验的一些重要内容包括：
- 具有“上次修改者”信息和查询搜索功能的目录页
- 带有文件夹唯一 URL 的痕迹导航，用于为重要的查询组添加书签
- 从结果页面对收藏夹查询进行的快速访问
在 DevOps 博客上详细了解这些令人兴奋的更新。
将工作项移动到另一个项目并更改工作项类型
你现在可以更改工作项类型或将工作项移动到项目集合中的另一个项目。 这些功能需要禁用数据仓库。 在禁用了数据仓库的情况下，可以使用 Analytics Service 为报告需求提供支持。 要详细了解如何禁用数据仓库，请参阅禁用数据仓库和多维数据集。
冲刺 (sprint) 计划功能
新的冲刺 (sprint) 计划功能有助于加快和优化冲刺 (sprint) 计划体验。
- 直接从 Sprints 中心创建下一个冲刺计划或订阅现有冲刺计划。
- 使用积压工作 (backlog) 中新的计划窗格将工作项拖放到将来的冲刺 (sprint) 中。 计划窗格包括冲刺 (sprint) 日期、工作项计数和计划工作量。
- 将要求添加到任务板顶部或使用快速创建添加到冲刺 (sprint) 积压工作 (backlog) 的顶部、底部或所选行。
- 为“被分派人”、“工作项类型”、“状态”和“标记”使用筛选器，以根据需要调整视图。
新目录页
所有新的中心（包括积压工作 (backlog)、板和冲刺 (sprint)）现在具有使用以下部分进行组织的新目录页面：
- 从离开的位置继续 这一新部分提供直接指向你所处的最后一个（板 | 积压工作 (backlog) |冲刺 (sprint)）的快速链接。
- 收藏夹 在所有团队间收藏的所有板、冲刺 (sprint) 和积压工作 (backlog)。
- 我的 你所属团队的所有板、积压工作 (backlog)和冲刺 (sprint)。
- 全部 所有板、积压工作 (backlog)和冲刺 (sprint) 的完整列表。
新视图选项菜单
新中心（包括积压工作 (backlog)、板和冲刺 (sprint)）具有新的视图选项菜单。 这是用于自定义布局和页内容的所有操作的新主页。 使用视图选项可启用其他视图（如显示积压工作 (backlog) 中的层次结构或更改任务板上的分组依据选项）以打开侧面板来映射和计划冲刺 (sprint)，或浏览工作详细信息图表。
在 DevOps 博客上详细了解这些令人兴奋的更新、新的团队配置文件窗格和收藏夹。
卡注释包含 bug 和自定义工作项类型
卡注释因其直观的检查列表视图和交互而深受欢迎。 以前，卡注释仅限于默认的积压工作 (backlog) 级别类型，不支持 Bug 或自定义类型。 在新版本中，我们删除了对工作项类型的限制，并添加了将 Bug 和任何自定义工作项类型显示为卡注释的功能。
卡注释的板设置已扩展为包含可用于该积压工作 (backlog) 级别的所有工作项类型。
启用工作项注释后，该工作项类型的计数将作为单独的检查列表包含在卡上。
还可以通过卡上下文菜单快速创建启用的工作项类型。
使用建议的区域和迭代移动工作
经常会有这样的情况：在同一区域或迭代中工作，并且在移动工作项时反复浏览层次结构。 区域和迭代路径控件现在以建议的形式包含最近使用的值的列表，从而使你可以快速访问以进行设置并继续处理。
此外，迭代日期包含在名称右侧，以便可以快速判断何时应传递工作项。
使用 +/- 跨迭代计划查询工作 @CurrentIteration
帮助 @CurrentIteration 团队根据迭代计划跟踪工作的宏现在支持整数偏移量。 使用 - 1 轻松保留未关闭 @CurrentIteration 的工作的选项卡，或者查看计划用于将来使用 @CurrentIteration + 1 迭代的工作。 有关详细信息，请参阅 Microsoft DevOps 博客上的 @CurrentIteration 帖子。
使用 @CurrentIteration Team 参数阐明查询迭代计划
如果过去一直在 @CurrentIteration 查询中使用宏，则可能已经注意到，如果团队上下文因不同的迭代计划而更改 Teams 中的团队上下文，则结果可能会有所不同。 现在，使用宏创建或修改查询 @CurrentIteration 时，还需要选择与查询相关的迭代计划的团队。 使用 Team 参数，可以在同一查询中使用宏，但跨团队使用 @CurrentIteration 。 一个示例可能是查询使用不同迭代名称甚至计划的两个不同团队项目中的工作项。 这意味着在冲刺 (sprint) 更改时，无需更新查询！ 有关详细信息，请参阅 Microsoft DevOps 博客上的 @CurrentIteration 帖子。
使用新 @TeamAreas 宏在团队的区域路径中查询工作
在团队设置中，可以关联一个或多个区域路径，这可帮助侧重于积压工作 (backlog)、板、计划，甚至是仪表板，以便仅为该团队而工作。 但是，如果要为团队编写查询，你必须在查询子句中列出该团队的特定区域路径。 现在，可以使用新的 @TeamAreas 宏轻松引用指定团队拥有的区域路径。
查询空的格式文本字段
使用新的 IsEmpty 查询运算符可查找具有空格式文本字段（例如“说明”）的工作项。
轻松查找链接和提及体验中的现有工作项
如果要将两个现有的工作项链接在一起，现在可以使用新的工作项搜索控件轻松找到对你很重要的项。 查询选择器已替换为基于最近访问的工作项的内联建议，以及按 ID 或标题搜索特定工作项的入口点。
从搜索中打开工作项
以前，如果工作项预览窗格处于关闭状态，则无法从搜索结果页打开工作项。 这将使你难以深入了解搜索结果。 现在，你可以单击工作项标题，在模式窗口中打开工作项。
Repos
改进的分支选取器
Azure Repos 中的大多数体验要求选择一个存储库，然后选择该存储库中的一个分支。 为了面向具有大量分支的组织改进这一体验，我们将推出新的分支选取器。 现在，使用该选取器可以选择所需分支或快速搜索分支。
绕过拉取请求策略时接收通知
对于使用拉取请求 (PR) 和分支策略的团队而言，可能会出现需要替代和绕过这些策略的情况，例如，在午夜针对生产问题部署修补程序时。 值得一提的是，应该相信开发人员能够做出正确操作和慎用替代功能。 同时，团队需要一种方法来验证是否在正确的情况下使用了这些策略替代功能。 为此，我们添加了新的通知筛选器，允许用户和团队在绕过策略时接收电子邮件警报。 首先使用创建或更新拉取请求模板，从筛选器的列表中选择策略绕过。 选择已绕过策略作为值，每当 PR 完成并绕过策略时，你都会收到通知。
在不放弃推送保护的情况下允许绕过分支策略
在某些情况下，有时需要绕过分支策略 - 还原导致生成中断的更改、在午夜应用修补程序等。以前，我们提供了权限（“免除策略强制实施”），以帮助团队在完成拉取请求时能够绕过分支策略。 但是，该权限还授予了直接推送到分支的能力，完全绕过 PR 过程。
为了改进此体验，我们拆分了旧的权限，以便为授予绕过权限的团队提供更多的控制。 有两个新权限可以替换旧权限：
- 完成拉取请求时绕过策略。 具有此权限的用户能够对拉取请求使用“替代”体验。
- 推送时绕过策略。 具有此权限的用户将能够直接推送到配置了所需策略的分支。
通过授予第一个权限并拒绝第二个权限，用户将能够在必要时使用绕过选项，但仍可防止意外地推送到具有策略的分支。
注意
此更改不引入任何行为更改。 以前针对“免除策略实施”被授予了允许的用户会针对这两个新权限被授予允许，因此他们能够同时替代 PR 完成时和直接推送到具有策略的分支。
有关详细信息，请参阅设置分支权限文档。
使用提交消息快速说明拉取请求
编写说明性提交消息会将值添加到任何 Git 存储库的历史记录中。 为了鼓励高质量的提交消息，具有多个提交的新拉取请求 (PR) 将需要参与者手动输入标题。
默认情况下，拉取请求说明将继续为空，但新功能会使 PR 提交中的提交消息更容易合并到 PR 说明中。 若要添加提交消息，只需单击添加提交消息以将提交消息追加到 PR 描述文本末尾。
在没有默认团队作为审阅者的情况下创建拉取请求
当我们首次启动拉取请求 (PR) 体验时，我们认为将所有 PR 分配给创建 PR 时选择的团队上下文是有意义的。 此行为一直让操作者觉得不方便，因为许多人没有注意到团队上下文与 PR 分配之间的关联。
在新的导航更改中，我们利用这个机会更改了与团队的这个默认关联。 你将注意到两个更改：
- 在创建 PR 时，默认情况下不会添加任何审阅者。 审阅者列表有一项功能，可让你更轻松地添加最近添加到 PR 的个人和组。 所需的审阅者策略还可以帮助希望确保添加特定审阅者以审阅其代码的团队。
- 拉取请求中心具有一个新的可自定义部分。 默认情况下，此部分显示“分配给我的团队”的拉取请求，提供与旧版等效的功能。 但是，如果你属于多个团队，此部分将显示分配给你的任何团队的拉取请求。 此部分也可以自定义，只需单击该部分标头旁边的“自定义此视图”操作即可。
使用模板实现拉取请求说明标准化
编写良好的拉取请求描述是帮助审阅者了解审阅代码时的预期内容的好办法。 它们也是帮助跟踪应对每个更改执行的操作（如测试、添加单元测试和更新文档）的好办法。 你们中的许多人一直请求我们添加拉取请求模板，以使团队更轻松地编写重要说明，我们现在添加了该功能。
除了支持默认的拉取请求说明模板以外，团队还可以添加多个模板，这些模板将在“创建拉取请求”页上的菜单中显示。 只需单击添加模板按钮即可从存储库中的任何模板进行选择，以将它追加到 PR 描述中。
如果要将拉取请求的其他模板应用到特定分支或分支文件夹中，还支持使用特定于分支的模板。 例如，如果想要拥有特定于所有以“hotfix/”开头的分支的模板，则可以将用于所有拉取请求的模板添加到这些分支中。
请参阅拉取请求模板文档，了解有关如何创建和使用模板的详细信息。
更改拉取请求的目标分支
对于大多数团队，几乎所有拉取请求都面向同一分支，例如main或develop。 但是，在确实需要针对其他分支的情况下，很容易忘记将默认值更改为目标分支。 现在，借助可更改活动拉取请求的目标分支的新功能，这变成了一个简单的操作。 只需在拉取请求头中单击目标分支名称附近的铅笔图标。
除了更正错误外，借助更改目标分支的功能，还能够在合并或删除目标分支后轻松将其他拉取请求作为目标。 考虑这样一种场景：你有一个拉取请求，其以功能分支为目标，该分支包含一些“更改”所依赖的功能。 你希望与功能分支中的其他更改隔离查看依赖更改，以便最初确定目标features/new-feature。 然后，审阅者只能看到你的更改，并留下适当的评论。
现在，请考虑如果功能分支也处于活动状态并合并到main更改之前会发生什么情况？ 以前，必须放弃更改并创建新的 PR， main或将 PR 合并到该 PR 中 features/new-feature，然后从 features/new-feature 中 main创建另一个 PR。 使用此新操作更新目标分支，只需将 PR 的目标分支更改为features/new-featuremain保留所有上下文和注释。 更改目标分支甚至会为 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 编辑器中显式保存管道。
使用生成完成触发器将相关生成链接在一起
大型产品具有多个相互依赖的组件。 这些组件通常独立生成。 当上游组件（例如库）发生更改时，下游依赖项必须重新生成并重新验证。 团队通常会手动管理这些依赖项。
现在，你可以在成功完成一个生成后触发另一个生成。 上游生成生成的项目可以在以后的版本中下载和使用，还可以从以下变量中获取数据：Build.TriggeredBy.BuildId、Build.TriggeredBy.DefinitionId、Build.TriggeredBy.BuildDefinitionName。 有关详细信息， 请参阅生成触发器 文档。
请记住，在某些情况下，单个多阶段生成可以满足你的需求。 但如果你的需求涉及不同配置设置、选项或拥有相关流程的其他团队，则生成完成触发器非常有用。
本地更新代理
从库中安装的任务有时需要较新版本的管道代理。 如果 Azure DevOps Server 可以连接到 Internet，则会自动下载较新版本。 如果不可以，则必须手动升级每个代理。 从此发布开始，可以将 Azure DevOps Server 配置为在其本地磁盘中（而不是从 Internet）查找代理包文件。 这使你可以灵活地控制要提供哪些代理版本，而无需将 Azure DevOps Server 公开到 Internet。
新生成状态徽章 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 策略，然后将这些策略从发布定义本身分配给资源、订阅或管理组。
在 Linux/ARM 和 Windows 32 位平台上生成
Azure Pipelines 开放源代码、跨平台代理始终在 64 位 （x64） Windows、macOS 和 Linux 上受支持。 在此版本中，我们将引入两个新的受支持平台： Linux/ARM 和 Windows/32 位。 使用这些新平台，可以在不太常见但同样重要的平台（例如 Raspberry Pi，一种 Linux/ARM 计算机）上生成。
改进了 Pipelines 中的测试体验
测试选项卡现在具有现代体验，可针对管道提供丰富的上下文中测试信息。 新体验提供了正在进行的测试视图、整页调试体验、上下文中测试历史记录、报告中止的测试执行以及运行级摘要。
查看正在进行的测试的执行
测试（例如集成和函数测试）可长时间运行，因此，请务必在任意特定时间查看测试执行情况。 有了正在进行的测试视图，不再需要等待测试执行完成即可知道测试结果。 在测试开始运行时即可近乎实时地获得结果，有助于更快地采取措施。 可以调试失败或中止、提交 bug 或中止管道。 该功能当前可用于多代理阶段中使用 VS 测试任务的生成和发布管道、使用发布测试结果任务或是使用 API 发布测试结果。 未来，我们计划将这种体验扩展到使用 Single Agent 的测试执行过程。
以下视图在新的发布进度视图中显示了“正在进行的测试”摘要，报告了特定时间点的总测试数和测试失败次数。
通过单击上面的正在进行的测试摘要，可以在测试计划中查看详细测试摘要以及失败或已中止测试信息。 测试摘要会定期更新，并且可以根据新结果的可用性按需刷新详细信息视图。
在整页视图中查看测试运行调试详细信息
错误消息和堆栈跟踪本质上相当冗长，需要足够的空间才能查看调试期间的详细信息。 要获得沉浸式调试体验，现在可以将测试或测试运行视图扩展为整页视图，同时仍然可以执行所需的上下文中操作，例如创建 bug 或关联当前测试结果的需求。
在上下文中查看测试历史记录
在历史上，团队必须转到运行中心，才能查看测试结果的历史记录。 借助新体验，我们直接在测试计划选项卡的上下文中提供生成和发布的测试历史记录。 测试历史记录信息以渐进方式提供，先提供所选测试的当前生成定义或环境，然后分别提供生成和发布的其他分支和环境。
查看已中止的测试
测试执行可能因多种原因（例如测试代码不佳、源处于试验阶段以及环境问题）而中止。 无论因和原因而中止，请务必调查行为并确定根本原因。 现在可以在测试计划中查看已中止的测试和测试运行以及已完成的运行。 该功能当前可用于多代理阶段中使用 VS 测试任务的生成和发布管道或是使用 API 发布测试结果。 未来，我们计划将这种体验扩展到使用 Single Agent 的测试执行过程。
测试历史记录中的测试可跟踪性和发布环境支持
我们添加了对查看自动测试历史记录的支持，该历史记录按运行测试的各种发布环境进行分组。 如果将发布环境建模为发布管道或测试环境，并在此类环境中运行测试，则可以发现尽管在开发环境中通过了测试，但在集成环境中测试却失败。 可以发现，尽管在使用英语区域设置时通过了测试，但在采用土耳其区域设置的环境中测试却失败。 对于每个环境，你可发现最新测试结果的状态，如果该环境中的测试失败，你还可发现从哪个发布开始测试始终失败。
查看汇总的测试结果
在测试执行期间，测试可能会生成多个测试实例，它们都会参与形成整体结果。 其中一些示例包括：因失败而重新运行的测试、由其他测试按顺序组合而成的测试（例如顺序测试）或基于提供的输入参数包含不种实例的测试（数据驱动的测试）。 由于这些测试是相关的，因此需要将其与基于各个测试结果所得出的总体结果一起报告。 在此更新中，我们引入了改进版本的测试结果，它们在发布的测试选项卡中显示为层次结构。 我们来看一个示例。
以前，我们在 VS 测试任务中引入了重新运行失败的测试这一功能。 但我们仅在最后一次尝试测试后才进行报告，这在某种程度上限制了此功能的实用性。 现在，我们扩展了此功能，在每次尝试后报告一个测试执行实例。 此外，测试管理 API 现在支持发布和查询分层测试结果。 有关详细信息，请参阅测试结果 API 文档。
注意
测试摘要部分中的指标（例如测试总数、已通过等）使用层次结构的根级别（而不是测试的每个单独迭代）进行计算。
在管道中查看测试分析
持续跟踪测试质量并改进测试附件是维持管道正常运行的关键。 使用测试分析功能可近乎实时地查看生成和发布管道的测试数据。 该功能可通过识别重复且严重影响质量的问题来帮助提高管道效率。
可以按各种元素对测试结果进行分组、确定分支或测试文件的关键测试，或深入了解特定测试，以查看趋势并了解质量问题（例如测试不可靠）。
有关详细信息，请参阅我们的文档。
简化包含多个无代理任务的定义
无代理阶段的任务由服务器安排，并在该服务器上执行。 无代理阶段不需要代理或任何目标计算机。 与代理阶段不同，只能向定义中的每个无代理阶段添加一个任务。 这意味着如果进程中存在多个无代理任务，则必须添加多个阶段，这将导致定义非常庞杂。 我们放宽了该限制，使你可以在无代理阶段维护多个任务。 与代理阶段一样，同一无代理阶段中的任务将按顺序执行。 有关详细信息，请参阅服务器阶段文档。
使用发布入口逐步公开并分阶段部署
使用发布入口，可以指定将发布提升到下一个环境之前必须满足的应用程序运行状况条件。 在部署之前或之后将定期评估所有指定入口，直到全部部署成功。 四种类型的入口立即可用，并且可以从市场添加更多入口。 你可以审核是否满足部署的所有必需条件。 请参阅发布入口文档获取详细信息。
保持部署，直到入口持续成功
使用发布入口，可以在将发布提升到下一个环境之前自动评估运行状况条件。 默认情况下，收到所有入口的一个成功示例后，发布将继续工作。 即使入口不稳定，且收到的成功示例是噪音，发布仍将继续工作。 为避免这些类型的问题，现在可以配置发布，以验证发布前最短持续时间内运行状况的一致性。 在运行时，发布将先确保对入口的连续评估结果为成功，然后再允许提升。 评估的总时间取决于“两次评估之间的间隔时间”，通常会超过配置的最短持续时间。 有关详细信息，请参阅使用入口的发布部署控制文档。
自动部署到部署组中的新目标
以前，将新目标添加到部署组时，需要通过手动部署确保所有目标具有相同的发布。 现在，可以将环境配置为将上一个成功的发布自动部署到新目标。 有关详细信息，请参阅部署组文档。
连续部署由生成后处理标记的生成
连续部署触发器在完成生成时创建发布。 但是，有时生成会进行后期处理，只应在该处理完成之后才发布生成。 现在，可以在发布的触发器筛选器中利用后期处理期间分配的生成标记。
在发布时设置变量
现在，可在发布定义中选择要在创建发布时设置的变量。
创建发布时为变量提供的值仅用于该发布。 此功能可帮助你避免执行以草稿状态创建的多个步骤、更新草稿中的变量以及使用变量触发发布。
将环境变量传递到任务
CI/CD 任务作者可以在 task.json 中设置新属性 showEnvironmentVariables，用于将环境变量传递到任务。 执行此操作时，生成编辑器中的任务上将呈现一个额外控件。 此可用于 Powershell、Cmd 和 Bash 任务。
这可以实现两种方案：
- 任务需要环境变量，且变量名称中保留大小写。 例如，在上述示例中，传递到任务的环境变量将是“foo”而不是“FOO”。
- 这允许将机密值以安全的方式传递到脚本。 这比将机密作为参数传递到脚本更有优势，因为代理上的操作系统可能会记录包含其参数的进程的调用。
克隆变量组
我们添加了对克隆变量组的支持。 如果你想要复制变量组且只想更新少量变量，你无需进行逐一添加变量的繁琐过程。 现在，你可以快速复制变量组、更新相应的值，然后将其另存为新的变量组。
注意
克隆变量组时，不会复制机密变量值。 你需要更新已加密的变量，然后保存已克隆的变量组。
忽略部署的发布入口
使用发布入口，可以在将发布提升到下一个环境之前自动评估运行状况条件。 默认情况下，仅当所有入口同时处于正常状态时，发布管道才会继续工作。 在某些情况下（例如加快发布时或手动检查运行状况之后），即使尚未评估入口是否正常，审批者也可能想要忽略该入口，然后允许发布继续工作。 有关详细信息，请参阅发布入口文档。
使用拉取请求发布触发器执行其他测试
你已经能够基于拉取请求 (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 容器
Azure App 服务部署任务的 4.* 版本现在支持将自己的自定义容器部署到 Linux 上的 Azure Functions。
Azure Functions 的 Linux 托管模型基于 Docker 容器，利用这些容器，可更灵活地打包和利用特定于应用的依赖项。 Linux 上的 Functions 可以托管在两种不同的模式中：
- 内置容器映像： 引入 Function App 代码，Azure 提供和管理容器（内置映像模式），因此不需要特定的 Docker 相关知识。 应用服务部署任务的现有版本支持此模式。
- 自定义容器映像：我们增强了App 服务部署任务，以支持将自定义容器映像部署到 Linux 上的 Azure Functions。 当函数需要特定的语言版本，或者需要内置映像中未提供的特定依赖项或配置时，可以使用 Azure Pipelines 在 Linux 上生成自定义映像并将其部署到 Azure Function。
Xcode 任务支持新发布的 Xcode 10
与 Apple 的 Xcode 10 发布相同，你现在可以将项目设置为生成，或设置为专门使用 Xcode 10 进行测试。 你的管道还可以与 Xcode 版本的矩阵并行运行作业。 可以使用 Microsoft 托管的 macOS 代理池运行这些生成。 请参阅指南，了解如何在 Azure Pipelines 中使用 Xcode。
使用 Helm 简化部署到 Kubernetes 的过程
Helm 是一种工具，可简化 Kubernetes 应用程序的安装和管理。 去年，它还获得了众多用户和社区支持。 发布中的 Helm 任务现在可用于打包 Helm 图表并将其部署到 Azure 容器服务（AKS）或任何其他 Kubernetes 群集。
添加该 Helm 任务后，现可以设置基于 Helm 的 CI/CD 管道，以将容器交付到 Kubernetes 群集。 有关详细信息，请参阅使用 Kubernetes 部署到 Azure 容器服务文档。
控制发布中使用的 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 工具，然后将其添加到生成代理的 PATH 中。 如果代理中已安装目标版本的 Go 工具，则此任务将跳过重新下载并安装它的过程。
Go 任务可帮助下载依赖项、生成或测试应用程序。 你还可以使用此任务来运行所选的自定义 Go 命令。
在管道中运行内联的或基于文件的 Python 脚本
新的 Python 脚本任务简化了在管道中运行 Python 脚本。 该任务将从存储库中的 Python 文件 (.py) 运行脚本，或者你可以在任务的设置中手动输入脚本，以将其另存为管道的一部分。 该任务将在路径中使用 Python 的版本，或者你可以指定要使用的 Python 解释器的绝对路径。
利用 xcpretty 中改进的 Xcode 生成和测试输出
xcpretty 增强了 xcodebuild 输出的可读性，并以 JUnit 格式生成了测试结果。 现在，Xcode 生成任务与在托管的 macOS 代理上一样，在代理计算机上（如果可用）自动使用 xcpretty。 尽管 xcpretty 输出可能与 xcodebuild 输出不同且不如后者详细，但我们提供了每个生成的完整 xcodebuild 日志。
测试计划
使用 Test Runner (Azure Test Plans) 客户端运行桌面应用程序的手动测试
现可使用 Test Runner (Azure Test Plans) 客户端运行桌面应用程序的手动测试。 这可帮助你从 Microsoft 测试管理器迁移到 Azure Test Plans。 请在此处参阅我们的指南。 可以使用 Test Runner 客户端运行手动测试并记录每个测试步骤的测试结果。 此外，还可以使用数据收集功能，例如屏幕截图、图像操作日志和音频视频录制。 如果在测试时发现问题，请使用 Test Runner 创建一个 Bug，该 Bug 中会自动包含测试步骤、屏幕截图和注释。
Test Runner (Azure Test Plans) 需要一次性地下载并安装运行程序。 选择为桌面应用程序运行，如下所示。
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。 接下来，可以在 Git 存储库中指定一个应提升的文件夹。
单击发布之后，所选文件夹下的所有 markdown 文件都会发布为 wiki。 该操作还会将分支头映射到 Wiki，因此对 Git 存储库进行的任何更改都可立即显示。
有关详细信息，请参阅产品文档博客文章。
链接到页面中的标题
现在，你可以单击 Wiki 页面中任何部分的标题旁的链接图标，以直接生成指向该部分的 URL。 然后，你可以复制该 URL 并与团队成员共享，使其可以直接访问该部分。
在文件夹中附加文件和图像
脱机编辑 wiki 页面时，可以更轻松地在与 wiki 页面相同的目录中添加文件附件和图像。 现在，你可以在 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 用户界面中使用 REST API 重命名 wiki。 从更多菜单中，单击重命名 wiki 以向 wiki 提供便于记忆的名称。
在新标签页中打开页面
现在，你可以右键单击 wiki 页面并选择在新标签页中打开该页面，也可按住 CTRL 并左键单击 wiki 页面，以在新标签页中打开该页面。
保留 Wiki 页面标题中的特殊字符
现在可以创建包含特殊字符的 Wiki 网页，例如 : < > * ? | -。 现在包含标题的页面，如“常见问题解答？” 或“设置指南”可以在 Wiki 中创建。 以下字符将转换为其 UTF-8 编码字符串：
| 字符 | 编码字符串 |
|---|---|
| : | %3A |
| < | %3C |
| > | %3E |
| * | %2A |
| ？ | %3F |
| | | %7C |
| - | %2D |
查看断开的链接
wiki 中所有未正确链接的链接都将以独特的红色以及断开的链接图标显示，使你可以直观地查看 wiki 页面中所有断开的链接。
在移动页面时修复断开的链接
页面链接断开是所有文档解决方案中页面质量不佳的主要原因之一。 以前在 Wiki 中，当移动树结构中的某个页面或重命名某个页面时，它可能是从其他页面和工作项到该页面的断开的链接。 现在，你可以在链接断开之前对其进行检查和修复。
重要
请记住， []() 在工作项中使用页面链接的 Markdown 语法和 Wiki 页面 链接类型，以便 Wiki 查找和修复这些可能损坏的链接。 此功能不会选取工作项中的纯文本 URL 和超链接。
重命名或移动页面时，系统会提示你检查受影响的绝对或相对链接。
随后会在执行操作之前显示受影响的页面链接和工作项的列表。
为 wiki 页面创建目录
现在，你可以使用 [[_TOC_]] 现在，可以使用语法将目录添加到具有至少一个标题 [[_TOC_]] 的任何页面。
也可以在编辑页面时通过单击格式窗格中的相应按钮来插入目录。
有关在 Azure DevOps 中使用 markdown 的详细信息，请参阅 markdown 指南文档。
使用 YAML 标记显示 wiki 页面和代码预览的元数据
将元数据添加到文档可以帮助读者和搜索索引选取和显示有意义的内容。 在此更新中，任何在文件开头包含 YAML 块的文件都将转换为包含一个表头和一行的元数据表。 YAML 块的格式必须为在三点划线之间包含有效的 YAML 集。 它支持将所有基本数据类型、列表、对象作为值。 Wiki 和代码文件预览中支持该语法。
YAML 标记示例：
---
tag: post
title: Hello world
---
列表中的 YAML 标记示例：
---
tags:
- post
- code
- web
title: Hello world
---
使用“参与”权限将代码发布为 wiki
以前，只有对 git 存储库拥有创建存储库权限的用户才能将代码发布为 wiki。 这导致非存储库管理员或创建者无法完成将 git 存储库中托管的 markdown 文件发布为 wiki 的任何请求。 现在，如果刚刚对代码存储库拥有“参与”权限，则可以将代码发布为 wiki。
正在报告
用于报告的 Analytics 市场扩展现已可用
Analytics 市场扩展现可用于 Azure DevOps Server。 Analytics 是 Azure DevOps 和 Azure DevOps Server 的报告的未来。 安装 Analytics 扩展可提供 高级小组件、 Power BI 集成和 OData 访问。
有关详细信息，请查看什么是 Analytics 和报告路线图。 Analytics 目前提供公共预览版。 它目前包含 Boards 的数据和通过 Pipelines 获得的自动测试结果。 请参阅 Analytics Service 中可用的数据。
通过新的生成仪表板小组件调查生成历史记录
我们提供了一个经过改进的全新小组件，你可将该小组件添加到仪表板。 现在，使用该小组件可以在仪表板上查看特定分支的生成历史记录，还可以在面向匿名访问者的公共项目中对其进行配置。
重要
如果你正在寻找有关 XAML 生成的见解，请继续使用较旧的小组件，并阅读如何 从 XAML 生成迁移到新生成。 否则建议你迁移到较新的小组件。
反馈
我们期待你的宝贵意见和建议！ 你可以报告问题或提供想法并通过开发者社区跟踪它，并获取有关 Stack Overflow 的建议。