Adds support for deleting connections. Fixes AB#20.
这会创建从工作项 #20 到 GitHub 中的提交的链接，该链接会出现在工作项的“开发”部分中。
如果字词“fix”、“fixes”或“fixed”在提及工作项之前出现（如上所示），则当提交合并到默认分支时，工作项会转变为已完成状态。
使用 Azure Pipelines 在 GitHub 中生成代码的团队还会在生成摘要中看到链接到其 GitHub 提交的工作项。
新的工作项中心
工作项中心是用于容纳工作项的新中心！ 在此处你可获得为你缩小了范围的许多不同的工作项列表视图。 可以查看分配到我以快速浏览分配给你的所有工作，或是向你显示项目中最近更新的所有工作项的最近更新。 可以在下面看到所有列表选项：
如果甚至要进一步缩小列表范围，则能够对类型、分配对象、状态、区域、标记和关键字进行筛选。 获得所需列表视图之后，随后只需单击列标题，便可以对工作项进行排序。 如果某列太窄，无法该列的完整内容，则可以在标题区域中轻松调整该列大小。 可以在下面看到这些体验：
新的板、积压工作 (backlog) 和冲刺 (sprint) 中心
积压工作 (backlog) 中心划分为三个不同的中心，以改进用户体验。 尽管功能强大，不过旧的积压工作 (backlog) 中心容纳了太多功能。 这样通常难以找到用户寻求的特性或功能。 为了解决此问题，我们将积压工作 (backlog) 中心拆分为：
积压工作 (backlog) 中心现在仅容纳项目的积压工作 (backlog)。 积压工作 (backlog) 是设置了优先级的团队工作列表。 积压工作 (backlog) 提供了计划工具，如工作项层次结构、预测和新的冲刺 (sprint) 计划体验。
新的板中心容纳项目的所有看板。 板用于传达状态和流。 卡（工作项）通过团队定义的列，在板中从左到右移动。
新的冲刺 (sprint) 中心容纳用于计划和执行工作增量的功能。 每个冲刺 (sprint) 包含一个冲刺 (sprint) 积压工作 (backlog)、一个任务板以及一个用于为团队管理和设置容量的视图。
在我们的 DevOps 博客上详细了解这些令人兴奋的更新。
将工作项移动到另一个项目并更改工作项类型
现在可以 更改工作项类型 或 将工作项移动到 项目集合中的另一个项目。 这些功能需要禁用数据仓库。 禁用数据仓库后，可以使用 Analytics Service 来支持报告需求。 若要详细了解如何禁用数据仓库，请参阅 禁用数据仓库和多维数据集。
冲刺 (sprint) 计划功能
新的冲刺 (sprint) 计划功能可帮助加快并改进冲刺 (sprint) 计划体验。
直接从 Sprints 中心创建下一个冲刺或订阅现有冲刺计划。
使用积压工作 (backlog) 中新的计划窗格将工作项拖放到将来的冲刺 (sprint) 中。 计划窗格包括冲刺 (sprint) 日期、工作项计数和计划工作量。
将要求添加到任务板顶部或使用快速创建添加到冲刺 (sprint) 积压工作 (backlog) 的顶部、底部或所选行。
对被分派人、工作项类型、状态和标记使用筛选器以按照需求定制视图。
所有新的中心（包括积压工作 (backlog)、板和冲刺 (sprint)）现在具有使用以下部分进行组织的新目录页面：
从离开的位置继续 这一新部分提供直接指向你所处的最后一个（板 | 积压工作 (backlog) |冲刺 (sprint)）的快速链接。
收藏夹 在所有团队间收藏的所有板、冲刺 (sprint) 和积压工作 (backlog)。
我的 你所属团队的所有板、积压工作 (backlog)和冲刺 (sprint)。
全部 所有板、积压工作 (backlog)和冲刺 (sprint) 的完整列表。
在我们的 DevOps 博客上详细了解这些令人兴奋的更新、新的团队配置文件窗格和收藏夹。
卡注释包括 bug 和自定义工作项类型
卡注释由于其直观的检查列表视图和交互而深受人们喜爱。 以前，卡注释限制为默认积压工作 (backlog) 级别类型，不支持 Bug 或自定义类型。 在新版本中，我们移除了对工作项类型的限制，并添加了将 Bug 和任何自定义工作项类型显示为卡注释的功能。
卡注释的板设置已扩展为包括可用于该积压工作 (backlog) 级别的所有工作项类型。
启用了工作项的注释时，对该工作项类型的计数会作为单独检查列表包含在卡中。
还可通过卡上下文菜单快速创建已启用的工作项类型。
使用建议的区域和迭代移动工作
可能常常在相同区域或迭代中工作并在四处移动工作项时重复浏览层次结构。 区域和迭代路径控件现在以建议的形式包含最近使用的值的列表，从而使你可以快速访问以进行设置并继续处理。
此外，迭代日期包含在名称右侧，以便可以快速判断何时应传递工作项。
使用 +/- 跨迭代计划查询工作 @CurrentIteration
帮助 @CurrentIteration 团队根据迭代计划跟踪工作的宏现在支持整数偏移量。 在未关闭 @CurrentIteration 的工作上轻松保留选项卡 - 1，或提前查看计划使用 + 1 进行将来迭代 @CurrentIteration 的工作。 有关详细信息，请参阅 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，提供与旧部分等效的功能。 但是，如果你属于多个团队，则此部分会显示分配给你的所有团队的 PR。 此部分也可自定义（只需单击此部分标题附近的“自定义此视图”操作）。
使用模板标准化拉取请求描述
编写良好的拉取请求描述是帮助审阅者了解审阅代码时的预期内容的好办法。 它们也是帮助跟踪应对每个更改执行的操作（如测试、添加单元测试和更新文档）的好办法。 你中的许多人一直在请求我们添加拉取请求模板，以便团队更轻松地编写出色的说明，现在我们添加了该功能。
除了支持默认 PR 描述模板，团队可以添加多个模板，这些模板会在创建 PR 页面上的菜单中提供给你。 只需单击添加模板按钮即可从存储库中的任何模板进行选择，以将它追加到 PR 描述中。
如果要将 PR 的不同模板应用到特定分支或分支文件夹中，则也支持特定于分支的模板。 例如，如果要使用特定于开头为“hotfix/”的所有分支的模板，则可以将用于所有 PR 的模板添加到这些分支中。
请参阅 拉取请求模板 文档，了解有关如何创建和使用模板的详细信息。
更改拉取请求的目标分支
对于大多数团队，几乎所有拉取请求都面向同一分支，例如 main 或 develop。 但是，在需要面向不同分支的情况下，很容易忘记更改默认的目标分支。 借助用于更改活动拉取请求的目标分支的新功能，现在这是简单的操作。 只需单击拉取请求标头中目标分支名称旁的铅笔图标。
不仅仅是更正错误，通过用于更改目标分支的功能还可在合并或删除了目标分支时轻松地“重定向”拉取请求。 请考虑这样一个情况：你的一个 PR 面向的功能分支包含更改所依赖的某些功能。 你希望查看依赖更改，与功能分支中的其他更改隔离，因此你最初的目标是 features/new-feature。 审阅者因而可以仅查看你的更改，并留下相应的注释。
现在，请考虑如果功能分支也具有 PR 活动，并在更改之前合并到 main 什么情况？ 以前，必须放弃更改并创建新的 PR， main或将 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 中统一了术语以阐明其概念。 现在你会看到以下统一术语：
升级到 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
测试结果和扩展性
还会为每个环境展现测试执行的结果。 单击测试结果可打开一个包含测试详细信息的视图，其中包括来自参与处理的其他扩展的结果。
现有扩展在此新视图进行工作，并且有新的扩展点可允许扩展表现甚至更多的环境信息。 有关详细信息，请参阅 贡献和扩展 文档。
Azure DevOps Server 中提供了基于 YAML 的生成管道。 使用签入到存储库中的 YAML 文件可自动执行持续集成管道。 在此处可以找到 YAML 架构的完整参考。
为了更加无缝地支持基于 YAML 的生成管道，我们将你创建的所有新资源（如服务连接、变量组、代理池和安全文件）的默认行为更改为可在该项目的所有管道中使用。 如果要对资源进行更紧密的控制，则可以禁用默认授权模型（请参阅下图）。 执行此操作时，具有使用资源的权限的人员必须在将资源引用添加到 YAML 文件之后，在 Web 编辑器中显式保存管道。
大型产品具有多个相互依赖的组件。 这些组件通常独立生成。 当上游组件（例如库）发生更改时，下游依赖项必须重新生成并重新验证。 团队通常手动管理这些依赖项。
现在可以在一个生成成功完成时触发另一个生成。 上游生成生成的Artifacts可下载并用于后续生成，还可以从以下变量获取数据：Build.TriggeredBy.BuildId、Build.TriggeredBy.DefinitionId、Build.TriggeredBy.BuildDefinitionName。 有关详细信息，请参阅 生成触发器 文档。
请记住，在某些情况下，单个 多阶段生成 可以满足你的需求。 但是，如果要求包括不同配置设置、选项或拥有依赖进程的不同团队，则生成完成触发器十分有用。
本地更新代理
有时从库安装的任务需要较新版本的管道代理。 如果 Azure DevOps Server 可以连接到 Internet，则会自动下载较新版本。 如果未自动下载，则必须手动升级每个代理。 从此发布开始，可以配置 Azure DevOps Server 以查找其本地磁盘上（而不是来自 Internet）的代理包文件。 这使你可以具备灵活性并控制你提供的代理版本，而不必向 Internet 公开 Azure DevOps Server。
新的生成状态徽章 URL
嵌入在存储库主页中的生成徽章是显示存储库运行状况的常用方法。 尽管我们到目前为止已有了生成徽章，但是存在几个问题：
URL 不直观
徽章不特定于某个分支
用户无法单击徽章以将用户转到该定义的最新生成
我们现在针对生成徽章推出了一个解决这些问题的新 API。 新 API 使用户可以发布每个分支状态，可以将用户转到所选分支的最新生成。 可以通过在“新建生成”页中选择“状态锁屏提醒”菜单操作来获取新状态锁屏提醒 URL 的 Markdown。
为了向后兼容，我们将继续同样接受较旧生成徽章 URL。
将自定义生成计数器添加到生成
生成计数器提供对生成进行唯一编号和标记的方法。 以前可以使用 $(rev:r) 特殊变量来实现此目的。 现在可以在生成定义中定义自己的计数器变量，这些变量在每次运行生成时自动递增。 可在定义的变量选项卡上执行此操作。 这一新功能在以下方面为你提供更强大的功能：
可以定义自定义计数器并设置其种子值。 例如，可以在 100 处启动计数器。 $ (rev：r) 始终从 0 开始。
可以使用自己的自定义逻辑重置计数器。 $ (rev：r) 与生成数生成相关联，每当内部版本号中有新前缀时，它会自动重置。
对每个定义可以定义多个计数器。
可以查询生成之外的计数器值。 例如，可以使用计数器对自上次重置以来运行的生成数进行计数。
有关生成计数器的详细信息，请参阅有关 用户定义的变量 的文档。
管道中的 Azure Policy 合规性和安全性验证
我们希望在开发过程中尽早确保软件的稳定性和安全性，同时将开发、安全性和操作整合在一起。 为此，我们添加了对Azure Policy的支持。
可以借助 Azure Policy，通过策略定义来对资源强制实施规则并施加影响，以便管理和预防 IT 问题。 使用Azure Policy时，资源与公司标准和服务级别协议保持一致。
为了在发布过程中遵守合规性和安全性指导原则，我们增强了我们的 Azure 资源组部署体验。 现在，如果在部署 ARM 模板期间发生任何违规，则我们会使存在与相关策略有关的错误的 Azure 资源组部署任务失败。
此外，我们添加了 Azure Policy 发布定义模板。 这使用户可以创建 Azure 策略并通过发布定义本身将这些策略分配给资源、订阅或管理组。
Azure Pipelines开放源代码跨平台代理始终在 64 位 (x64) Windows、macOS 和 Linux 上受支持。 在此版本中，我们将推出两个新的受支持平台：Linux/ARM 和 Windows/32 位。 这些新平台使你可以在不太常见，但并不是不重要的平台（如 Raspberry Pi、Linux/ARM 计算机）上进行生成。
改进了管道中的测试体验
测试选项卡现在具有现代体验，可针对管道提供丰富的上下文中测试信息。 新体验提供正在进行的测试视图、整页调试体验、上下文中测试历史记录、报告已中止测试执行以及运行级别摘要。
查看正在进行的测试的执行
测试（如集成和功能测试）可能会长时间运行，因此可在任何给定时间查看测试执行会十分重要。 借助正在进行的测试视图，不必再等待测试执行完成即可了解测试结果。 结果会在运行时近乎实时地提供，从而帮助更快地执行操作。 可以调试失败或中止、对 bug 归档或中止管道。 该功能当前可用于多代理阶段中使用 VS 测试任务的生成和发布管道、使用发布测试结果任务或是使用 API 发布测试结果。 我们计划将来对使用单个代理的测试执行扩展此体验。
下面的视图显示新发布进度视图中正在进行的测试摘要，报告给定时间点的总测试计数和测试失败数。
通过单击上面的正在进行的测试摘要，可以在测试计划中查看详细测试摘要以及失败或已中止测试信息。 测试摘要基于新结果的可用性以定期间隔进行刷新，能够按需刷新详细信息视图。
以整页查看测试运行调试详细信息
错误消息和堆栈跟踪本质上很长，需要足够空间才能在调试过程中查看详细信息。 若要获得沉浸式调试体验，现在可以将测试或测试运行视图展开为整页视图，同时仍然能够对当前测试结果执行所需的上下文中操作（如 bug 创建或要求关联）。
查看上下文中测试历史记录
在历史上，团队必须转到运行中心，才能查看测试结果的历史记录。 借助新体验，我们直接在测试计划选项卡的上下文中提供生成和发布的测试历史记录。 以渐进式方法提供测试历史记录信息，从所选测试的当前生成定义或环境开始，接下来分别是生成和发布的其他分支和环境。
查看已中止的测试
测试执行可能会由于多种原因（如错误测试代码、进行测试的源代码和环境问题）而中止。 无论是何种中止原因，诊断行为并确定根本原因都十分重要。 现在可以在测试计划中查看已中止的测试和测试运行以及已完成的运行。 该功能当前可用于多代理阶段中使用 VS 测试任务的生成和发布管道或是使用 API 发布测试结果。 我们计划将来对使用单个代理的测试执行扩展此体验。
测试历史记录中的测试可跟踪性和发布环境支持
我们添加了支持来查看按在其中运行测试的各种发布环境分组的自动测试历史记录。 如果将发布环境建模为发布管道或测试环境，并在这类环境间运行测试，则可以发现测试是否在开发环境中通过，但在集成环境中失败。 可以发现它是否在英语区域设置中通过，但在具有土耳其语区域设置的环境中失败。 对于每个环境中，会找到最新测试结果的状态，并且如果测试在该环境中失败，则还会找到测试开始失败时的第一个发布。
查看汇总测试结果
在测试执行期间，测试可能会生成多个测试实例，它们都会参与形成整体结果。 一些示例包括：由于失败而重新运行的测试、由其他测试的有序组合构成的测试（例如顺序测试）或是具有基于所提供输入参数的不同实例的测试（数据驱动测试）。 由于这些测试相关，因此需要与基于单个测试结果派生的整体结果一起进行报告。 在此更新中，我们引入了改进版本的测试结果，它们在发布的测试选项卡中显示为层次结构。 接下来举例说明。
此前，我们引入了在 VS 测试任务中重新运行失败的测试的功能。 但是，我们仅报告了测试的最近一次尝试，这在某种程度上限制了此功能的有用性。 我们现在将此功能扩展为将测试执行的每个实例作为一次尝试进行报告。 此外，测试管理 API 现在支持发布和查询分层测试结果的功能。 有关详细信息，请参阅 测试结果 API 文档。
查看管道中的测试分析
随时间推移跟踪测试质量并改进测试附属品是维护正常管道的关键。 利用测试分析功能可以近乎实时地了解用于生成和发布管道的测试数据。 该功能可通过识别重复且严重影响质量的问题来帮助提高管道效率。
可以按各种元素对测试结果进行分组、标识分支或测试文件的关键测试或深化到特定测试以查看趋势并了解质量问题（如信号不可靠）。
查看 生成 和 发布的测试分析，预览以下版本：
有关详细信息，请参阅文档。
使用多个无代理任务简化定义
无代理阶段中的任务由服务器进行安排并在服务器上执行。 无代理阶段不需要代理或任何目标计算机。 与代理阶段不同，只能将一个任务添加到定义中的每个无代理阶段。 这意味着在过程中存在多个无代理任务时必须添加多个阶段，从而使定义十分庞大。 我们放宽了此限制，使你可以在无代理阶段中维护多个任务。 相同阶段中的任务会按顺序执行，如同针对代理阶段一样。 有关详细信息，请参阅 服务器阶段 文档。
使用发布入口逐渐公开部署并划分阶段
使用发布入口可以指定在将发布提升到下一个环境之前必须满足的应用程序运行状况条件。 所有指定入口都会在任何部署之前或之后定期进行评估，直到它们全部成功。 四种类型的大门现身可用，你可以从 市场添加更多大门。 你能够审核是否满足了部署的所有必需条件。 请参阅发布入口文档获取详细信息。
保持部署，直到入口一致地成功
通过发布入口可以在将发布提升到下一个环境之前自动评估运行状况条件。 默认情况下，发布会在收到所有入口的一个成功示例之后前进。 即使入口不稳定，并且收到的成功示例是噪声，发布也会前进。 若要避免这些类型的问题，现在可以配置发布以在前进之前验证最小持续时间内的运行状况一致性。 在运行时，发布会在允许提升之前确保入口的连续评估成功。 评估的总时间取决于“重新评估之间的时间”，通常多于配置的最小持续时间。 有关详细信息，请参阅 使用入口文档的发布部署控制 。
自动部署到部署组中的新目标
以前，当新目标添加到部署组时，需要进行手动部署以确保所有目标都具有相同发布。 现在可以配置环境以将最近的成功发布自动部署到新目标。 有关详细信息，请参阅 部署组 文档。
持续部署标记进行后期生成处理的生成
持续部署触发器在生成完成时创建发布。 但是，有时生成会进行后期处理，只应在该处理完成之后才发布生成。 现在可以在发布的触发器筛选器中利用生成标记（在后期处理过程中分配）。
在发布时设置变量
在发布定义中，现在可以选择要在创建发布时设置的变量。
在创建发布时为变量提供的值仅用于该发布。 此功能可帮助避免用于以草稿状态创建、更新草稿中的变量以及使用变量触发发布的多个步骤。
将环境变量传递给任务
CI/CD 任务作者可以在 task.json 中设置一个新属性 showEnvironmentVariables，以将环境变量传递给任务。 执行此操作时，会在生成编辑器中的任务上呈现一个额外控件。 此可用于 Powershell、Cmd 和 Bash 任务。
这可实现两个方案：
一个任务需要变量名称保留大小写的环境变量。 例如在上面的示例中，传递给任务的环境变量是“foo”而不是“FOO”。
它允许以安全方式将机密值传递给脚本。 这优先于将机密作为参数传递给脚本，因为代理上的操作系统可能会记录进程调用（包括其参数）。
克隆变量组
我们添加了对克隆变量组的支持。 每当要复制变量组并且只更新少数变量时，无需完成逐个添加变量的冗长过程。 现在可以快速复制变量组，相应地更新值，然后将它保存为新变量组。
从 Azure 应用服务部署中支持的包运行
Azure 应用服务部署任务 (4.*) 版本现在支持以前称为 RunFromZip 的 RunFromPackage (。
应用服务支持多种不同的技术来部署文件，如 msdeploy（又称为 WebDeploy）、git、ARM 等。 但所有这些技术都有一个限制。 文件部署在 wwwroot 文件夹（具体而言是 d:\home\site\wwwroot）下，运行时随后从其中运行文件。
借助“从包运行”功能，不再需要将各个文件复制到 wwwroot 的部署步骤。 而是只需将它指向到一个 zip 文件，该 zip 会作为只读文件系统装载在 wwwroot 上。 这样做有以下几个好处：
减少文件副本锁定问题的风险。
可部署到生产应用（需重启）。
可以确定哪些文件在应用中运行。
提高 Azure 应用服务部署的性能。
可以减少冷启动时间，特别是对于具有大型 npm 包树的 JavaScript 函数。
使用应用服务器部署任务部署 Linux 容器
4.* 版本的 Azure 应用服务部署任务现在支持将自己的自定义容器部署到 Linux 上的 Azure Functions。
Azure Functions 的 Linux 托管模型基于 Docker 容器，这些容器在打包和利用应用特定依赖项方面可提供更高灵活性。 Linux 上的 Functions 可以采用 2 种不同模式进行托管：
内置容器映像： 将 Function App 代码引入并管理容器 (内置映像模式) ，因此不需要特定的 Docker 相关知识。 这在现有版本的应用服务部署任务中受支持。
自定义容器映像：我们增强了App 服务部署任务，以支持将自定义容器映像部署到 Linux 上的Azure Functions。 当函数需要特定语言版本或需要内置映像中未提供的特定依赖项或配置时，可以使用 Azure Pipelines 生成自定义映像并部署到 Linux 上的 Azure Functions。
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 工具，并将它添加到生成代理的路径。 如果代理上已安装了目标 Go 工具版本，则此任务会跳过下载并再次安装它的过程。
Go 任务可帮助下载依赖项、生成或测试应用程序。 还可以使用此任务运行所选择的自定义 Go 命令。
在管道中运行内联或基于文件的 Python 脚本
新的 Python 脚本 任务简化了在管道中运行 Python 脚本。 该任务会从存储库中的 Python 文件 (.py) 运行脚本，你也可以在任务设置中手动输入脚本以保存为管道的一部分。 该任务将使用路径中的 Python 版本，也可以指定要使用的 Python 解释器的绝对路径。
利用来自 xcpretty 的改进的 Xcode 生成和测试输出
xcpretty 增强了 xcodebuild 输出的可读性，并使用 JUnit 格式生成测试结果。 当代理计算机上有 xcpretty 可用时，Xcode 生成任务现在会自动使用 xcpretty，因为它处于托管 macOS 代理上。 尽管 xcpretty 输出与 xcodebuild 输出相比可能有所不同并且没那么详细，但是我们会随每个生成提供完整 xcodebuild 日志。
Test Plans
测试运行程序 (Azure Test Plans) 客户端运行桌面应用程序的手动测试
现在可以使用测试运行程序 (Azure Test Plans) 客户端为桌面应用程序运行手动测试。 这会帮助你从 Microsoft 测试管理器迁移到 Azure Test Plans。 请在此处参阅我们的指南。 使用测试运行程序客户端，可以运行手动测试并记录每个测试步骤的测试结果。 还可获得数据收集功能，如屏幕截图、图像操作日志和音频视频录制。 如果在测试时发现问题，请使用测试运行程序创建 bug，bug 中会自动包含测试步骤、屏幕截图和注释。
测试运行程序 (Azure Test Plans) 需要一次性下载并安装运行程序。 选择为桌面应用程序运行，如下所示。
Azure DevOps Server 2019 对 Azure Artifacts 源上可用的上游源提供了大量更新：
可以将 nuget.org 上游源添加到在以前的 TFS 版本中创建的现有源。 可查找源包上方的横幅以了解详细信息，包括在升级之前应注意的行为更改。
可以将其他 Azure DevOps Server 源作为上游源添加到你的源，这意味着你可以通过你的源使用这些源中的 NuGet 和 npm 包。
我们还在Azure Artifacts中引入了一个新角色：“协作者”。 协作者可以保存来自上游源的包，但无法将包直接到发布到源中（例如使用 nuget 发布）。 这使你可以将包发布限制为受信任的用户或生成系统，同时允许你的工程师使用来自上游源的新包。
我们使直接使用每个包上的新关注按钮设置通知变得更简单。 关注按钮也与发布视图兼容。 如果你关注某个循包，同时通过视图查看它，则你只会获得提升到该视图的新版本的更新。
更改源设置而不必手动保存
源设置页面上的几个交互得到了改进。 现在会立即保存进行的更改（如添加上游或权限）。 这意味着在设置透视之间切换时，不必担心会丢失更改。
与经过身份验证的 NuGet 源进行的交互刚刚得到了很大改善。 基于 .NET Core 的新Azure Artifacts凭据提供程序适用于 Windows、macOS 和 Linux 上的 msbuild、dotnet 和 nuget (.exe) 。 每当要使用来自 Azure Artifacts 源的包时，该凭据提供程序会自动获取并存储代表所使用的 NuGet 客户端的令牌。 无需再在配置文件中手动存储和管理令牌。
若要获取新提供商，请转到GitHub并按照客户端和平台的说明进行操作。
发布到文件共享时压缩符号
我们已更新 索引 & 发布符号任务 ，以支持在将符号发布到文件共享时压缩符号。
从 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 页面 链接类型的 markdown 语法，以允许 Wiki 查找和修复这些可能损坏的链接。 此功能不会选取工作项中的纯文本 URL 和超链接。
重命名或移动页面时，系统会提示你检查受影响的绝对链接或相对链接。
随后会在执行操作之前显示受影响的页面链接和工作项的列表。
为 wiki 页面创建目录
有时 wiki 页面可能会很长，其内容按多个标题进行组织。 现在，可以使用语法将目录添加到具有至少一个标题 [[_TOC_]] 的任何页面。
还可以在编辑页面时通过单击格式窗格中的相应按钮来插入目录。
有关在 Azure DevOps 中使用 markdown 的详细信息，请参阅 markdown 指南文档。
使用 YAML 标记展示 wiki 页面和代码预览的元数据
向文档添加元数据可以帮助读者和搜索索引选取并展现有意义的内容。 在此更新中，在文件开头包含 YAML 块的任何文件都会转换为由一个头和一行组成的元数据表。 YAML 块必须采用在三重短划线之间设置的有效 YAML 的形式。 它支持所有将基本数据类型、列表、对象作为值。 Wiki 和代码文件预览中支持该语法。
YAML 标记示例：
tag: post
title: Hello world
使用参与权限将代码发布为 wiki
以前，只有对 git 存储库拥有创建存储库权限的用户才能将代码发布为 wiki。 这使得对于将 git 存储库中托管的 markdown 文件发布为 wiki 的任何请求，存储库管理员或创建者都会成为瓶颈。 现在，如果只是对代码存储库拥有“参与”权限，则可以将代码发布为 wiki。
用于报告的 Analytics 市场扩展现已推出
分析市场扩展现在可用于Azure DevOps Server。 Analytics 是未来适用于 Azure DevOps 和 Azure DevOps Server 的报告。 安装 Analytics 扩展可提供高级小组件、Power BI集成和 OData 访问。
有关详细信息，请查看什么是分析和报告路线图。
Analytics 处于公共预览版状态。 它当前通过管道包含板和自动测试结果的数据。 请参阅 Analytics Service 中提供的数据。
通过新的生成仪表板小组件调查生成历史记录
我们提供了一个改进的新生成历史记录小组件，你可以将它添加到你的仪表板。 使用此小组件现在可以在仪表板上查看特定分支中的生成的历史记录，并在公共项目中为匿名访问者配置它。
如果你想深入了解你的 XAML 生成，请继续使用较旧的小组件，并阅读从 XAML 生成迁移到新生成。 否则建议你迁移到较新的小组件。
我们期待你的宝贵意见和建议！ 可以报告问题或提供想法，并通过开发者社区跟踪它，并获取有关 Stack Overflow 的建议。
