~$ 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时速度缓慢和超时。
工作项链接上的“修订者”值不正确。
Azure Pipelines
在管道通知中，某些区域设置中的“持续时间”等字段可能为 null。
模板路径不能指向包含 Azure 资源组部署的管道中的有效 JSON 文件。
集合级保留设置页显示在项目设置页中。
Azure Test Plans
编辑Test Plans中的字段速度较慢。
在测试用例中，当从 Boards (而不是Test Plans) 打开时，不会打开共享步骤详细信息。
集合不按字母顺序排序。
内存使用率高。
配置了负载均衡器的服务器必须将其公共源显式添加到 AllowedOrigins 注册表项。
在 SQL Azure 上安装的客户看不到“完成试用”对话框。
安装扩展时会显示错误“错误消息缺少贡献 (ms.vss-dashboards-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 引入了许多新功能。 其中一些要点包括：
新建基本流程
查询与日、周、月或年开始时间相关的工时
在 GitHub 中规划时接受并执行Azure Boards
为自动完成拉取请求重新运行过期的内部版本
用于完成拉取请求的新合并类型
使用标记触发 YAML 管道
用于编辑 YAML 文件的任务助手
具有用于 YAML 管道的 IntelliSense 的 Web 编辑器
使用管道管理 GitHub 版本
高级) 小组件 (测试结果趋势
包的出处信息
对 Python 包的支持
Maven 的上游源
在 Wiki 中嵌入Azure Boards查询结果
Wiki 网页的永久链接
Wiki 页面上的通知
使用 Analytics 不再需要分析扩展
还可以跳转到各个部分以查看新功能：
Boards
Repos
深色主题一直是 Azure DevOps Services 上的热门功能，现已在Azure DevOps Server推出。 可以通过从每个页面右上角的头像下方的菜单中选择“ 主题 ”来打开深色主题。
Boards
新建基本流程
从历史上看，敏捷一直是新项目的默认流程，提供一组可靠而灵活的工作项类型和状态，以适应各种项目交付方法。 对于一些更熟悉其他工具或正在成长并希望采用更强大的工具集的团队，希望使用他们更熟悉的术语快速开始。
新的“基本”流程提供三种工作项类型， (长篇故事、议题和任务) 来规划和跟踪工作。 建议使用“问题”来跟踪用户情景、bug 和功能等内容，同时使用长篇故事将问题分组到更大的工作单元中。 在工作上取得进展时，沿着简单的“To Do”、“Do”和“Done”状态工作流移动项。
请参阅 跟踪问题和任务 文档，以帮助你开始使用新项目。
以前，工作项窗体上的状态值按字母顺序排序。 在此更新中，我们更改了状态值的排序方式，以匹配进程设置中的工作流顺序。 还可以在状态自定义设置中更改每个类别中的状态顺序。
功能启用不再可用
客户需要手动更新每个项目的 XML，以便在升级集合后启用新功能。
请参阅 文档 ，了解如何启用特定功能。
使用更丰富的工作项附件整理参考资料
通过将文件附加到工作项，你和你的团队可以集中参考资料，以便在需要时始终靠近它们。 现在只需将文件拖放到工作项窗体上的任意位置，即可更轻松地添加新附件。 可以继续以列表的形式查看附件，或切换到网格视图以显示缩略图预览。 双击文件以打开预览，并循环浏览它们以快速找到所需的信息。
使用徽章共享团队的版块
存储库的自述文件通常是项目团队查找的主页，以获取有关如何为解决方案做出贡献和使用的信息。 现在，就像在 Azure Pipelines 中使用生成或部署状态一样，可以在 Azure Boards 中为团队董事会添加徽章。 可以将锁屏提醒配置为仅显示“正在进行”列或所有列，甚至可以在项目开放源代码时公开显示锁屏提醒。
如果自述文件基于 Markdown，只需从状态锁屏提醒设置页复制示例 Markdown 并将其粘贴到文件中。
查询与日、周、月或年开始时间相关的工时
虽然团队通常专注于在下一个即将发生的情况或基于冲刺迭代的情况下工作，但通过日历的视角回顾工作，报告上个月或今年第一季度发生的所有工作通常很有趣。 现在，可以使用以下新的 @StartOf 宏集以及任何基于日期的字段，以便基于日、周、月或年的开始时间进行查询：
@StartOfYear
@StartOfMonth
@StartOfWeek
@StartOfDay
其中每个宏还接受一个新的修饰符字符串，该字符串允许按不同的日期单位移动数据。 例如，可以通过查询状态更改日期 = 和<@StartOfYear(状态更改日期 >= @StartOfYear “+3M” ) 编写查询来查找今年第一季度完成的所有工作项。 有关详细信息，请参阅 查询宏 文档。
我们很高兴地宣布推出高投票开发者社区功能，在Azure Boards中编辑和删除工作项讨论中的批注。 若要编辑批注，只需将鼠标悬停在你拥有的任何批注上，你将看到两个新按钮。 如果单击铅笔图标，将进入编辑模式，只需进行编辑并按“更新”按钮即可保存编辑。
单击溢出菜单时，将看到用于删除批注的选项。 单击此项后，系统将再次提示确认是否要删除此批注，该批注将被删除。
在工作项窗体上的“历史记录”选项卡中，你将获得所有编辑和删除的批注的完整跟踪。 你还将看到，我们更新了讨论体验的 UI，使其感觉更加现代和交互。 我们在批注周围添加了气泡，以更清楚地说明个人评论的开始和结束位置。
将查询结果导出到 CSV 文件
现在可以直接从 Web 将查询结果导出到 CSV 格式化文件。
现在，当你在 GitHub 中使用 AB#{work item ID} 语法在问题的注释中提及工作项、拉取请求或提交时，这些提及将成为超链接，你可以单击这些超链接以直接导航到提到的工作项。
这不会创建一个正式链接，使每个相关对话Azure Boards中的工作项变得杂乱无章，而是让你的团队在讨论代码或客户报告的问题时提供一些有关工作项的详细信息。 有关详细信息，请参阅Azure Boards GitHub 集成文档。
在 gitHub 中规划时接受并执行Azure Boards
现在，可以将 Azure Boards 中的工作项与 GitHub 中的相关问题链接。 借助这种新型链接，现在可以实现其他几种方案。 如果你的团队希望继续接受来自用户的 bug 报告（例如，作为 GitHub 中的问题），但在Azure Boards中整体关联和组织团队的工作，现在你可以了。
你的团队用于提交和拉取请求的相同提及语法仍然适用，当然，你可以手动将Azure Boards链接到问题 URL。 有关详细信息，请参阅 GitHub & Azure Boards文档。
从看板快速查看链接的 GitHub 活动
在自己或团队查看看板时，你经常遇到诸如“此项目是否已开始开发？”或“此项目是否已在审阅？”借助看板上的新 GitHub 注释，现在可以快速了解项的位置，并直接导航到 GitHub 提交、拉取请求或问题以获取更多详细信息。 有关此注释以及任务和测试的其他注释的详细信息，请参阅 自定义卡片 文档。
Repos
草稿拉取请求
为了阻止拉取请求在已准备就绪之前完成以及轻松地创建可能不涉及任何人的正在进行的工作，我们现在支持草稿拉取请求。
在创建拉取请求时，可以通过从创建按钮下拉列表中选择创建为草稿来创建草稿拉取请求。
创建了草稿拉取请求之后，便会在标题旁看到一个指示其状态的徽章。
默认情况下，草稿拉取请求不包括审阅者或运行内部版本，但允许手动添加审阅者并运行生成。 若要将拉取请求提升为普通拉取请求，只需单击“拉取请求详细信息”页中的“发布”按钮即可。
为自动完成拉取请求重新运行过期的内部版本
Azure Repos现在会自动将拉取请求策略触发的过期生成排队。 这适用于已通过所有其他策略并设置为自动完成的拉取请求。
以前，当拉取请求具有策略（如所需审阅者）时，审批过程可能需要太长的时间，并且关联的生成可能会在审阅者批准拉取请求之前过期。 如果拉取请求设置为自动完成，则在用户手动将过期的内部版本排入队列之前，该拉取请求将一直处于阻止状态。 通过此更改，生成将自动排队，以便拉取请求可以在成功生成后自动完成。
此自动化将每个拉取请求最多将五个过期的生成排入队列，并且只会尝试对每个生成重新排队一次。
在拉取请求中仅查看左侧或右侧文件
现在，在拉取请求中查看文件更改时，可以使用并行差异或内联差异模式。 我们收到了反馈，你们中的许多人只想查看原始文件或更改的文件，而不进行比较，因此我们添加了一个新选项，允许你单独查看左侧文件或右侧文件。
用于完成拉取请求的新合并类型
现在，在将更改从拉取请求合并到目标分支时，你有更多的选择。 我们在开发者社区添加了对两个最需要的功能的支持：快进合并和半线性合并 (也称为“重基和合并”) 。
现在，你将在 “完成拉取请求 ”对话框中看到这些新选项：
更新的策略管理页允许管理员控制分支或分支文件夹中允许的合并策略。
如果目标分支上的策略禁止使用重基策略，则需要“替代分支策略”权限。
如果拉取请求的源分支具有策略，则无法对其进行重定基。 重定基将修改源分支，而无需完成策略审批过程。
如果已使用 合并冲突扩展 来解决合并冲突。 在对一次一个拉取请求所有提交进行重基时，应用于三向合并的冲突解决很少成功， (甚至有效的) 。
在所有这些情况下，你仍然可以选择在本地重定分支基并推送到服务器，或者在完成拉取请求时压缩合并更改。
按拉取请求中的目标分支筛选 (PR)
拉取请求允许团队在将代码合并到 main 分支之前查看代码并提供有关更改的反馈。 它们已成为许多团队工作流的重要组成部分，因为你可以单步执行提议的更改、留下评论，并投票批准或拒绝代码更改。
为了便于你查找拉取请求，我们添加了一个筛选选项，用于使用目标分支搜索 PR。
还可以使用目标分支筛选来自定义“ 我的 ”选项卡中的拉取请求视图。
允许扩展添加语法突出显示和自动完成
目前，我们针对 Monaco 编辑器支持的一部分语言发布了语法突出显示。 但是，你们中的许多人希望为不支持的语言创建自己的语法突出显示。
在此更新中，我们添加了一个扩展点，允许扩展将语法突出显示和自动完成添加到文件资源管理器和拉取请求视图。
可 在此处找到演示此功能的扩展示例。
此外，我们还添加了对 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+Space 获取 IntelliSense 支持。 你将看到语法错误突出显示，并获取有关更正这些错误的帮助。
用于编辑 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 触发器。
branches:
include:
- main
- releases/*
autoCancel: false
在 YAML 管道中选择已签出代码的目录
以前，我们已将存储库签出到 s $ (Agent.BuildDirectory) 下的目录。 现在，可以选择将 Git 存储库签出以用于 YAML 管道的目录。
使用 上的path关键字 (keyword) checkout，你将控制文件夹结构。 下面是可用于指定目录的 YAML 代码示例。
steps:
- checkout: self
path: my-great-repo
在此示例中，代码将签出到 my-great-repo 代理工作区中的 目录。 如果未指定路径，存储库将继续签出到名为 的 s目录。
针对 YAML 优化的新Azure 应用服务任务
我们现在支持四个新任务，这些任务提供了一种简单而强大的方法来部署Azure 应用服务，并考虑到新式开发人员。 这些任务具有优化的 YAML 语法，使得在 Windows 和 Linux 平台上创作部署到 Azure AppServices（包括 WebApps、FunctionApps、用于容器的 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
资源授权改进
我们需要为受保护的资源提供安全性， (例如，在 YAML 文件中引用时，服务连接、变量组、代理池、安全文件) 。 同时，我们希望更轻松地设置和使用这些类型的资源的管道，以用于非生产方案。 以前，我们添加了一个设置，用于将资源标记为“已授权在所有管道中使用”。
通过此更新，即使尚未将资源标记为此类资源，我们也能更轻松地解决资源授权问题。 在新体验中，当生成因资源授权错误而失败时，你将看到一个选项，用于显式授权在管道中使用这些资源，然后继续。 有权授权资源的团队成员将能够直接从失败的生成中完成此操作。
“管道测试”选项卡中的新扩展贡献点
我们继续通过在管道的“测试结果”选项卡中添加两个新的贡献点，使扩展框架更加强大。 这将使 市场扩展 能够提供更定制的报告体验，并添加进一步的交互性。
两个贡献点是：
工具栏中的“自定义操作”按钮
有时，你可能想要执行更新 API 数据或使用测试结果中的元数据运行自定义工具等操作。 使用此贡献点，可以创建扩展，这些扩展使用所选测试结果的直接上下文将自定义操作添加到 *自定义操作- 按钮。
详细信息窗格中的“自定义详细信息”选项卡
你可能有各种各样的测试报表使用工作流，并且可能想要针对失败的测试查看不同的数据点，以便进行调试和分析。 使用此贡献点，团队可以将新选项卡添加到详细信息窗格中，当你选择数据网格中的任何测试结果行时，该选项卡将会出现该选项卡。 此新选项卡可以显示包含静态内容或使用内部或外部 API 提取的动态数据的视图。
运行一次代理
如果使用 Azure 容器实例 等基础结构来运行弹性专用代理，通常希望每个代理在离开前只接受一个作业。 到目前为止，这并不容易，因为必须终止代理 (可能导致) 报告失败，或者接受代理可能收到另一个作业的风险，然后才能将其关闭。 在此更新中，我们向代理配置添加了 --once 标志。 以这种方式配置代理时，它将只接受一个作业，然后自行关闭。
代理池用户界面更新
项目设置中的代理池管理页已使用新的用户界面进行了更新。 现在，可以轻松查看池中运行的所有作业。 此外，还可以了解作业未运行的原因。
部署到部署组中失败的目标
默认情况下，重新部署以前失败的运行时， Azure Pipelines 用于重新运行所有作业。 现在，可以通过在部署时配置 部署选项 来替代此行为。 通过选择“ 所有作业并限制为部署组中失败的目标 ”选项，重新运行将运行所有作业，并将部署跳过到已是最新的目标。
失败时自动重新部署
当部署到阶段失败时， Azure Pipelines 现在可以自动重新部署上次成功的部署。 可以通过在部署后条件中配置自动重新部署触发器，将阶段配置为自动部署最后一个成功的版本。 我们计划在将来的冲刺中向自动重新部署配置添加其他触发的事件和操作。 有关详细信息，请参阅 部署组 文档。
Grafana 批注服务挂钩
我们现在支持新的服务挂钩，它允许将部署已完成事件的 Grafana 注释添加到 Grafana 仪表板。 这使你可以将部署与 Grafana 仪表板中可视化的应用程序或基础结构指标的更改相关联。
查询 Azure Monitor 警报任务
以前版本的 查询 Azure Monitor 任务 仅支持在经典监视体验上查询警报。 使用此新版本的任务，可以查询有关 Azure Monitor 最近引入的统一监视体验的警报。
以前，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 关联的某个订阅中选择一个 Azure 容器注册表， (AAD) 标识。 需要与容器注册表（如 Docker@2 和 KubernetesManifest@0 ）建立服务连接的所有任务都支持单一指定连接的方式。
在发布定义中按文件夹名称搜索
可以通过将发布定义存储在文件夹中来组织发布定义。 以前，你没有按文件夹执行搜索的选项。 如果创建了大量文件夹，则很难找到特定的发布定义。 现在可以在发布定义中按文件夹名称进行搜索，以便更轻松地查找要查找的定义。
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: |
我们添加了一个新任务，用于在代理上安装特定版本的 Kubectl 二进制文件。 最新和 semver 版本字符串（如“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 模块的支持。 在生成和发布管道中新的 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 Active Directory (AD) Azure SQL 任务的身份验证支持
Azure SQL任务已得到增强，以支持使用 Azure AD (集成&密码) 和连接字符串以及 SQL Server 身份验证的现有支持连接到数据库。
发布具有长文件路径的生成项目
到目前为止，存在一个限制，阻止上传路径超过 233 个字符的生成项目。 这可能会阻止你上传文件路径长于限制的 Linux 和 macOS 版本的代码覆盖率结果。 限制已更新为支持长路径。
跳过提交 (CI) 的持续集成
现在可以告诉 Azure Pipelines 忽略提交并跳过运行提交通常会触发的管道。 只需包含在[skip ci]HEAD提交的提交消息中，Azure Pipelines 就会跳过 CI。 还可以使用下面列出的任何变体。 提交到 git 和 GitHub Enterprise Server Azure Repos支持此操作。
[skip ci] 或 [ci skip]
skip-checks: true 或 skip-checks:true
[skip azurepipelines] 或 [azurepipelines skip]
[skip azpipelines] 或 [azpipelines skip]
[skip azp] 或 [azp skip]
***NO_CI***
Test Plans
“ 高级) ”小组件 (测试结果趋势 提供对多个生成和发布的测试数据的准实时可见性。 “ 测试结果趋势 (高级) 小组件 显示管道或跨管道的测试结果趋势。 可以使用它来跟踪每日测试计数、通过率和测试持续时间。 跟踪一段时间内的测试质量并改进测试附件是维护正常运行的 DevOps 管道的关键。
“ 高级) ”小组件 (测试结果趋势 可帮助你在测试结果中找到离群值，并回答以下问题：测试的运行时间是否比平时长？ 哪个测试文件或管道会影响我的总体通过率？ 我长时间运行的测试是什么？
为了帮助你回答这些问题，小组件提供了以下功能：
显示通过率的趋势，以及测试结果或测试持续时间的计数
基于多个生成管道或发布管道显示测试结果
使用组合图表选项显示同一趋势的两个指标
按测试结果筛选一段时间内的测试计数
按分支或测试筛选所有测试结果
按“优先级”或“环境”等测试属性堆叠指标
在测试文件、所有者或管道上对数据进行分组
小组件具有高度可配置性，可用于各种方案。
通过 URL 共享测试运行结果
可以将自动测试配置为作为生成或发布的一部分运行。 可以在生成或发布摘要的“ 测试 ”选项卡中查看已发布的测试结果。 在此更新中，我们添加了 “复制结果 URL” 功能，以便你可以与团队中的其他人共享单个测试运行结果。
共享级别包括：
在测试运行中选择的单个选项卡
共享还与配置的任何扩展选项卡兼容
共享 URL 时，查看者将在全屏视图中看到测试运行结果。
Artifacts
具有 SemVer 2.0.0 版本号的 NuGet 包
以前，Azure Artifacts 不支持具有 SemVer 2.0.0 版本号的 NuGet 包，通常 (包含版本的生成元数据部分的版本号，这表示 +) 。 现在，可以从包含生成元数据的 nuget.org 保存包，并使用生成元数据推送自己的包。 根据 SemVer 规范 和 NuGet.org 策略，生成元数据不能用于对包进行排序。 因此，不能将 和 1.0.0+build2 同时1.0.0+build1发布到 Azure Artifacts (或 nuget.org) ，因为这些版本将被视为等效版本，因此受不可变性约束的约束。
通过此更新，我们可以更轻松地了解包的来源：发布包的人员或内容以及它们来自哪些源代码。 在 Azure Pipelines 中使用 NuGet、 npm、 Maven 和 Twine Authenticate (发布的所有包会自动填充此信息，) 任务。
包使用情况统计信息
到目前为止，Azure Artifacts 还没有提供一种方法来衡量包的使用情况或受欢迎程度。 通过此更新，我们向包列表和包详细信息页添加了 下载 和 用户 计数。 你可以在任一页面的右侧看到统计信息。
对 Python 包的支持
Azure Artifacts 现在可以托管 Python 包：你自己生成的包和上游从公共 PyPI 保存的包。 有关更多详细信息，请参阅公告博客文章和 文档。
现在，可以在同一源中托管所有 NuGet、npm、Maven 和 Python 包。
Maven 的上游源
上游源现在可用于 Maven 源。 这包括主要 Maven Central 存储库和 Azure Artifacts 源。 若要将 Maven 上游添加到现有源，请访问源设置，选择“上游源”透视，然后选择“添加上游源”。
到目前为止，许多与项目相关的生成任务尚未提供对 Azure Pipelines 代理基础结构的完全支持，这导致使用本地代理中的任务时面临挑战。 通过此更新，我们已向以下任务添加了对代理的支持：
设计器) 中的Npm@1 (“npm”
NuGetCommand@2 (设计器中的“NuGet”) ：仅还原和推送命令
设计器中的DotNetCoreCLI@2 (.NET Core) ：仅还原和 nuget 推送命令
在设计器) 中NpmAuthenticate@0、PipAuthenticate@0和TwineAuthenticate@0 (“[type] Authenticate”：这些任务在获取身份验证令牌期间支持代理，但仍需要配置任何后续任务/脚本/工具以使用代理。 换句话说，这些任务不会为基础工具配置代理， (npm、pip、twine) 。
设计器) 中的NuGetToolInstaller@0、NodeTool@0 DotNetCoreInstaller@0 (“[type] Installer”
版本中支持的所有项目包类型
到目前为止，Pipelines 版本中的 Azure Artifacts 项目类型 仅支持 NuGet 包。 此更新支持所有 Azure Artifacts 包类型（Maven、npm 和 Python）。
版本中支持的项目视图
以前，Azure Artifacts 项目类型只能在将新包版本发布到源时触发。 现在，我们还添加了对视图的支持，因此你可以在源中已有的包提升为视图时触发发布。
保留策略可以跳过最近下载的包
到目前为止，Azure Artifacts 源已经提供了基本的保留策略，当达到“每个包的最大版本数”时，这些策略将开始删除旧包版本。 通过此更新，我们添加了在执行此清理时跳过最近下载的包的功能。 若要启用，请编辑源并检查跳过最近下载的包复选框。
委托谁可以管理源
在 Azure Artifacts 中， 项目集合管理员 (PCA) 始终能够管理 Azure DevOps 服务器中的所有源。 通过此更新，PCA 还可以为其他用户和组提供此功能，从而委派管理任何源的能力。
编辑 Wiki 时，不再需要记住用于添加 公式、 视频 和 YAML 标记 的 markdown 语法。 现在可以单击工具栏中的上下文菜单，然后选择所选选项。
在 Wiki 中嵌入Azure Boards查询结果
现在可以Azure Boards查询结果以表格的形式嵌入 Wiki 页面。
下图显示了一个 Wiki 页面示例，其中包含已发布的所有功能和嵌入在 Wiki 中的当前冲刺中的所有活动 bug 的列表。 页面中显示的内容使用现有的工作项查询。 借助这项新功能，可以创建动态内容，而无需担心手动更新 Wiki 页面。
可以通过两个步骤添加查询结果：
单击编辑工具栏中的“查询结果”按钮。
Wiki 页面的永久链接
到目前为止，如果链接页面已重命名或移动，共享 Wiki 页面链接会中断。 现在，我们通过向 URL 添加页面 ID 引入了永久链接。 这可确保随着 Wiki 随时间推移的变化，您共享的链接保持不变。
此功能已根据 此 建议票证确定优先级。
在 Wiki 页面中显示工作项状态
在此更新中，我们通过向页面添加工作项的状态及其 ID 和标题，增强了 Wiki 页面中的工作项提及功能。
拉取请求注释和 Boards 讨论中的工作项引用也会显示状态。
@mention 用户和组
现在可以 @mention 在 Wiki 页面中使用用户和组。 这使得文档（如团队的联系人页面、指导文档和知识文档）更加丰富。 下图是一个示例，其中显示了对任务和负责人的冲刺回顾。
@提及用户和组时的外观的屏幕截图。 />
此外，还可以通过在 Wiki 编辑页中键入“@”，从自动建议中选择用户或组。 提到的人员也将通过邮件收到通知。
的屏幕截图。 />
最后，还可以单击用户以查看@mentioned卡配置文件信息。
此功能已根据 此功能 建议确定优先级。
Wiki 页面上的通知
到目前为止，你还没有办法知道何时更改了 Wiki 页面上的内容。 现在，您可以关注 Wiki 页面，在编辑、删除或重命名页面时通过电子邮件收到通知。 若要跟踪对 Wiki 所做的更改，请从 Wiki 页面选择“ 关注 ”按钮。
此功能已根据 此 建议票证确定优先级。 若要了解详细信息，请参阅 此处的文档。
现在，可以使用 HTML 标记在 Wiki 中创建更丰富的内容。 请查看下面的 HTML 标记可以执行的操作。
现在，可以使用 详细信息 和 摘要 标记在 Wiki 页面中创建可折叠部分。 可以添加 open 属性，使详细信息在默认情况下保持展开状态。
有关 details 标记的详细信息，请查看 此处的文档。
这是基于 此建议票证的优先级。
Edge 和 Internet Explorer 浏览器不支持此标记。
改进了表创建和编辑
到目前为止，在 Wiki 中创建和编辑表很困难。 我们进行了更改，以便更轻松地在 Wiki 中添加和管理表。
从网格创建表
不再需要记住 markdown 表语法。 现在，可以通过从 15 X 15 网格中进行选择来轻松创建 markdown 表。 只需选择所需的列数和行即可通过单击插入表。
此功能已根据以下建议票证确定优先级：
Wiki 的表视图
使在 Wiki 中插入表变得简单
提高表可读性
现在可以切换 自动换行 功能，使编辑器能够更好地阅读表格。 禁用自动换行会添加滚动条，使你能够更轻松地查看大型表的内容。
不再需要分析扩展即可使用 Analytics
分析正日益成为 Azure DevOps 体验不可或缺的一部分。 这是客户帮助他们做出数据驱动型决策的一项重要功能。
对于 Update 1，我们很高兴地宣布客户不再需要 Analytics 扩展来使用 Analytics。 客户现在可以在“项目集合设置”下启用分析。 这是一个简单的过程，就在产品中。
下面是客户启用 Analytics 的方式：
导航到“项目集合设置”：
大功告成！ 将为集合启用分析支持的体验。
在 Update 1 和 Azure DevOps Server 2019 集合中创建的新集合，其中安装了已升级的 Analytics 扩展，默认情况下将启用 Analytics。
若要详细了解 Analytics 及其启用的体验，请执行以下操作：
详细了解 如何启用 Analytics。
阅读 分析概述文档。
了解主要功能： 分析小组件、 失败最大的测试报告、 Power BI 集成和 OData 终结点。
观看 有关 Azure DevOps Analytics 的此第 9 频道视频。
我们期待你的宝贵意见和建议！ 可以报告问题或提供想法，并通过开发者社区跟踪它，并获取有关 Stack Overflow 的建议。
