Azure DevOpsServer 2020 Update 1 发行说明

| 开发者社区系统要求 | 许可条款 | DevOps 博客 | SHA-1 哈希

在本文中,你将找到有关Azure DevOps Server最新版本的信息。

若要详细了解如何安装或升级Azure DevOps Server部署,请参阅Azure DevOps Server要求。 若要下载 Azure DevOps 产品,请访问Azure DevOps Server下载页

支持从 Azure DevOps Server 2019 或 Team Foundation Server 2015 或更高版本直接升级到 Azure DevOps Server 2020。 如果 TFS 部署为 TFS 2010 或更低版本,必须先执行一些过渡步骤,然后才能升级到 Azure DevOps Server 2019。 若要了解详细信息,请参阅 在本地安装和配置 Azure DevOps


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

Azure DevOps Server 2020 引入了一个新的管道运行 (生成) 保留模型,该模型基于项目级设置工作。

Azure DevOps Server 2020 基于管道级保留策略以不同的方式处理生成保留。 某些策略配置会导致在升级后删除管道运行。 升级后,不会删除已手动保留或由版本保留的管道运行。

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

Azure DevOps Server 2020 Update 1.2 Patch 4 发布日期:2022 年 12 月 13 日

我们发布了适用于 Azure DevOps Server 2020 Update 1.2 的修补程序,其中包括以下内容的修补程序。

  • 修复了 IdentityPicker 中特殊字符的显示问题。

用于演示 IndetityPicker 中特殊字符的 Gif。

  • 未删除测试数据,导致数据库增长。 通过此修补程序,我们更新了生成保留期,以防止创建新的孤立测试数据。

Azure DevOps Server 2020 Update 1.2 Patch 3 发布日期:2022 年 10 月 18 日

我们发布了适用于 Azure DevOps Server 2020 Update 1.2 的修补程序,其中包括以下内容的修补程序。

  • 解决新添加的 AD 标识未显示在安全对话标识选取器中的问题。
  • 修复了 Web 挂钩设置中组筛选器成员请求的问题。
  • 修复当管道的组织设置的作业授权范围配置为将作业授权范围限制为非发布管道的当前项目时,封闭式签入生成错误。
  • 修复在经过身份验证的代理后建立服务连接时从 Azure 检索访问令牌的问题。

Azure DevOps Server 2020 Update 1.2 修补程序 2 发布日期:2022 年 8 月 9 日

我们发布了适用于 Azure DevOps Server 2020 Update 1.2 的修补程序,其中包括以下内容的修补程序。

  • 修复了将工作项分配给显示在不同域中的标识时出现的标识值错误。

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

我们发布了适用于 Azure DevOps Server 2020 Update 1.2 的修补程序,其中包括以下内容的修补程序。

  • 在“测试运行 API”中,返回的继续标记大于指定的“maxLastUpdatedDate”值。

Azure DevOps Server 2020 Update 1.2 发布日期:2022 年 5 月 17 日

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

注意

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

此版本包括以下内容的修补程序:

  • Azure DevOps Server 2020.1.2 禁用Azure DevOps Server 2020) 中引入的新保留模型 (,以防止管道运行 (生成) 丢失。 这意味着系统将:

    • 为运行 Server 2020 时生成的最近 3 个生成创建租约
    • 对于不按管道保留策略的 YAML 管道和经典管道,将根据集合级别最大保留设置保留生成
    • 对于具有自定义每个管道保留策略的经典管道,将根据特定于管道的保留策略保留生成
    • 具有租约的内部版本不计入“要保留的最小值”设置
  • 更改集和搁置集注释链接未正确重定向。 将注释添加到更改集或搁置集中的文件时,选择这些注释不会重定向到文件视图中的正确位置。

  • 无法使用“运行下一步”按钮跳过生成队列。 以前,“运行下一步”按钮仅为项目集合管理员启用。

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

Azure DevOps Server 2020.1.1 补丁 4 发布日期:2022 年 1 月 26 日

我们发布了适用于 Azure DevOps Server 2020.1.1 的修补程序,其中包括以下修补程序。

  • 在工作项中使用 @mention 控件时,Email通知未发送。
  • 用户个人资料中的首选电子邮件地址未更新。 这导致了电子邮件发送到之前的电子邮件地址。
  • “项目摘要”页中未显示标头。 标头显示了几毫秒,然后消失了。
  • 改进了 Active Directory 用户同步。
  • 通过从 log4j 二进制文件中删除 jndilookup 类来解决 Elasticsearch 漏洞。

安装步骤

  1. 使用 修补程序 4 升级服务器。
  2. 检查 HKLM:\Software\Elasticsearch\Version 的注册表值。 如果注册表值不存在,请添加一个字符串值,并将版本设置为 5.4.1 (Name = Version, Value = 5.4.1)。
  3. 按照自述文件中的说明运行 update 命令 PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update。 它可能会返回类似于下面的警告:无法连接到远程服务器。 请勿关闭窗口,因为更新正在执行重试,直到完成。

注意

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

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

SHA-256 哈希: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 补丁 3 发布日期:2021 年 12 月 15 日

Azure DevOps Server 2020.1.1 的修补程序 3 包括以下修补程序。

  • 修复了包含“包含字词”的查询的工作项宏。 以前,查询为包含换行符的值返回不正确的结果。
  • 提高 Maven 包版本字符长度的限制。
  • 自定义工作项布局状态的本地化问题。
  • 电子邮件通知模板中的本地化问题。
  • 为字段定义多个 NOTSAMEAS 规则时,NOTSAMEAS 规则评估的问题。

Azure DevOps Server 2020.1.1 补丁 2 发布日期:2021 年 10 月 26 日

Azure DevOps Server 2020.1.1 的修补程序 2 包括以下内容的修补程序。

  • 以前,Azure DevOps Server只能创建到 GitHub Enterprise Server 的连接。 使用此修补程序,项目管理员可以在 GitHub.com 上的Azure DevOps Server和存储库之间创建连接。 可以在 “GitHub 连接 ”页的 “项目设置”下找到此设置。
  • 解决测试计划小组件的问题。 测试执行报告显示结果中的错误用户。
  • 修复了“项目概述”摘要页加载失败的问题。
  • 修复了未发送电子邮件以确认产品升级的问题。

Azure DevOps Server 2020.1.1 补丁 1 发布日期:2021 年 9 月 14 日

Azure DevOps Server 2020.1.1 的修补程序 1 包括以下内容的修补程序。

  • 修复项目下载/上传失败。
  • 解决测试结果数据不一致的问题。

Azure DevOps Server 2020 Update 1.1 发布日期:2021 年 8 月 17 日

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

注意

数据迁移工具将在发布后三周左右用于 Azure DevOps Server 2020 Update 1.1。 可在此处查看导入的当前支持的版本列表。

此版本包括针对以下 bug 的修补程序:

Azure Boards

  • 通知电子邮件中的“查看工作项”超链接未使用公共 URL。

Azure Repos

  • 修复了显示的受限合并类型继承复选框,以便在设置跨存储库策略后启用修改限制合并类型。

Azure Pipelines

  • 更改代理更新的设置时,设置不会传播到环境中的其他应用程序层。

常规

  • 修复了服务器配置向导中的拼写问题。
  • 增加了扩展包大小,并允许在注册表中更改大小。

Azure Test Plans

  • 从历史记录页回击到摘要页后,无法导航回测试结果。

Azure DevOps Server 2020.1 修补程序 2 发布日期:2021 年 8 月 10 日

我们发布了 Azure DevOps Server 2020.1 的修补程序,可修复以下问题。

  • 修复生成定义 UI 错误。
  • 更改了浏览历史记录以显示文件而不是根存储库。

Azure DevOps Server 2020.1 修补程序 1 发布日期:2021 年 6 月 15 日

我们发布了 Azure DevOps Server 2020.1 的修补程序,可修复以下问题。

  • 在断言 SameSite=None的授权流中使用的安全 Cookie。

  • 解决通知 SDK 的问题。 以前,未正确分析使用区域路径筛选器的通知订阅。

Azure DevOps Server 2020.1 RTW 发布日期:2021 年 5 月 25 日

Azure DevOps Server 2020.1 RTW 中的新增功能摘要

Azure DevOps Server 2020.1 RTW 是 bug 修复的汇总。 它包括以前发布的 Azure DevOps Server 2020.1 RC2 中的所有功能。 Azure DevOps Server 2020.1 RTW 是 bug 修复的汇总。 可以直接安装 Azure DevOps Server 2020.1 或从 Azure DevOps Server 2020、2019 或 Team Foundation Server 2015 或更高版本升级。

注意

数据迁移工具将在发布后大约三周Azure DevOps Server 2020 Update 1 中提供。 可在此处查看导入的当前支持的版本列表。

Azure DevOps Server 2020.1 RC2 发布日期:2021 年 4 月 13 日

Azure DevOps Server 2020.1 RC2 中的新增功能摘要

Azure DevOps Server 2020.1 RC2 是 bug 修复的汇总。 它包括以前发布的 Azure DevOps Server 2020.1 RC1 中的所有功能。

Azure DevOps Server 2020.1 RC1 发布日期:2021 年 3 月 23 日

Azure DevOps Server 2020.1 RC1 中的新增功能摘要

Azure DevOps Server 2020.1 RC1 引入了许多新功能。 其中一些要点包括:

还可以跳转到各个部分,查看每个服务的所有新功能:


Boards

状态转换限制规则

我们将继续缩小托管 XML 与继承的进程模型之间的功能奇偶一性差距。 此新工作项类型规则允许限制工作项从一个状态移动到另一个状态。 例如,可以限制 Bug 从“新建”到“已解决”。 相反,它们必须从“新建 -> 活动 -> 已解决”

img

还可以创建规则以按组成员身份限制状态转换。 例如,只有“审批者”组中的用户才能从“新建 -> 已批准”移动用户情景。

复制工作项以复制子项

Azure Boards最需要的功能之一是能够复制同时复制子工作项的工作项。 我们在复制工作项对话框中添加了“包括子工作项”的新选项。 选中此选项后,将复制工作项并复制所有子工作项, (最多 100) 。

此页显示Azure Boards“在复制的工作项中包含子工作项”中的新选项。

改进了已激活字段和已解析字段的规则

到目前为止, “激活者”、“ 激活日期”、“ 解决者”和“ 解决日期 ”的规则一直是个谜。 它们仅为系统工作项类型设置,并且特定于状态值“Active”和“Resolved”。 我们更改了逻辑,使这些规则不再适用于特定状态。 相反,它们由状态所在的类别 (状态类别) 触发。 例如,假设你在“已解决”类别中有“需要测试”的自定义状态。 当工作项从“活动”更改为“需要测试”时,将触发 “解决者 ”和“ 解决日期” 规则。

这样,客户就可以创建任何自定义状态值,并且仍生成“ 激活者”、“ 激活日期”、“ 解决者”和“ 解析日期” 字段,而无需使用自定义规则。

利益干系人可以跨板列移动工作项

利益干系人始终能够更改工作项的状态。 但是,当他们转到看板时,他们无法将工作项从一个列移动到另一列。 相反,利益干系人必须一次打开一个工作项,并更新状态值。 长期以来,这一直是客户的痛点,我们很高兴地宣布,你现在可以跨板列移动工作项。

积压工作和板上的系统工作项类型

现在可以将系统工作项类型添加到所选的积压工作级别。 过去,这些工作项类型仅在查询中可用。

过程 工作项类型
敏捷 问题
Scrum 障碍
CMMI 更改请求
问题
复习
风险

将系统工作项类型添加到积压工作级别非常简单。 只需进入自定义流程,然后单击“ 积压工作级别”选项卡。选择所选的积压工作级别 (示例:要求积压工作) ,然后选择编辑选项。 然后添加工作项类型。

积压

Azure Boards GitHub 应用存储库限制提高

GitHub 市场中Azure Boards应用程序的存储库限制已从 100 增加到 250。

自定义合并拉取请求时的工作项状态

并非所有工作流都是相同的。 一些客户希望在拉取请求完成后关闭其相关工作项。 另一些则希望将工作项设置为另一个状态,以在关闭之前进行验证。 我们应该允许两者兼而有之。

我们有一项新功能,可用于在拉取请求合并和完成时将工作项设置为所需状态。 为此,我们扫描拉取请求说明,并查找状态值后跟工作项#mention () 。 在此示例中,我们将两个用户情景设置为“已解决”,并关闭两个任务。

work-item-state

现在,只需将工作项链接到生成、在生成中查找或集成,即可轻松跟踪项目中的生成依赖项。

链接工作项

编辑说明 (系统字段上的帮助文本)

始终能够编辑自定义字段的说明。 但对于优先级、严重性和活动等系统字段,说明不可编辑。 这是 Hosted XML 和 Inherited 之间的功能差距,导致某些客户无法迁移到继承模型。 现在可以编辑系统字段的说明。 编辑的值将仅影响进程中和该工作项类型的该字段。 这使你能够灵活地对不同工作项类型上的同一字段使用不同的说明。

编辑说明

在合并拉取请求时自定义工作项状态

拉取请求通常引用多个工作项。 创建或更新拉取请求时,可能需要关闭其中一些拉取请求,解析其中一些拉取请求,并使其余部分保持打开状态。 现在可以使用注释(如下图所示的注释)来实现此目的。 有关 更多详细信息,请参阅文档

自定义状态

任务板上的父域

由于热门请求,你现在可以将“父”字段添加到任务板上的子卡和父卡。

父域任务板

删除 Bug 工作项类型的“分配到”规则

敏捷、Scrum 和 CMMI 中的所有不同工作项类型都有几个隐藏的系统规则。 这些规则已经存在了十多年,而且一般情况下没有任何投诉就行。 但是,有一些规则已经用尽了他们的欢迎。 特别是一条规则给新客户和现有客户造成了很大的痛苦,我们决定是时候删除它了。 此规则存在于敏捷过程中的 Bug 工作项类型上。

“将状态更改为”已解决“时,将”分配“值设置为”创建者”

我们收到了你关于此规则的大量反馈。 作为响应,我们继续从敏捷过程中的 Bug 工作项类型中删除了此规则。 此更改将影响使用继承的敏捷或自定义继承的敏捷过程的每个项目。 对于喜欢并依赖此当前规则的客户,请参阅我们的 博客文章 ,了解使用自定义规则重新添加规则的步骤。

删除了“工作项”页上的项

工作项”页 是快速查找已创建或分配给你的项目等项的绝佳位置。 它提供多个个性化透视表和筛选器。 “分配给我”透视表的主要投诉之一是,它显示已删除的工作项 (即处于“已删除”状态的工作项) 。 我们同意! 已删除的项是不再具有价值的工作,因此已从积压工作中删除,因此在此视图中包含它没有用。

现在可以在“工作项”页上的“分配给我”透视中隐藏所有已删除的项目。

Repos

默认分支名称首选项

Azure Repos现在为 Git 提供可自定义的默认分支名称。 在存储库设置中,可以选择在初始化存储库时使用的任何法定分支名称。 Azure Repos始终支持更改现有存储库的默认分支名称。 有关更多详细信息 ,请访问管理分支

 default-branch-name

注意:如果未启用此功能,则存储库将使用Azure Repos的默认名称进行初始化。 现在,该默认值为 master。 为了履行 Microsoft 对包容性语言的承诺和客户对语言的要求,我们将与 行业同行一 起将此默认值更改为 main。 这种变化将在今年夏天晚些时候发生。 如果要继续使用 master,则应立即打开此功能并将其设置为 master

默认分支的组织级别设置

现在有一个集合级别设置,用于新存储库的首选初始分支名称。 如果项目尚未选择初始分支名称,则将使用此组织级别设置。 如果未在组织设置或项目设置中指定初始分支名称,则新存储库将使用 Azure DevOps 定义的默认值。

组织级别的分支设置

添加新的身份验证范围,用于贡献 PR 注释

此版本添加了一个新的 OAuth 范围,用于读取/写入拉取请求注释。 如果机器人或自动化只需与批注交互,则可以仅向它提供具有此范围的 PAT。 如果自动化有 bug 或令牌泄露,则此过程会减少爆炸半径。

拉取请求体验改进

新的拉取请求体验已得到以下改进:

  • 使可选检查更可见

客户使用可选检查来吸引开发人员关注潜在问题。 在以前的经验中,当这些检查失败时,情况过去是显而易见的。 但是,预览体验中的情况并非如此。 所需检查上的绿色大复选标记可屏蔽可选检查中的失败。 用户只能通过打开检查面板来发现可选检查失败。 没有问题的迹象时,开发人员通常不会这样做。 在此部署中,我们使可选检查的状态在摘要中更加明显。


显示可选检查


  • 按 Ctrl 单击菜单项

PR 上的选项卡菜单不支持 Ctrl 单击。 用户通常会在查看拉取请求时打开新的浏览器选项卡。 此问题已解决。

  • [+] 批注的位置

PR 中的文件树列表显示注释 [+],以帮助作者和审阅者识别新文件。 由于批注在省略号之后,因此对于较长的文件名,它通常不可见。


显示批注的位置

  • PR 更新下拉列表重新获取计时信息

用于选择 PR 中的更新和比较文件的下拉列表在预览体验中丢失了一个重要元素。 它未显示更新的发生时间。 此问题已解决。


PR 更新下拉列表中缺少计时信息

  • **改进了批注筛选器布局 **

在拉取请求的摘要页上筛选注释时,下拉列表位于右侧,但文本是左对齐的。 此问题已解决。


改进了批注筛选器布局

  • 导航到父提交

在“提交”页下,可以将特定提交中所做的更改与其父提交进行比较。 但是,你可能想要导航到父提交,并进一步了解该提交与其自己的父提交有何不同。 当你想要了解发布中的所有更改时,通常需要这样做。 我们在提交中添加了父 () 卡,以帮助你实现此目的。


导航到父提交

  • 在“PR 文件”选项卡中为具有长名称的文件夹和文件提供更多空间

由于文件树中缺少水平间距,具有长名称的文件夹和文件被切断。 我们通过修改树的缩进以匹配根节点,并通过在页面上隐藏省略号按钮(悬停时除外)来恢复树中的一些额外空间。

新文件树的图像:


为文件夹和文件提供更多空间

将鼠标悬停在目录上时文件树的图像:


名称显示

  • 在 PR 文件选项卡中调整差异窗格的大小时保留滚动位置

在“PR 文件”选项卡中调整并排差异窗格的大小时,用户的滚动位置将丢失。 此问题已修复;用户的滚动位置现在保留在调整差异窗格的大小上。

  • 在移动设备上搜索提交

在移动设备上查看“提交”页时,新体验中缺少搜索框。 因此,很难通过哈希找到提交并将其打开。 此问题现已修复。


在移动设备上搜索提交

  • 改进了新 PR 文件差异移动视图的空间使用情况

我们更新了此页面以更好地利用空间,以便用户可以在移动视图中查看更多文件,而不是使标题占用 40% 的屏幕。


改进了空间新 PR 文件名的使用

  • PR 摘要视图中的增强图像

在 PR 中编辑的图像未显示在 PR 摘要视图中,但在 PR 文件视图中正确显示。 此问题已解决。

  • 创建新 PR 时增强的分支体验

在此更新之前,这种体验并不理想,因为它会将更改与存储库的默认分支而不是比较分支进行比较。


分支体验增强

管道

其他代理平台:ARM64

我们已将 Linux/ARM64 添加到 Azure Pipelines 代理支持的平台列表中。 尽管代码更改很少,但许多幕后工作必须首先完成,我们很高兴地宣布其发布!

管道资源的标记筛选器支持

现在,我们已在 YAML 管道中添加了“标记”。 可以使用标记将 CI 管道设置为运行或何时自动触发。

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

上面的代码片段显示,标记可用于确定当 CD (持续部署) 管道运行未由某些其他源/资源或计划运行触发器触发时要运行的 CI (持续集成) 管道的默认版本。

例如,如果为 CD 管道设置了计划触发器,而你只想在 CI 具有生产标记时运行该触发器,则触发器部分中的标记可确保仅在 CI 完成事件满足标记条件时才触发 CD 管道。

控制管道中允许的任务

现在可以禁用市场任务。 你们中的一些人可能允许市场扩展,但不允许他们带来的管道任务。 为了获得更多控制,我们还允许你独立禁用除签出以外的所有现成 (任务,这是) 的特殊操作。 启用这两个设置后,允许在管道中运行的唯一任务是使用 tfx 上传的任务。 访问 https://dev.azure.com/<your_org>/_settings/pipelinessettings 并查找名为“任务限制”的部分以开始使用。

独占部署锁定策略

通过此更新,可以确保一次只有一个运行部署到环境。 通过在环境中选择“独占锁”检查,只会继续一次运行。 要部署到该环境的后续运行将暂停。 使用排他锁的运行完成后,最新运行将继续。 将取消任何中间运行。

在“添加”检查页中,选择“独占锁”,确保一次只有一个运行部署到环境。

管道资源触发器的阶段筛选器

我们添加了对“阶段”的支持,作为 YAML 中管道资源的筛选器。 使用此筛选器,无需等待整个 CI 管道完成以触发 CD 管道。 现在可以选择在 CI 管道中的特定阶段完成后触发 CD 管道。

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

在 CI 管道中成功完成触发器筛选器中提供的阶段后,会自动为 CD 管道触发新的运行。

YAML 管道的基于 Webhook 的通用触发器

目前,我们拥有各种资源 (,例如管道、容器、生成和包) ,通过这些资源可以使用项目并启用自动触发器。 但是,到目前为止,你无法根据其他外部事件或服务自动执行部署过程。 在此版本中,我们将在 YAML 管道中引入 Webhook 触发器支持,以实现管道自动化与任何外部服务的集成。 可以通过其 webhook 订阅任何外部事件, (Github、Github Enterprise、Nexus、Aritfactory 等) 并触发管道。

下面是配置 Webhook 触发器的步骤:

  1. 在外部服务上设置 Webhook。 创建 Webhook 时,需要提供以下信息:

    • 请求 URL - “https://dev.azure.com/<ADO collection>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview”
    • 机密 - 这是可选的。 如果需要保护 JSON 有效负载,请提供 “机密”
  2. 创建新的“传入 Webhook”服务连接。 这是新引入的服务连接类型,可用于定义三条重要信息:

    • Webhook 名称:Webhook 的名称应与在外部服务中创建的 Webhook 匹配。
    • HTTP 标头 - 请求中 HTTP 标头的名称,其中包含用于请求验证的有效负载哈希值。 例如,对于 GitHub,请求标头将为“X-Hub-Signature
    • 机密 - 机密用于分析用于验证传入请求的有效负载哈希, (这是可选的) 。 如果在创建 Webhook 时使用了机密,则需要提供相同的密钥

    在“编辑服务连接”页中,配置 Webhook 触发器。

  3. YAML 管道中引入了名为 的新 webhooks 资源类型。 若要订阅 Webhook 事件,需要在管道中定义 Webhook 资源,并将其指向传入 Webhook 服务连接。 还可以基于 JSON 有效负载数据在 Webhook 资源上定义其他筛选器,以进一步自定义每个管道的触发器,并且可以在作业中以变量的形式使用有效负载数据。

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}
  1. 每当传入 Webhook 服务连接收到 Webhook 事件时,将为订阅 Webhook 事件的所有管道触发新运行。

YAML 资源触发器问题支持和可跟踪性

当管道触发器无法按预期执行时,可能会造成混淆。 为了帮助更好地了解这一点,我们在管道定义页中添加了一个名为“触发器问题”的新菜单项,其中显示了有关触发器未执行的原因的信息。

资源触发器可能由于两个原因而无法执行。

  1. 如果提供的服务连接的源无效,或者触发器中存在任何语法错误,则根本不会配置触发器。 这些错误显示为错误。

  2. 如果触发器条件不匹配,则不会执行触发器。 每当发生这种情况时,都会显示一条警告,以便你可以了解条件不匹配的原因。

    此名为“触发器问题”的管道定义页显示有关触发器未运行的原因的信息。

多存储库触发器

可以在一个 YAML 文件中指定多个存储库,并导致任何存储库的更新触发管道。 此功能非常有用,例如,在以下方案中:

  • 使用来自不同存储库的工具或库。 每当更新工具或库时,你都希望为应用程序运行测试。
  • 将 YAML 文件保存在与应用程序代码不同的存储库中。 你希望在每次将更新推送到应用程序存储库时触发管道。

通过此更新,多存储库触发器仅适用于 Azure Repos 中的 Git 存储库。 它们不适用于 GitHub 或 BitBucket 存储库资源。

以下示例演示如何在管道中定义多个存储库资源,以及如何在所有这些资源上配置触发器。

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

如果存在以下任何更新,将触发此示例中的管道:

  • main 包含 YAML 文件的存储库中的 self 分支
  • mainrelease 存储库中的 tools 分支

有关详细信息,请参阅 管道中的多个存储库

改进了代理日志上传

当代理停止与 Azure Pipelines 服务器通信时,它正在运行的作业将被放弃。 如果碰巧正在查看流式处理控制台日志,则可能在代理停止响应之前已获取一些有关其状态的线索。 但是,如果没有,或者刷新了页面,这些控制台日志将消失。 在此版本中,如果代理在发送完整日志之前停止响应,我们会将控制台日志保留为下一个最佳状态。 控制台日志限制为每行 1000 个字符,有时可能不完整,但它们比不显示任何内容更有用! 检查这些日志可能有助于排查自己的管道问题,这肯定会帮助我们的支持工程师帮助进行故障排除。

(可选)将容器卷装载为只读

在 Azure Pipelines 中运行容器作业时,包含工作区、任务和其他材料的多个卷将映射为卷。 这些卷默认为读/写访问权限。 为了提高安全性,可以通过在 YAML 中更改容器规范,以只读方式装载卷。 对于只读,下 mountReadOnly 的每个键都可以设置为 true , (默认值为 false) 。

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

对容器启动/停止的精细控制

通常,我们建议允许 Azure Pipelines 管理作业和服务容器的生命周期。 但是,在某些不常见的方案中,可能需要自行启动和停止它们。 在此版本中,我们已将该功能内置到 Docker 任务中。

下面是使用新功能的示例管道:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

此外,我们还在管道变量 Agent.ContainerMapping中包含容器列表。 例如,如果要检查脚本中的容器列表,则可以使用此方法。 它包含一个字符串化的 JSON 对象,将上述示例中的资源名称 (“builder”) 映射到代理管理的容器 ID。

解压缩每个步骤的任务捆绑包

当代理运行作业时,它首先下载该作业的步骤所需的所有任务捆绑包。 通常,为了提高性能,即使任务在多个步骤中使用,它也会为每个作业解压缩一次任务。 如果担心不受信任的代码会更改解压缩的内容,可以通过让代理在每次使用时解压缩任务来换取一点性能。 若要启用此模式,请在配置代理时传递 --alwaysextracttask

通过限制访问令牌的范围提高发布安全性

基于增强 Azure Pipelines 安全设置的计划,我们现在支持限制发布访问令牌的范围。

在版本中运行的每个作业都会获得一个访问令牌。 访问令牌由任务和脚本用来回调到 Azure DevOps 中。 例如,我们使用访问令牌获取源代码、下载项目、上传日志、测试结果或对 Azure DevOps 进行 REST 调用。 将为每个作业生成一个新的访问令牌,并在作业完成后过期。

通过此更新,我们通过限制访问令牌的范围并将相同的范围扩展到经典版本,从而改进管道安全性。

默认情况下,对于新项目和集合,此功能将启用。 对于现有集合,必须在集合设置管道设置>>中启用它。 >将作业授权范围限制为发布管道的当前项目。 在此处了解更多信息。

YAML 预览 API 增强功能

现在可以预览管道的完整 YAML ,而无需运行它。 此外,我们还为预览功能创建了一个专用的新 URL。 现在可以 POST 到 https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview 以检索最终的 YAML 正文。 此新 API 采用与排队运行相同的参数,但不再需要“队列生成”权限。

接下来运行此作业

你是否曾经有过需要 立即 部署的 bug 修复,但必须等待 CI 和 PR 作业? 在此版本中,我们现在允许提高排队作业的优先级。 对池具有“管理”权限的用户(通常是池管理员)将在作业详细信息页上看到新的“运行下一步”按钮。 单击该按钮将尽快将作业设置为运行。 (当然,你仍然需要可用的并行度和合适的代理。)

YAML resources 块中允许的模板表达式

以前,Azure Pipelines YAML 文件的 部分不允许resources使用编译时表达式 (${{ }}) 。 在此版本中,我们解除了容器的此限制。 这允许在资源中使用 运行时参数 内容,例如在队列时选取容器。 我们计划随着时间的推移将此支持扩展到其他资源。

控制市场中的自动任务更新

编写 YAML 管道时,通常仅指定包含任务的主版本号。 这允许管道自动获取最新功能添加和 bug 修复。 有时可能需要回滚到任务的上一个点版本,通过此更新,我们添加了执行此操作的功能。 现在可以在 YAML 管道中指定完整的 major.minor.patch 任务版本。

不建议定期执行此操作,仅在发现较新的任务中断管道时将其用作临时解决方法。 此外,这不会从市场安装较旧版本的任务。 它必须已存在于集合中,否则管道将失败。

示例:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

代理和任务中的节点 10 支持

由于不再支持节点 6,因此我们将迁移任务以使用节点 10。 对于此更新,我们已将近 50% 的内置任务迁移到节点 10。 代理现在可以运行节点 6 和节点 10 任务。 在将来的更新中,我们将从代理中完全删除节点 6。 为了准备从代理中删除节点 6,我们要求更新内部扩展和自定义任务,以便也尽快使用节点 10。 若要将 Node 10 用于任务,请在 task.json中的 下 execution,将 从 Node 更新为 Node10

在经典生成设计器中改进 YAML 转换

在此版本中,我们为设计器生成管道引入了新的“导出到 YAML”功能。 保存管道定义,然后在菜单上找到“导出到 YAML”。...

新的导出函数替换了以前在经典生成设计器中找到的“View as YAML”函数。 该函数不完整,因为它只能检查 Web UI 对生成的了解,这有时会导致生成不正确的 YAML。 新的导出函数准确考虑管道的处理方式,并生成与设计器管道完全保真的 YAML。

新的 Web 平台转换 - 存储库设置

我们已将两个存储库设置页面转换为已升级到新 Web 平台的单个体验。 此升级不仅使体验更快、更现代,而且这些页面还为从项目级别到分支级别的所有策略提供单一入口点。

新的 Web 平台转换。

有了这一新体验,由于加载速度更快,并且增加了搜索筛选器,对具有大量存储库的项目的导航变得更加容易。 还可以在“策略”选项卡下查看项目级策略和跨存储库策略列表。

在“策略”选项卡下查看跨存储库策略。

如果单击存储库,可以查看在存储库级别设置的策略和权限。 在“策略”选项卡中,可以查看设置策略的每个分支的列表。 现在,单击分支可查看所有策略,同时从不离开“存储库设置”页。

选择“分支”以查看策略。

现在,当策略继承自你正在使用的范围更大时,我们会在每个策略旁边显示策略继承自的位置。 还可以通过单击范围名称导航到设置了更高级别策略的页面。

显示策略的继承位置。

策略页面本身也已升级到具有可折叠部分的新 Web 平台! 为了改进查找特定生成验证、状态检查或自动审阅者策略的体验,我们为每个部分添加了搜索筛选器。

搜索每个部分的筛选器。

ServiceNow 更改管理与 YAML 管道的集成

适用于 ServiceNow 的 Azure Pipelines 应用可帮助你集成 Azure Pipelines 和 ServiceNow 更改管理。 通过此更新,我们将让 Azure Pipelines 了解在 ServiceNow 中进一步管理更改管理过程,并进一步迁移到 YAML 管道。

通过在资源上配置“ServiceNow 更改管理”检查,现在可以在将生成部署到该资源之前暂停以批准更改。 可以自动为某个阶段创建新更改,也可以等待现有更改请求。


ServiceNow 变更管理集成

还可以在 UpdateServiceNowChangeRequest 服务器作业中添加任务,以使用部署状态、说明等更新更改请求。

Artifacts

能够从 UI 创建组织范围的源

我们将恢复客户通过 Web UI 为本地和托管服务创建和管理集合范围的源的能力。

现在,可以通过 UI 创建组织范围的源,方法是转到“项目 -> 创建源”,并在“作用域”中选择一种源类型。

选择“项目”,然后选择“创建源”,并在“作用域”中选择一种源类型,创建集合范围的源。

虽然我们建议使用项目范围的源,以与 Azure DevOps 产品/服务的其余部分保持一致,但你可以再次通过 UI 和各种 REST API 创建、管理和使用集合范围的源。 有关详细信息,请参阅我们的源文档。

更新包版本 REST API 现在可用于 Maven 包

现在可以使用 Azure 项目“更新包版本”REST API 来更新 Maven 包版本。 以前,可以使用 REST API 更新 NuGet、Maven、npm 和通用包的包版本,但不能更新 Maven 包。

若要更新 Maven 包,请使用 HTTP PATCH 命令,如下所示。

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

可以设置以下内容:

URI 参数

名称 位于 必需 类型 说明
artifactId path TRUE string 包的项目 ID
feed path TRUE 字符串 源的名称或 ID
groupId path TRUE 字符串 包的组 ID
collection path TRUE 字符串 Azure DevOps 集合的名称
版本 path TRUE 字符串 包的版本
project path string 项目 ID 或项目名称
api-version query TRUE 字符串 要使用的 API 版本。 应将其设置为“5.1-preview.1”才能使用此版本的 API

请求正文

名称 类型 说明
视图 JsonPatchOperation 将向其添加包版本的视图

有关详细信息,请参阅 更新 REST API 文档

反馈

我们期待你的宝贵意见和建议! 可以报告问题或提供想法,并通过开发者社区跟踪它,并获取有关 Stack Overflow 的建议。


返回页首