Azure DevOps Server 2022 Update 1 发行说明


| 开发者社区System 要求和兼容性 | 许可条款 | DevOps 博客 | SHA-256 哈希 | |


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

若要详细了解如何安装或升级 Azure DevOps Server 部署,请参阅 Azure DevOps Server 要求

若要下载 Azure DevOps Server 产品,请访问 Azure DevOps Server 下载页

Azure DevOps Server 2019 或 Team Foundation Server 2015 或更高版本支持直接升级到 Azure DevOps Server 2022 Update 1。 如果 TFS 部署在 TFS 2013 或更早版本上,则需要在升级到 Azure DevOps Server 2022 之前执行一些临时步骤。 有关详细信息,请参阅安装页


Azure DevOps Server 2022 Update 1 修补程序 4 发布日期:2024 年 6 月 11 日

文件 SHA-256 哈希
devops2022.1patch4.exe 29012B79569F042E2ED4518CE7216CA521F9435CCD80295B71F734AA60FCD03F

我们发布了 Azure DevOps Server 2022 Update 1 的修补程序 4 ,其中包括以下修补程序。

  • 修复了 wiki 和工作项目中的一个问题,其中搜索结果不适用于具有土耳其“I”名称的项目(其名称为土耳其区域设置)。

Azure DevOps Server 2022 Update 1 修补程序 3 发布日期:2024 年 3 月 12 日

文件 SHA-256 哈希
devops2022.1patch3.exe E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

我们发布了 Azure DevOps Server 2022 Update 1 的修补程序 3 ,其中包括以下修补程序。

  • 解决了安装 Patch 2 后代理服务器停止工作的问题。
  • 修复了扩展详细信息页上影响非英语语言的呈现问题。

Azure DevOps Server 2022 Update 1 修补程序 2 发布日期:2024 年 2 月 13 日

文件 SHA-256 哈希
devops2022.1patch2.exe 59B3191E86DB787F91FD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

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

  • 修复搜索扩展插件上的详细信息页面呈现问题。
  • 修复了代理缓存文件夹使用的磁盘空间不正确且文件夹未正确清理的 bug。
  • CVE-2024-20667:Azure DevOps Server 远程代码执行漏洞。

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

文件 SHA-256 哈希
devops2022.1patch1.exe 9D0FDCCD1F20461E586689B756E600CC16424018A3377042F7DC3A6EEF096FB6

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

  • 阻止在管道运行队列时设置 requested for

Azure DevOps Server 2022 Update 1 发布日期:2023 年 11 月 28 日

注意

此版本存在两个已知问题:

  1. 升级到 Azure DevOps Server 2022.1 并使用代理池配置中的更新代理后,代理版本不会更新。 我们目前正在研究一个修补程序来解决此问题,并在开发者社区中共享更新,因为我们正在进行。 在此期间,可以在此开发者社区票证中找到此问题的解决方法。
  2. Maven 3.9.x 兼容性。 Maven 3.9.x 通过将默认 Maven 解析程序传输更新为 Wagon 中的本机 HTTP,引入了 Azure Artifacts 的重大更改。 这会导致使用 http 而不是 https 的客户出现 401 身份验证问题。 可在此处找到有关此问题的更多详细信息。 解决方法是,可以继续使用具有属性 -Dmaven.resolver.transport=wagon的 Maven 3.9.x。 此更改强制 Maven 使用 Wagon 冲突解决程序传输。 有关更多详细信息,请查看此处的文档

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

注意

Maven 3.9.x 兼容性存在已知问题。 Maven 3.9.x 通过将默认 Maven 解析程序传输更新为 Wagon 中的本机 HTTP,引入了 Azure Artifacts 的重大更改。 这会导致使用 http 而不是 https 的客户出现 401 身份验证问题。 可在此处找到有关此问题的更多详细信息。

解决方法是,可以继续使用具有属性 -Dmaven.resolver.transport=wagon的 Maven 3.9.x。 此更改强制 Maven 使用 Wagon 冲突解决程序传输。 有关更多详细信息,请查看此处的文档

Azure DevOps Server 2022 Update 1 RC2 发布日期:2023 年 10 月 31 日

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

注意

Maven 3.9.x 兼容性存在已知问题。 Maven 3.9.x 通过将默认 Maven 解析程序传输更新为 Wagon 中的本机 HTTP,引入了 Azure Artifacts 的重大更改。 这会导致使用 http 而不是 https 的客户出现 401 身份验证问题。 可在此处找到有关此问题的更多详细信息。

解决方法是,可以继续使用具有属性 -Dmaven.resolver.transport=wagon的 Maven 3.9.x。 此更改强制 Maven 使用 Wagon 冲突解决程序传输。 有关更多详细信息,请查看此处的文档

此版本已修复以下问题:

  • 修复了本地源中上游条目未解析显示名称更改的问题。
  • 将选项卡从“代码”切换到“搜索”页上的另一个选项卡时发生意外错误。
  • 使用中文、日语和朝鲜语(CJK)统一象形字创建新工作项类型时出错。 当团队项目名称或文件包含 CJK 时,原始日志上会显示问号。
  • 修复了在安装搜索期间,Java 虚拟机(JVM)无法向弹性搜索进程分配足够的内存的问题。 搜索配置小组件现在将使用与弹性搜索捆绑在一起的 Java 开发工具包(JDK),从而删除预安装在目标服务器上的任何 Java 运行时环境(JRE)的依赖项。

Azure DevOps Server 2022 Update 1 RC1 发布日期:2023 年 9 月 19 日

Azure DevOps Server 2022.1 RC1 包含许多新功能。 其中一些重要内容包括:

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


常规

所有公共 REST API 都支持精细 PAT 范围

以前,许多公开记录的 Azure DevOps REST API 与范围(例如工作项读取)无关,这些 API 导致客户使用完整范围通过非交互式身份验证机制(如个人访问令牌(PAT)使用这些 API。 使用完整的范围个人访问令牌会增加在恶意用户手中时的风险。 这是许多客户没有充分利用 控制平面策略 来限制 PAT 的使用和行为的主要原因之一。

现在,所有公共 Azure DevOps REST API 现在都与并支持精细的 PAT 范围相关联。 如果当前使用全范围 PAT 向某个公共 Azure DevOps REST API 进行身份验证,请考虑迁移到具有 API 接受的特定范围的 PAT,以避免不必要的访问。 在文档页的“安全性”部分可以找到给定 REST API 支持的精细 PAT 范围。 此外,此处还有一个范围表。

扩展应显示其作用域

将扩展安装到 Azure DevOps 集合时,可以在安装过程中查看扩展所需的权限。 但是,安装扩展后,扩展权限在扩展设置中不可见。 这给需要定期评审已安装扩展的管理员带来了挑战。 现在,我们已将扩展权限添加到扩展设置,以帮助你查看和决定是否保留扩展设置。

创建要部署到市场的个人访问令牌

Boards

“交付计划”页上的“上次访问”列

“传递计划”目录页提供为项目定义的计划列表。 可以按:名称、创建者、说明、上次配置或收藏夹进行排序。 通过此更新,我们已将“上次访问”列添加到目录页。 这提供上次打开并查看交付计划时间的可见性。 因此,可以轻松识别不再使用且可删除的计划。

“交付计划”页上的“上次访问”字段的 Gif。

可视化交付计划上的所有依赖项

交付计划始终提供跨工作项查看依赖项的功能。 可以逐个可视化依赖项行。 通过此版本,我们通过允许你查看屏幕上所有工作项的所有依赖项行来改进体验。 只需单击交付计划右上角的依赖项切换按钮即可。 再次单击以关闭行。

Gif 演示了“交付计划”页上的所有依赖项的可视化。

新的工作项修订限制

在过去的几年里,我们已经看到使用自动化工具的项目集合生成了数以万计的工作项修订。 这会在工作项窗体和报告 REST API 上创建性能和可用性问题。 为了缓解此问题,我们实现了对 Azure DevOps 服务 10,000 的工作项修订限制。 该限制仅影响使用 REST API 的更新,而不会影响工作项窗体。

单击此处 了解有关修订限制以及如何在自动化工具中处理修订限制的详细信息。

将交付计划团队限制从 15 增加到 20

通过交付计划,可以查看项目集合中的多个积压工作和多个团队。 以前,可以查看 15 个团队积压工作,包括来自不同项目的积压工作和团队的组合。 在此版本中,我们将最大限制从 15 增加到 20。

修复了“报告工作项链接获取 API”中的 bug,以返回链接类型的正确 remoteUrl 值 System.LinkTypes.Remote.Related 。 在修复之前,我们返回了错误的项目集合名称和缺少的项目 ID。

创建临时查询 REST 终结点

我们看到了多个扩展作者尝试通过查询字符串传递工作项查询语言(WIQL)语句来运行未保存的查询的实例。 除非有达到查询字符串长度的浏览器限制的大型 WIQL 语句,否则这可以正常工作。 为了解决此问题,我们创建了一个新的 REST 终结点,以允许工具作者生成临时查询。 使用响应中的 ID 通过 querystring 传递可消除此问题。

临时查询 REST API 文档页中了解详细信息。

批量删除 API

目前,从回收站中删除工作项的唯一方法是使用此 REST API 一次删除一个。 这可以是一个缓慢的过程,在尝试进行任何类型的大规模清理时,会受到速率限制。 作为响应,我们添加了一个新的 REST API 终结点,用于批量删除和/或销毁工作项。

@CurrentIteration 传递计划中的宏

通过此更新,我们添加了对传递计划中样式的 @CurrentIteration 宏的支持。 通过此宏,可以从计划中每一行的团队上下文中获取当前迭代。

在交付计划中演示 CurrentIteration 宏的 Gif。

交付计划中的卡片调整逻辑大小

并不是每个人都在跟踪功能和史诗时使用目标日期和时间和/或开始日期。 有些选择使用日期和迭代路径的组合。 在此版本中,我们改进了逻辑,根据迭代路径和日期字段组合的使用方式来适当设置迭代路径和日期字段组合。

例如,如果未使用目标日期并重设卡片大小,则会设置新的迭代路径,而不是更新目标日期。

用于演示的 Gif 复制批注链接。

批量更新改进

我们对工作项批处理更新 API 的 7.1 版本进行了多项更改。 其中包括轻微的性能改进和部分故障的处理。 这意味着,如果一个修补程序失败,但其他修补程序失败,其他修补程序将成功完成。

单击此处 了解有关批处理更新 REST API 的详细信息。

批量删除 API

此用于删除和/或销毁批处理中工作项的新 REST API 终结点现已公开发布。 单击此处了解详细信息。

阻止编辑可共享选取列表字段

自定义字段跨进程共享。 这可能导致选择列表字段出现问题,因为我们允许进程管理员在字段中添加或删除值。 执行此操作时,更改会影响使用该字段的每个进程。

为了解决此问题,我们添加了集合管理员“锁定”字段不被编辑的功能。 锁定选取列表字段时,本地进程管理员无法更改该选取列表的值。 他们只能从进程添加或删除字段。

可共享选择列表字段的 Gif 到演示编辑。

新的保存注释权限

仅保存工作项注释的功能是开发人员社区的首要请求。 我们很高兴地让你知道我们实现了此功能。 首先,让我们回顾一下最常见的方案:

“我想阻止某些用户编辑工作项字段,但允许他们参与讨论。

若要完成此操作,需要转到 “项目设置 > 项目配置 > 区域路径”。 然后选择所选的区域路径,然后单击“安全性”。

区域路径

请注意新的权限“在此节点中编辑工作项注释”。 默认情况下,权限设置为 “未设置”。 这意味着,工作项的行为与之前的行为完全相同。 若要允许组或用户保存批注,请选择该组/用户,并将权限更改为“允许”。

新权限

当用户在此区域路径中打开工作项窗体时,他们将能够添加注释,但无法更新任何其他字段。

演示可共享选取列表字段的编辑。

我们希望你和我们一样喜欢此功能。 和往常一样,如果你有任何反馈或建议, 请告诉我们

交互式板报表

交互式报表位于 Boards 中心,在我们的托管产品版本中已可访问多年。 它们替换了较旧的累积流图、速度和冲刺燃尽图表。 在此版本中,我们将提供它们。

若要查看这些图表,请单击看板、积压工作和冲刺页面上的 “分析 ”选项卡位置。

交互式报表

Repos

删除分支创建者的“编辑策略”权限

以前,创建新分支时,我们被授予编辑该分支上的策略的权限。 通过此更新,我们将更改默认行为,不再授予此权限(即使存储库启用了“权限管理”设置)。

权限管理映像。

你需要具备通过安全权限继承或组成员身份显式授予的“编辑策略”权限(手动或通过 REST API)。

管道

当前项目设置为经典管道中生成访问令牌的默认范围

Azure Pipelines 使用作业访问令牌在运行时访问 Azure DevOps 中的其他资源。 作业访问令牌是 Azure Pipelines 在运行时为每个作业动态生成的安全令牌。 以前,创建新的经典管道时,访问令牌的默认值设置为 Project Collection。 通过此更新,我们将在创建新的经典管道时将作业授权范围设置为 当前项目 作为默认值。

可以在 Access 存储库、项目和其他资源文档中找到有关作业访问令牌的更多详细信息。

在经典生成管道中更改访问令牌的默认范围

为了提高经典生成管道的安全性,创建新管道时,默认情况下, 生成作业授权范围 将为 Project。 到目前为止,它曾经是 项目集合详细了解作业访问令牌。 此更改不会影响任何现有管道。 它只会影响从这一点开始创建的新经典生成管道。

Azure Pipelines 支持圣迭戈、东京和犹他州的 ServiceNow 版本

Azure Pipelines 与 ServiceNow 的现有集成。 集成依赖于 ServiceNow 中的应用和 Azure DevOps 中的扩展。 我们现在更新了该应用,以便与圣迭戈、东京和犹他州的 ServiceNow 版本配合使用。 若要确保此集成有效,请从 ServiceNow 存储升级到新版本的应用(4.215.2)。

有关详细信息,请参阅 与 ServiceNow 更改管理集成文档

使用代理 URL 进行 GitHub Enterprise 集成

Azure Pipelines 与本地 GitHub Enterprise Servers 集成,以运行持续集成和 PR 生成。 在某些情况下,GitHub Enterprise Server 位于防火墙后面,需要通过代理服务器路由流量。 为了支持此方案,Azure DevOps 中的 GitHub Enterprise Server 服务连接允许你配置代理 URL。 以前,并非所有来自 Azure DevOps 的流量都通过此代理 URL 进行路由。 通过此更新,我们确保路由来自 Azure Pipelines 的以量,以通过代理 URL:

  • 获取分支
  • 获取拉取请求信息
  • 报表生成状态

容器注册表服务连接现在可以使用 Azure 托管标识

创建用于Azure 容器注册表的 Docker 注册表服务连接时,可以使用系统分配的托管标识。 这样就可以使用与自承载 Azure Pipelines 代理关联的托管标识访问Azure 容器注册表,而无需管理凭据。

新的 Docker 注册表服务连接,用于更改审批

注意

用于访问Azure 容器注册表的托管标识需要适当的 Azure 基于角色的访问控制(RBAC)分配,例如 AcrPull 或 AcrPush 角色。

为 Kubernetes 服务连接创建的自动令牌

由于 Kubernetes 1.24,在创建新的 Kubernetes 服务连接时,不再自动创建令牌。 我们添加了此功能。 但是,建议在访问 AKS 时使用 Azure 服务连接,以了解有关 使用 Kubernetes 任务博客文章的 AKS 客户的服务连接指南的详细信息。

Kubernetes 任务现在支持 kubelogin

我们更新了支持 kubelogin 的KuberentesManifest@1、HelmDeploy@0Kubernetes@1AzureFunctionOnKubernetes@1任务。 通过此操作,能够以配置了 Azure Active Directory 集成的 Azure Kubernetes 服务 (AKS) 为目标。

未在托管映像预安装 Kubelogin。 若要确保上述任务使用 kubelogin,请在依赖于它的任务之前插入 KubeloginInstaller@0 任务来安装它:

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

管道权限改进体验

我们改进了有关管理管道权限的体验,使权限系统记住管道以前是否使用了受保护的资源(例如服务连接)。

过去,如果在创建受保护资源时选中了“向所有管道授予访问权限”,但随后限制了对资源的访问,则管道需要新的授权才能使用该资源。 此行为与后续打开和关闭对资源的访问不一致,其中不需要新的授权。 此问题现在已修复。

用于管理管道授权和审批和检查的新 PAT 范围

为了限制通过泄露 PAT 令牌造成的损害,我们添加了名为 的新 PAT 范围 Pipeline Resources。 在使用 受保护的资源(例如服务连接)管理管道授权时,可以使用此 PAT 范围,或者管理 审批和检查 该资源。

显示管道 REST API 更新的屏幕截图。

以下 REST API 调用支持新的 PAT 范围,如下所示:

将受保护的资源限制为资源管理员

为了提高对安全生成和部署应用程序至关重要的资源的安全性,Azure Pipelines 现在需要在向所有管道开放对资源的访问权限时需要资源类型管理员角色。

例如,需要常规服务连接管理员角色才能允许 任何 管道使用服务连接。 创建受保护的资源或编辑其安全配置时,此限制适用。

此外,在创建服务连接且没有足够的权限时, 将禁用对所有管道 选项授予访问权限。

服务连接 此外,当尝试打开对现有资源的访问并且没有足够的权限时,你将获得 你无权打开此资源 消息的访问权限。

管道权限

管道 REST API 安全性改进

Azure DevOps 中的大多数 REST API 都使用限定范围的 PAT 令牌。 但是,其中一些需要完全范围的 PAT 令牌。 换句话说,必须通过选择“完全访问权限”来创建 PAT 令牌,才能使用这些 API 中的一些。 此类令牌会带来安全风险,因为它们可用于调用任何 REST API。 我们在 Azure DevOps 中进行了改进,通过将每个 REST API 合并到特定范围来消除对完全限定范围的令牌的需求。 作为这项工作的一部分,用于更新资源的管道权限的 REST API 现在需要特定的范围。 范围取决于要授权使用的资源类型:

  • Code (read, write, and manage) 用于类型的资源 repository
  • Agent Pools (read, manage)Environment (read, manage) 类型 queue 为和 agentpool
  • Secure Files (read, create, and manage) 用于类型的资源 securefile
  • Variable Groups (read, create and manage) 用于类型的资源 variablegroup
  • Service Endpoints (read, query and manage) 用于类型的资源 endpoint
  • Environment (read, manage) 用于类型的资源 environment

若要批量编辑管道权限,仍需要一个完全范围的 PAT 令牌。 若要详细了解如何更新资源的管道权限,请参阅“ 管道权限 - 更新资源管道权限” 文档。

代理池的精细访问管理

使用代理池可以指定和管理管道运行的计算机。

以前,如果使用了自定义代理池,则管理哪些管道可以访问该池是粗粒度的。 可以允许所有管道使用它,也可以要求每个管道请求权限。 遗憾的是,向代理池授予管道访问权限后,无法使用管道 UI 撤消该权限。

Azure Pipelines 现在为代理池提供精细的访问管理。 体验类似于管理服务连接的管道权限的体验。

FabrikamFiber 代理池,用于更改审批

阻止向所有管道授予对受保护资源的访问权限

创建受保护的资源(如服务连接或环境)时,可以选择“ 对所有管道 授予访问权限”复选框。 到目前为止,此选项默认已选中。

虽然这使得管道能够更轻松地使用新的受保护资源,但相反,它倾向于意外地向过多管道授予访问资源的权限。

若要提升默认选择,Azure DevOps 现在将保留未选中的复选框。

默认情况下,对所有管道授予访问权限处于关闭状态

能够禁用短机密的掩码

Azure Pipelines 会屏蔽日志中的机密。 机密可以是标记为机密的变量、链接到 Azure 密钥保管库的变量组中的变量,也可以是服务连接提供程序标记为机密的服务连接的元素。

机密值的所有匹配项都会被屏蔽。 屏蔽短机密(例如“”、“12”、“”Dev)可以轻松猜测其值,例如在日期中:“”Jan 3, 202***
现在很明显,“”3是一个秘密。 在这种情况下,你可能不希望完全屏蔽机密。 如果无法将值标记为机密 (例如该值取自密钥保管库) ,则可以将AZP_IGNORE_SECRETS_SHORTER_THAN旋钮设置为最多 4 的值。

节点运行器下载任务

采用 排除节点 6 任务运行器的代理版本 时,可能偶尔需要运行尚未更新的任务,以使用较新的 Node 运行器。 对于此方案,我们提供了一种仍使用依赖于节点生命周期终止运行器的任务的方法,请参阅 Node 运行器指南 博客文章

以下任务是一种实时安装 Node 6 运行器的方法,因此旧任务仍可执行:

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 6

更新了 TFX 节点运行器验证

任务作者使用 扩展打包工具 (TFX) 发布扩展。 TFX 已更新为对节点运行器版本执行验证,请参阅 Node 运行器指南 博客文章

包含使用节点 6 运行器的任务的扩展将看到以下警告:

Task <TaskName> is dependent on a task runner that is end-of-life and will be removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance.

有关在管道代理上手动预安装 Node 6 的说明

如果使用 pipeline- 代理源,则代理中不包含 Node 6。 在某些情况下,如果市场任务仍然依赖于 Node 6,并且代理无法使用 NodeTaskRunnerInstaller 任务(例如由于连接限制),则需要单独预安装 Node 6。 若要完成此操作,查看有关如何手动安装 Node 6 运行器的说明

管道任务更改日志

现在,我们将对管道任务的更改发布到此更改日志。 它包含对内置管道任务所做的更改的完整列表。 我们已追溯发布以前的更改,因此更改日志提供了任务更新的历史记录。

发布任务使用Microsoft图形 API

我们已更新发布 任务 以使用 Microsoft 图形 API。 这会从任务中删除 AAD 图形 API 的使用

Windows PowerShell 任务性能改进

可以使用任务在管道中定义自动化。 其中一项任务是 PowerShell@2 实用工具任务,可用于在管道中执行 PowerShell 脚本。 若要使用 PowerShell 脚本以 Azure 环境为目标,可以使用该 AzurePowerShell@5 任务。 某些可以打印进度更新的 PowerShell 命令,例如 Invoke-WebRequest,现在执行速度更快。 如果脚本中有许多这些命令,或者长时间运行,则改进更为重要。 通过此更新,progressPreference任务的属性PowerShell@2AzurePowerShell@5现在默认设置为SilentlyContinue

.NET 6 上的 Pipelines Agent v3

管道代理已升级为使用 .NET 3.1 Core 到 .NET 6 作为运行时。 这引入了对 Apple Silicon 和 Windows Arm64 的本机支持。

使用 .NET 6 会影响代理的系统要求。 具体而言,我们放弃了对以下操作系统的支持:CentOS 6、Fedora 29-33、Linux Mint 17-18、Red Hat Enterprise Linux 6。 请参阅代理软件版本 3 的文档

脚本 可用于标识使用具有不受支持的操作系统的代理的管道。

重要

请注意,在上述任一操作系统上运行的代理将不再更新或失败,一旦推出基于 .NET 6 的代理。

在代理 VM 扩展中指定代理版本

可以使用 VM 扩展将 Azure VM 包含在部署组中。 VM 扩展已更新为根据需要指定要安装的代理版本:

    "properties": {
      ...
      "settings": {
        ...
        "AgentMajorVersion": "auto|2|3",
        ...
      },
      ...
     }

用于控制经典管道创建的新切换

Azure DevOps 现在允许你通过禁用经典生成管道、经典发布管道、任务组和部署组来确保项目集合仅使用 YAML 管道。 现有经典管道将继续运行,并且能够编辑它们,但无法创建新管道。

Azure DevOps 现在允许你通过禁用经典生成管道、经典发布管道、任务组和部署组来确保组织仅使用 YAML 管道。 现有经典管道将继续运行,并且能够编辑它们,但无法创建新管道。

可以通过打开相应的切换,在项目集合级别或项目级别禁用经典管道的创建。 可在项目/项目设置 -> 管道 - 设置中找到>切换。 有两个切换:一个用于经典 生成 管道,一个用于经典 发布 管道、部署组和任务组。

禁止创建经典管道

切换状态默认处于关闭状态,需要管理员权限才能更改状态。 如果切换在组织级别处于打开状态,则会对所有项目强制禁用。 否则,每个项目都可以自由选择是否强制禁用。

强制禁用经典管道的创建时,与创建经典管道、任务组和部署组相关的 REST API 将失败。 创建 YAML 管道的 REST API 将正常工作。

更新“运行阶段状态已更改”服务挂钩事件

使用服务挂钩可以在 Azure DevOps 中的项目中发生事件时在其他服务上运行任务, 运行阶段状态已更改 是其中一个事件。 运行阶段状态更改事件必须包含有关运行的信息,包括管道的名称。 以前,它只包含有关运行 ID 和名称的信息。 通过此更新,我们对事件进行了更改,以包含缺少的信息。

禁用显示管道运行的最后一个提交消息

以前,显示管道的运行时用于显示最后一个提交消息的管道 UI。

上一个提交消息示例

例如,当 YAML 管道的代码位于存储库中时,此消息可能会令人困惑,这与保存其生成的代码不同。 我们听取了开发者社区反馈,要求我们启用/禁用将最新的提交消息追加到每个管道运行的标题。

通过此更新,我们添加了一个名为的新 YAML 属性 appendCommitMessageToRunName,使你能够完全做到这一点。 默认情况下,该属性设置为 true。 将其设置为false时,管道运行将仅显示 。BuildNumber

包含内部版本号的管道运行示例

最后一个提交消息的管道运行示例

增加了 Azure Pipeline 限制,使其与 4 MB 最大 Azure 资源管理器 (ARM) 模板大小保持一致。

可以使用 Azure 资源管理器模板部署任务来创建 Azure 基础结构。 为了响应你的反馈,我们已将 Azure Pipelines 集成限制提高了 2 MB 到 4 MB。 这与 ARM 模板在集成大型模板 期间的最大大小为 4 MB 的解析大小约束保持一致。

管道运行状态概述图标

通过此版本,我们可以更轻松地了解管道运行的总体状态。

对于具有多个阶段的 YAML 管道,过去很难知道管道运行的状态,即管道运行仍在运行还是已完成。 如果完成,则总体状态是什么:成功、失败或已取消。 我们通过添加运行状态概述图标修复了此问题。

管道运行状态概述图标

管道阶段侧面板

YAML 管道可以具有数十个阶段,并非所有阶段都适合你的屏幕。 虽然管道运行概述图标告知运行的总体状态,但仍很难知道哪个阶段失败,或者哪个阶段仍在运行,例如。

在此版本中,我们添加了一个管道阶段侧面板,可让你快速查看所有阶段的状态。 然后,可以单击某个阶段并直接访问其日志。

更新管道

管道 UI 更新

在侧面板中搜索阶段

我们简化了在阶段侧面板中查找的阶段。 现在可以根据阶段的状态(例如正在运行的阶段或需要手动干预的阶段)快速筛选阶段。 还可以按阶段名称搜索阶段。

更新 AZ Pipelines

暂存快速操作

管道的 “运行” 屏幕可让你快速访问所有运行阶段。 在此版本中,我们添加了一个阶段面板,你可以在其中为每个阶段执行操作。 例如,可以轻松重新运行失败的作业或重新运行整个阶段。 当并非所有阶段都适合用户界面时,面板可用,如以下屏幕截图所示。

管道的屏幕截图,其中包含过多阶段。 单击阶段列中的“+”登录时,将显示阶段面板,然后可以执行阶段操作。

阶段面板的屏幕截图。

检查用户体验改进

我们正在简化读取检查日志。 检查日志提供有关部署成功的关键信息。 他们可以告诉你你是否忘记关闭工作项票证,或者你需要在 ServiceNow 中更新票证。 以前,知道检查提供了此类关键信息是很难的。

现在,管道运行详细信息页显示最新的检查日志。 这 仅适用于 遵循建议 用法的检查。

显示最新检查日志的图像。为了防止错误批准的审批,Azure DevOps 在管道运行的详细信息页中向审批者显示审批者的说明,并检查侧面板。

正在等待管道评审图像。

禁用检查

我们做了不太繁琐的调试检查。 有时,调用 Azure 函数或调用 REST API 检查无法正常工作,需要修复它。 以前,必须删除此类检查,以防止它们错误地阻止部署。 修复检查后,必须重新添加并正确配置它,确保设置所有必需的标头或查询参数正确。 这是繁琐的。

现在,只需禁用检查即可。 禁用的检查不会在后续检查套件评估中运行。

禁用检查图像。 修复错误检查后,只需启用它即可。

启用检查映像。

管道运行 Rest API 中的已用资源和模板参数

扩展 管道运行 REST API 现在返回管道运行使用的更多类型项目,以及用于触发该运行的参数。 我们增强了 API 以返回containerpipeline管道运行中使用的资源和模板参数。 例如,现在可以编写符合性检查来评估管道使用的存储库、容器和其他管道运行。

下面是新响应正文的示例。

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

YAML 编辑器中的正式发布模板支持

模板是 YAML 管道中常用的功能。 它们是共享管道代码片段的一种简单方法。 它们也是通过管道验证或强制实施 安全和治理 的强大机制。

Azure Pipelines 支持 YAML 编辑器,在编辑管道时非常有用。 但是编辑器直到现在才支持模板。 使用模板时,YAML 管道的作者无法通过 Intellisense 获得帮助。 模板作者无法使用 YAML 编辑器。 在此版本中,我们将在 YAML 编辑器中添加对模板的支持。

在编辑 Azure Pipelines YAML 主文件时,可以包含或扩展模板。 键入模板名称时,系统会提示验证模板。 验证后,YAML 编辑器会了解模板的架构,包括输入参数。

管道 REST API 汇报

验证后,可以选择导航到模板。 你将能够使用 YAML 编辑器的所有功能对模板进行更改。

存在已知限制:

  • 如果模板具有未作为主 YAML 文件中的输入提供的必要参数,则验证将失败并提示你提供这些输入。 在理想的体验中,不应阻止验证,并且应该能够使用 Intellisense 填写输入参数。
  • 不能从编辑器创建新模板。 只能使用或编辑现有模板。

新的预定义系统变量

我们引入了一个新的预定义系统变量,名为 Build.DefinitionFolderPath,其值是生成管道定义的文件夹路径。 变量在 YAML 和经典生成管道中均可用。

例如,如果管道位于 Azure Pipelines 中的文件夹下FabrikamFiber\Chat,则值为 Build.DefinitionFolderPath <a0/a0>。

在 YAML 模板表达式中添加对字符串拆分函数的支持

YAML 管道提供了减少代码重复的便捷方法,例如 循环访问 each 对象列表 或属性的值。

有时,要循环访问的项集表示为字符串。 例如,当要部署到的环境列表由字符串 integration1, integration2定义时。

当我们听取了来自开发者社区反馈时,我们听到你希望在 YAML 模板表达式中使用字符串split函数。

现在,可以 split 一个字符串并循环访问 each 其子字符串。

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

存储库资源定义中的模板表达式

我们在 YAML 管道中定义 ref 资源的属性 repository 时添加了对模板表达式的支持。 这是我们开发者社区要求很高的功能。

如果希望管道签出同一存储库资源的不同分支,则存在用例。

例如,假设你有一个生成自己的存储库的管道,因此需要从资源存储库中签出库。 此外,假设希望管道签出与自身使用的同一库分支。 例如,如果管道在 main 分支上运行,则应签出 main 库存储库的分支。 如果管道在 dev 分支上运行,则应签出 dev 库分支。

直到今天为止,必须显式指定分支进行签出,并在分支发生更改时更改管道代码。

现在,可以使用模板表达式选择存储库资源的分支。 请参阅用于管道的非主分支的 YAML 代码的以下示例:

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

运行管道时,可以指定要签出存储库的 library 分支。

指定要在生成队列时扩展的模板版本

模板是减少代码重复提高管道安全性的好方法。

一个常用的用例是将模板存放在其自己的存储库中。 这样可减少模板与扩展模板的管道之间的耦合,并使模板和管道能够更轻松地独立发展模板和管道。

请考虑以下示例,其中模板用于监视步骤列表的执行。 模板代码位于存储库中 Templates

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

假设你有一个 YAML 管道,用于扩展此模板,位于存储库 FabrikamFiber中。 直到今天为止,在将存储库用作模板源时,无法动态指定 ref 存储库资源的属性 templates 。 这意味着,如果希望管道能够:从其他分支扩展模板,则无论在哪个分支上运行管道的分支,都需更改管道的代码: 从不同的分支扩展模板。

在存储库资源定义中引入模板表达式后,可以编写管道,如下所示:

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

这样做后,管道会将模板扩展到运行管道的分支所在的同一分支中,因此可以确保管道的分支和模板的分支始终匹配。 也就是说,如果在分支dev上运行管道,它将扩展存储库分支中的devtemplates文件指定的template.yml模板。

或者,可以通过编写以下 YAML 代码,在生成队列时选择要使用的模板存储库分支。

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: ./build.sh
      - script: ./test.sh

现在,可以在分支 main 上让管道从一次运行中的分支 dev 扩展模板,并从另一个运行中的分支 main 扩展模板,而无需更改管道的代码。

ref 存储库资源的属性指定模板表达式时,可以使用 parameters 和系统预定义变量,但不能使用 YAML 或 Pipelines UI 定义的变量。

容器资源定义中的模板表达式

我们在 YAML 管道中定义endpointoptionsvolumesportscontainer资源的属性时添加了对模板表达式的支持。 这是我们开发者社区要求很高的功能。

现在,可以编写 YAML 管道,如下所示。

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

可以使用 parameters. 模板表达式和 variables. 模板表达式。 对于变量,只能使用 YAML 文件中定义的变量,但不能使用管道 UI 中定义的变量。 例如,如果重新定义变量,则使用代理日志命令不会有任何影响。

计划的生成改进

我们修复了导致管道的计划信息损坏且管道无法加载的问题。 例如,当分支的名称超过一定数量的字符时,就会导致此问题。

改进了未能加载管道时的错误消息

Azure Pipelines 提供了多种类型的触发器来配置管道的启动方式。 运行管道的一种方法是使用计划的触发器。 有时,管道的计划运行信息会损坏,并可能导致加载失败。 以前,我们显示误导性错误消息,声称找不到管道。 通过此更新,我们解决了此问题,并返回了一条信息性错误消息。 今后,你将收到类似于: 如果管道无法加载,生成计划数据将 损坏。

提取 Git 存储库时不要同步标记

签出任务使用--tags选项提取 Git 存储库的内容。 这会导致服务器提取所有标记以及这些标记所指向的所有对象。 这会增加在管道中运行任务的时间-特别是如果你有一个包含大量标记的大型存储库。 此外,即使启用浅提取选项,签出任务也会同步标记,从而可能破坏其目的。 为了减少从 Git 存储库提取或拉取的数据量,我们现在向任务添加了一个新选项来控制同步标记的行为。 此选项在经典管道和 YAML 管道中都可用。

可以通过 YAML 文件或 UI 控制此行为。

若要选择退出通过 YAML 文件同步标记,请添加到 fetchTags: false 签出步骤。 如果未指定该 fetchTags 选项,则它与 fetchTags: true 使用选项相同。

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

如果要更改现有 YAML 管道的行为,在 UI 中设置此选项可能更方便,而不是更新 YAML 文件。 若要导航到 UI,请打开管道的 YAML 编辑器,选择“触发器”,然后选择“处理”,然后选择“签出”步骤。

如果在 YAML 文件和 UI 中同时指定此设置,则 YAML 文件中指定的值优先。

对于创建的所有新管道(YAML 或经典),标记默认仍同步。 此选项不会更改现有管道的行为。 除非显式更改了上述选项,否则这些管道中的标记仍将同步。

Artifacts

更新了默认源权限

创建新的项目集合范围的 Azure Artifacts 源(而不是当前参与者角色)时,项目集合生成服务帐户现在将具有协作者角色。

以前,如果有源的副本,则可以看到上游包。 难题在于,无法搜索上游可用的包,并且尚未保存在源中。 现在,可以使用新的源用户界面搜索可用的上游包。

Azure Artifacts 现在提供一个用户界面,可用于搜索上游源中的包,并将包版本保存到源中。 这符合Microsoft改进产品和服务的目标。

正在报告

在查询结果小组件中显示父级

查询结果小组件现在支持父级的名称和指向该父级的直接链接。

创建要部署到市场的个人访问令牌

复制仪表板

在此版本中,我们将包括 复制仪表板

包含复制仪表板的图像

仪表板上次访问日期和修改者

允许团队创建多个仪表板的挑战之一是管理和清理过时和未使用的仪表板。 了解仪表板上次访问或修改时间是了解哪些仪表板可以删除的重要部分。 在此版本中,我们已将两个新列包含在仪表板目录页中。 上次访问日期 将跟踪最近访问仪表板的时间。 Modified By 跟踪上次编辑仪表板的时间以及由谁编辑。

修改者” 信息也会显示在仪表板页本身上。

仪表板预览

我们希望这些新字段可帮助项目管理员了解仪表板的活动级别,以便在是否删除仪表板时做出有根据的决策。

分析视图现已推出

分析 视图 功能在产品的托管版本中处于长时间的预览状态。 通过此版本,我们很高兴地宣布此功能现已可供所有项目集合使用。

在导航中, 分析视图 从“ 概述 ”选项卡移动到“ ”选项卡。

板导航中的分析视图。

分析视图提供了一种简化的方法,用于根据分析数据为 Power BI 报表指定筛选条件。 如果不熟悉 分析视图,可参阅以下一些文档:

多个存储库的拉取请求小组件现已可用

我们很高兴地宣布,Azure DevOps Server 2022.1 中提供了多个存储库的拉取请求小组件。 借助此新小组件,你可以在一个简化的列表中轻松查看最多 10 个不同存储库的拉取请求,从而比以往更轻松地随时了解拉取请求。

多存储库小组件正式发布

社区建议票证

在烧毁和烧毁图表中已解析为已完成的简介

我们了解准确反映团队进度的重要性,包括图表中已完成的已解决项目。 使用简单的切换选项,现在可以选择将已解析的项目显示为已完成,从而真实反映团队的进度状态。 此增强功能允许更准确的跟踪和规划,使团队能够根据实际进度做出明智的决策。 通过报表中更新的燃烧和燃烧图表,体验改进的透明度和更好的见解。

在烧毁和向上燃烧图表中完成的 Gif 演示。

Wiki

支持 Wiki 页面中的其他图表类型

我们已将 Wiki 页面中使用的美人鱼图表版本升级到 8.13.9。 通过此升级,现在可以在 Azure DevOps Wiki 页面中包括以下关系图和可视化效果:

  • 流程图
  • 序列图
  • 甘特图
  • 饼图
  • 要求图
  • 状态图
  • 用户旅程

不包括处于试验模式(如实体关系和 Git Graph)的关系图。 有关新功能的详细信息,请参阅 美人鱼发行说明


反馈

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


返回页首