Azure DevOps Server 2022 Update 1 发行说明

项目
03/12/2024

在本文中，你将找到有关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 补丁 3 发布日期：2024 年 3 月 12 日

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

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

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

Azure DevOps Server 2022 Update 1 补丁 2 发布日期：2024 年 2 月 13 日

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

我们发布了适用于 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 日

注意

此版本有两个已知问题：

升级到 Azure DevOps Server 2022.1 并在代理池配置中使用更新代理后，代理版本不会更新。我们目前正在研究一个修补程序来解决此问题，并会在开发者社区中共享更新，因为我们会取得进展。在此期间，可以在此开发者社区票证中找到此问题的解决方法。
Maven 3.9.x 兼容性。 Maven 3.9.x 通过从 Wagon 更新到本机 HTTP 的默认 Maven 解析程序传输，引入了 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 通过从 Wagon 更新到本机 HTTP 的默认 Maven 解析程序传输，引入了 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 中的所有功能。

注意

此版本修复了以下问题：

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

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

Azure DevOps Server 2022.1 RC1 包括许多新功能。其中一些要点包括：

所有公共 REST API 都支持精细 PAT 范围
“交付计划”页上的“上次访问时间”列
可视化交付计划上的所有依赖项
交付计划中@CurrentIteration宏
当前项目设置为经典管道中生成访问令牌的默认范围
在查询结果小组件中显示父级
复制仪表板
支持 Wiki 页面中的其他图表类型
容器注册表服务连接现在可以使用 Azure 托管标识

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

常规
Boards
Repos
管道
项目
报告
Wiki

常规

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

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

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

扩展应显示其范围

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

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

Boards

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

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

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

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

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

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

新的工作项修订限制

在过去几年中，我们看到使用自动化工具的项目集合生成了数万个工作项修订。这会在工作项表单和报告 REST API 上产生性能和可用性问题。为了缓解此问题，我们对 Azure DevOps Service 实现了工作项修订限制，限制为 10,000。此限制仅影响使用 REST API 的更新，而不会影响工作项窗体。

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

将交付计划团队限制从 15 提高到 20

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

修复了报告工作项链接获取 API 中的 bug

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

创建临时查询 REST 终结点

我们已看到多个扩展作者尝试通过 querystring 传递工作项查询语言 (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 集合。通过此更新，我们将在创建新的经典管道时将作业授权范围设置为 当前项目 作为默认值。

有关作业访问令牌的更多详细信息，请参阅访问存储库、项目和其他资源文档。

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

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

Azure Pipelines 对圣地亚哥、东京 & 犹他州的 ServiceNow 版本的支持

Azure Pipelines 已与 ServiceNow 集成。集成依赖于 ServiceNow 中的应用和 Azure DevOps 中的扩展。现在，我们已更新应用，以使用圣地亚哥、东京 & 犹他州的 ServiceNow 版本。若要确保此集成正常工作，请从 ServiceNow 存储升级到应用的新版本 (4.215.2) 。

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

使用代理 URL 进行 GitHub Enterprise 集成

Azure Pipelines 与本地 GitHub Enterprise Server 集成，以运行持续集成和 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 服务连接，若要了解详细信息，请参阅适用于 AKS 客户的使用 Kubernetes 任务的服务连接指南博客文章。

Kubernetes 任务现在支持 kubelogin

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

未在托管映像上预安装 Kubelogin。若要确保上述任务使用 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 范围，如下所示：

更新审批支持范围 Pipeline Resources Use
管理检查支持范围 Pipeline Resources Use and Manage
更新资源的管道权限支持范围 Pipeline Resources Use and Manage
授权定义资源支持范围 Pipeline Resources Use and Manage
授权项目资源支持范围 Pipeline Resources Use and Manage

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

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

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

此外，创建服务连接时，如果没有足够的权限，则会禁用 “授予对所有管道的访问权限 ”选项。

服务Connections 此外，当尝试打开对现有资源的访问，而你没有足够的权限时，你将收到“你无权打开此资源的访问权限”消息。

管道权限

管道 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 现在为代理池提供精细的访问管理。该体验类似于管理服务Connections的管道权限的体验。

用于审批更改的 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 运行器版本执行验证，请参阅 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- 代理源，则代理中不包含节点 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，和 AzurePowerShell@5 任务的属性PowerShell@2现在默认设置为 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 扩展中指定代理版本

Azure VM 可以使用 VM 扩展包含在部署组中。 VM 扩展已更新，可以选择性地指定要安装的所需代理版本：

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

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

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

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

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

禁止创建经典管道

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

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

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

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

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

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

上一个提交消息的示例

例如，当 YAML 管道的代码位于存储库中时，此消息可能会让人感到困惑，而存储库中保存的是它所生成代码的存储库。我们从开发者社区收到了你的反馈，要求我们启用/禁用将最新提交消息追加到每个管道运行的标题。

在此更新中，我们添加了一个名为 appendCommitMessageToRunName的新 YAML 属性，可用于执行此操作。默认情况下，属性设置为 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 检查无法正常工作，需要修复它。以前，必须删除此类检查，以防止它们错误地阻止部署。修复检查后，必须重新添加并正确配置它，确保设置了所有必需的标头或查询参数正确。这很繁琐。

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

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

启用检查映像。

Pipelines Runs Rest API 中消耗的资源和模板参数

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

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

"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 管道的作者在使用模板时无法通过智能感知获得帮助。模板作者无法使用 YAML 编辑器。在此版本中，我们将在 YAML 编辑器中添加对模板的支持。

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

管道 REST API 汇报

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

存在已知限制：

如果模板的必需参数未作为main YAML 文件中的输入提供，则验证会失败，并提示你提供这些输入。在理想情况下，不应阻止验证，并且应该能够使用 intellisense 填充输入参数。
不能从编辑器创建新模板。只能使用或编辑现有模板。

新的预定义系统变量

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

例如，如果管道位于 Azure Pipelines 中的文件夹下FabrikamFiber\Chat，则的Build.DefinitionFolderPathFabrikamFiber\Chat值为。

在 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分支。

直到今天，必须显式指定分支以检查，并在分支更改时更改管道代码。

现在，可以使用模板表达式来选择存储库资源的分支。请参阅以下用于管道非main分支的 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上运行管道，它将扩展存储库分支templates中dev文件指定的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 管道中定义endpoint资源的、、 volumesports和 options 属性container时添加了对模板表达式的支持。这是我们开发者社区高度要求的功能。

现在，可以编写 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 文件中定义的变量，而不能使用 Pipelines UI 中定义的变量。如果重新定义变量（例如，使用代理日志命令），则它不会有任何影响。

计划的生成改进

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

改进了加载管道失败时的错误消息

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

获取 Git 存储库时不同步标记

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

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 项目源时，项目集合生成服务帐户现在将默认具有 协作者 角色，而不是当前的 参与者 角色。

用于上游包搜索的新用户界面

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

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 的建议。

返回页首

Azure DevOps Server 2022 Update 1 发行说明

Azure DevOps Server 2022 Update 1 补丁 3 发布日期：2024 年 3 月 12 日

Azure DevOps Server 2022 Update 1 补丁 2 发布日期：2024 年 2 月 13 日

Azure DevOps Server 2022 Update 1 补丁 1 发布日期：2023 年 12 月 12 日

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

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

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

常规

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

扩展应显示其范围

Boards

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

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

新的工作项修订限制

将交付计划团队限制从 15 提高到 20

修复了报告工作项链接获取 API 中的 bug

创建临时查询 REST 终结点

批量删除 API

@CurrentIteration 交付计划中的宏

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

批处理更新改进

批量删除 API

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

新的保存注释权限

交互式板报表

Repos

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

管道

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

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

Azure Pipelines 对圣地亚哥、东京 & 犹他州的 ServiceNow 版本的支持

使用代理 URL 进行 GitHub Enterprise 集成

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

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

Kubernetes 任务现在支持 kubelogin

管道权限的体验改进

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

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

管道 REST API 安全性改进

代理池的精细访问管理

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

能够禁用短机密的掩码

节点运行器下载任务

更新了 TFX 节点运行器验证

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

管道任务更改日志

发布任务使用 Microsoft 图形 API

Windows PowerShell任务性能改进

.NET 6 上的 Pipelines Agent v3

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

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

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

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

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

管道运行状态概述图标

管道阶段侧面板

在侧面板中搜索阶段

阶段快速操作

检查用户体验改进

禁用检查

Pipelines Runs Rest API 中消耗的资源和模板参数

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

新的预定义系统变量

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

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

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

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

计划的生成改进

改进了加载管道失败时的错误消息

获取 Git 存储库时不同步标记

Artifacts

更新了默认源权限

用于上游包搜索的新用户界面

报表

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

复制仪表板

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

分析视图现已可用

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

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