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 2010 或更低版本上进行 TFS 部署,需要先执行一些中间步骤,再升级到 Azure DevOps Server 2019。 若要了解详细信息,请参阅 在本地安装和配置 Azure DevOps


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

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

Azure DevOps Server 2020 根据管道级保留策略以不同的方式处理生成保留。 某些策略配置会导致流水线运行在升级后被删除。 升级后,手动保留或通过发布保留的管道运行将不会被删除。

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

Azure DevOps Server 2020 Update 1.2 Patch 15 发布日期:2025 年 3 月 11 日

文件 SHA-256 哈希
devops2020.1.2patch15.exe 66B6FDE4949C0B7A87B20F3BC8E0673774401929D8B75E37F599DFF8BA74ABE5

我们已针对 Azure DevOps Server 2020 Update 1.2 发布了 Patch 15,包括以下内容:

Azure DevOps Server 2020 Update 1.2 修补程序 14 发布日期:2024 年 11 月 12 日

文件 SHA-256 哈希
devops2020.1.2patch14.exe 89AF4B1FCA1E2BD813A42F0D3E568E64AB470E5FD0A2F87F9E4894B8CA361420

我们发布了 Azure DevOps Server 2020 Update 1.2 的修补程序 14 ,以包括升级到易受攻击的依赖项。

Azure DevOps Server 2020 Update 1.2 修补程序 13 发布日期:2024 年 3 月 12 日

文件 SHA-256 哈希
devops2020.1.2patch13.exe 55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

我们发布了 Azure DevOps Server 2020 更新 1.2 的补丁 13,其中包括以下修复:

  • 解决了安装 Patch 12 后代理服务器停止工作的问题。

Azure DevOps Server 2020 Update 1.2 修补程序 12 发布日期:2024 年 2 月 13 日

文件 SHA-256 哈希
devops2020.1.2patch12.exe C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

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

  • 修复了一个 bug,该问题导致代理缓存文件夹的磁盘空间计算不正确,并且文件夹未被正确清理。
  • CVE-2024-20667:Azure DevOps Server 远程代码执行漏洞。

Azure DevOps Server 2020 Update 1.2 修补程序 11 发布日期:2023 年 12 月 12 日

文件 SHA-256 哈希
devops2020.1.2patch11.exe C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

我们发布了 Azure DevOps Server 2020 Update 1.2 的补丁 11,其中包括以下修复:

  • 修复了预部署审批安全继承在流水线阶段不起作用的 bug。

Azure DevOps Server 2020 Update 1.2 修补程序 10 发布日期:2023 年 11 月 14 日

我们发布了适用于 Azure DevOps Server 2020 Update 1.2 的补丁,其中包含以下问题的修复。

  • 扩展了 PowerShell 任务中允许的字符列表,以启用 shell 任务参数验证。

注意

若要实施此补丁程序,您必须执行多个步骤来手动更新任务。

安装补丁

重要

我们发布了 Azure Pipelines 代理的更新,修补程序 8 于 2023 年 9 月 12 日发布。 如果您未按补丁 8 的发行说明中所述安装代理更新,我们建议您在安装补丁 10 之前先安装这些更新。 安装 Patch 8 后的新版本为 3.225.0。

配置 TFX

  1. 遵循将任务上传到项目集合文档中的步骤进行安装,然后使用 tfx-cli 登录。

使用 TFX 更新任务

文件 SHA-256 哈希
Tasks20231103.zip 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5
  1. 下载并提取 Tasks20231103.zip
  2. 切换到解压缩后的文件所在的目录。
  3. 执行以下命令以上传任务:
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

管道要求

若要使用新行为,必须在使用受影响任务的管道中设置变量 AZP_75787_ENABLE_NEW_LOGIC = true

  • 关于经典:

    在管道中的变量选项卡上定义变量。

  • YAML 示例:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 1.2 Patch 9 发布日期:2023 年 10 月 10 日

重要

我们发布了 Azure Pipelines 代理的更新,修补程序 8 于 2023 年 9 月 12 日发布。 如果您未按照修补程序 8 的发行说明中所述安装代理更新,我们建议您在安装修补程序 9 之前先安装这些更新。 安装 Patch 8 后的新版本为 3.225.0。

我们发布了一个 补丁。 适用于 Azure DevOps Server 2020 Update 1.2,其中包括以下问题的修复。

  • 修复了“分析所有者”标识在进行补丁升级的机器上显示为非活动标识的错误。

Azure DevOps Server 2020 Update 1.2 Patch 8 发布日期:2023 年 9 月 12 日

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

  • CVE-2023-33136:Azure DevOps Server 远程代码执行漏洞。
  • CVE-2023-38155:Azure DevOps Server 和 Team Foundation Server 特权提升漏洞。

重要

请将修补程序部署到测试环境,并确保环境的管道按预期工作,然后将修复应用于生产环境。

注意

要应用此补丁程序的修复,您需要按照几个步骤手动更新代理和任务。

安装补丁

  1. 下载并安装 Azure DevOps Server 2020 Update 1.2 修补程序 8

更新 Azure Pipelines 代理程序

  1. 从以下位置下载代理:https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
  2. 使用自托管 Windows 代理文档中所述的步骤部署代理。  

注意

必须将 AZP_AGENT_DOWNGRADE_DISABLED 设置为“true”以防止代理降级。 在 Windows 上,可以在管理命令提示符下使用以下命令,然后重启。 setx AZP_AGENT_DOWNGRADE_DISABLED true /M

配置 TFX

  1. 遵循将任务上传到项目集合文档中的步骤进行安装,然后使用 tfx-cli 登录。

使用 TFX 更新任务

  1. 下载并解压 Tasks_20230825.zip
  2. 切换到解压缩后的文件所在的目录。
  3. 执行以下命令以上传任务:
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

管道要求

若要使用新行为,必须在使用受影响任务的管道中设置变量 AZP_75787_ENABLE_NEW_LOGIC = true

  • 关于经典:

    在管道中的变量选项卡上定义变量。

  • YAML 示例:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 1.2 Patch 7 发布日期:2023 年 8 月 8 日

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

  • CVE-2023-36869:Azure DevOps Server 欺骗漏洞。
  • 更新 SSH 服务以支持 SHA2-256 和 SHA2-512。 如果 SSH 配置文件硬编码为使用 RSA,则应更新为 SHA2 或删除条目。
  • 解决了 markdown 文件中相对链接无法正常工作的问题。
  • 修复了提交页面上注释导航的错误。
  • 修复了一个问题,即分析所有者身份显示为不活跃身份。
  • 修复了 CronScheduleJobExtension 上的无限循环 bug。

Azure DevOps Server 2020 Update 1.2 Patch 6 发布日期:2023 年 6 月 13 日

我们已发布一个 Azure DevOps Server 2020 Update 1.2 的补丁,其中包括以下修复。

  • CVE-2023-21565:Azure DevOps Server 欺骗漏洞。
  • CVE-2023-21569:Azure DevOps Server 欺骗漏洞。
  • 修复了从 2018 年或更早版本升级时干扰推送软件包的错误。
  • 修复了分离或附加集合失败并报告以下错误:“TF246018:数据库操作超出了超时限制并已取消。

Azure DevOps Server 2020 Update 1.2 Patch 5 发布日期:2023 年 2 月 14 日

为了修复以下问题,我们为 Azure DevOps Server 2020 Update 1.2 发布了一个修补程序

  • CVE-2023-21553:Azure DevOps Server 远程代码执行漏洞
  • 修复了通过 Web UI 解决货架辅助功能问题
  • 客户需要在更新 Azure DevOps Server 管理控制台中的 SMTP 相关设置后重启 tfsjobagent 服务和 Azure DevOps Server 应用程序池。

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

我们发布了针对 Azure DevOps Server 2020 Update 1.2 的 修补程序,该程序包含以下问题的修复。

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

Gif 以演示 IndetityPicker 中的特殊字符。

  • 测试数据未被删除,导致数据库增长。 在此次修补中,我们更新了构建保留,以防止创建新的孤立的测试数据。

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

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

  • 解决新添加的 AD 标识未显示在安全对话标识选取器中的问题。
  • 修复了 Webhook 设置中“由组成员请求的筛选器”问题。
  • 修复了当组织设置中将管道的作业授权范围配置为对于非发布管道限制在当前项目时,发生的封闭式签入生成错误。
  • 修复了在通过身份验证代理建立服务连接时从 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 是一个包含漏洞修复的累积更新包。 可以直接安装 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 工作项中的控件时,不会发送电子邮件通知。
  • 用户个人资料中的首选电子邮件地址未更新。 这导致邮件被发送到之前的电子邮件地址。
  • “项目摘要”页中未显示页眉。 标头显示几毫秒,然后它消失。
  • Active Directory 用户同步的改进。
  • 通过从 log4j 二进制文件中删除 jndilookup 类来解决 Elasticsearch 漏洞。

安装步骤

  1. 使用 Patch 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. 使用 Patch 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 的第三个补丁 包括以下修正。

  • 修复用于“包含字词”查询的工作项宏。 以前,查询返回包含换行符的值的错误结果。
  • 提高 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 的连接。 通过此修补程序,项目管理员可以在 Azure DevOps Server 与 GitHub.com 上的存储库之间创建连接。 可以在“项目设置”下的“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 测试计划

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

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

我们发布了 Azure DevOps Server 2020.1 的修补程序 ,修复了以下内容。

  • 修复构建定义用户界面错误。
  • 更改了浏览历史记录以显示文件而不是根存储库。

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 是一个包含错误修复的版本。 它包括以前发布的 Azure DevOps Server 2020.1 RC2 中的所有功能。 Azure DevOps Server 2020.1 RTW 是错误修复的集合。 可以直接安装 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 是一个错误修复更新汇总。 它包括以前发布的 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 引入了许多新功能。 其中一些重要内容包括:

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


状态转换限制规则

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

img

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

复制工作项并包含子元素

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

本页显示了 Azure Boards 中用于在复制的工作项中包含子工作项的新选项。

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

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

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

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

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

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

现在可以将系统工作项类型添加到所选积压工作项级别。 从历史上看,这些工作项类型仅在查询中可用。

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

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

积压

提升 Azure Boards GitHub 应用程序存储库限制

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

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

并非所有工作流都是相同的。 某些客户希望在拉取请求完成后关闭其相关工作项。 其他人希望将工作项设置为在关闭之前要验证的另一个状态。 我们应该同时允许这两者。

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

工作项状态

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

链接工作项

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

你一直能够编辑自定义字段的说明。 但是,对于优先级、严重性和活动等系统字段,说明不可编辑。 托管 XML 与继承模型之间的功能差距阻碍了一些客户迁移到继承模型。 现在可以编辑系统字段的说明。 编辑的值只会影响进程中的该字段以及该工作项类型。 这样,便可以灵活地在不同的工作项类型上为同一字段提供不同的说明。

编辑说明

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

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

自定义状态

任务板上的父字段

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

父域任务板

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

敏捷、Scrum 和 CMMI 中所有不同工作项类型都有多个隐藏的系统规则。 这些规则已经存在了十多年,并且通常没有引起任何投诉。 然而,有几个规则已经不再被欢迎。 特别是一条规则给新客户和现有客户带来了很大的痛苦,我们决定是时候删除它了。 此规则存在于敏捷过程中的 Bug 工作项类型上。

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

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

工作项页面上已删除的项目

工作项”页 是一个很好的位置,可用于快速查找已创建或分配给你的项,等等。 它提供多个个性化数据透视表和筛选器。 “分配给我”视图的最大抱怨之一是它显示的是“已删除的工作项”(即处于这种状态的工作项)。 我们同意! 已删除的项目是不再值的工作,因此已从积压工作中删除,因此,将此项包含在此视图中并不有用。

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

Repos

默认分支名称首选项

Azure Repos 现在提供 Git 的可自定义默认分支名称。 在存储库设置中,可以选择初始化存储库时要使用的任何法定分支名称。 Azure Repos 始终支持更改现有存储库的默认分支名称。

有关详细信息,请参阅“管理分支”和“更改默认分支

默认分支的组织级别设置

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

组织级别的分支设置

添加一个新的身份验证范围用于贡献 PR 评论。

此版本添加了一个新的 OAuth 范围,用于读取/写入拉取请求注释。 如果你有一个只需要与评论互动的机器人或自动化程序,可以为其提供一个仅限此功能范围的个人访问令牌(PAT)。 如果自动化有 bug 或令牌遭到入侵,则此过程会减少爆炸半径。

拉取请求体验改进

新的拉取请求体验已得到改进,如下所示:

  • 使可选检查更加可见

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


显示可选检查


  • 在菜单项上单击 Ctrl

PR 上的选项卡菜单不支持 Ctrl-click。 用户经常在查看拉取请求时打开新的浏览器选项卡。 此问题已修复。

  • [+] 批注的位置

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


显示批注的位置

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

用于选择更新和比较 PR 中的文件的下拉列表在预览体验中丢失了重要元素。 它未显示该更新的创建时间。 此问题已修复。


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

  • **改进的注释筛选器布局 **

筛选拉取请求摘要页上的评论内容时,下拉列表位于右侧,但文本左对齐。 此问题已修复。


改进了注释筛选器布局

  • 导航到父提交

在“提交”页下,可以将特定提交中所做的更改与其父提交进行比较。 但是,你可能想要查看父提交,并进一步深入了解该提交与其父级有何不同。 当你想要了解发布中的所有更改时,通常需要这样做。 我们向提交中添加了一张父母卡片,以帮助你实现这一目标。


导航到父提交

  • PR 文件选项卡中有更多空间用于具有长名称的文件夹和文件

由于文件树中缺少水平间距,具有长名称的文件夹和文件被切断。 我们通过将树的缩进调整为与根节点对齐,并在页面上隐藏省略号按钮(仅在悬停时显示),从而恢复了树中的一些额外空间。

新文件树的图像:


文件夹和文件的更多空间

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


名称显示

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

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

  • 在移动设备上搜索提交

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

  • 对于新的 PR 文件差异移动视图,改进了对空间的使用

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


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

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

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

  • 在创建新的 PR 时增强了分支操作体验

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


分支体验增强

管道

其他代理平台:ARM64

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

管道资源标签筛选功能支持

我们现在在 YAML 管道中添加了“标记”。 您可以使用标记来设置 CI 管道的运行或自动触发的时机。

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    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

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

例如,如果为您的 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。 现在,您可以向https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview发送 POST 请求以获取最终的 YAML 正文。 此新 API 采用与排队运行相同的参数,但不再需要“队列生成”权限。

下次运行此作业

你是否曾遇到过需要立刻部署的 bugfix,但不得不在 CI 和 PR 作业后面排队等待? 通过此版本,我们现在允许你提升排队作业的优先级。 对池具有“管理”权限(通常是池管理员)的用户将在作业详细信息页上看到新的“下一步”按钮。 单击该按钮将尽快使作业进入运行状态。 (当然,你仍然需要可用的并行度和合适的代理。

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

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

控制来自线上市场的自动化任务更新

编写 YAML 管道时,通常只指定包含任务的主要版本号。 这样,工作流程就可以自动采用最新的功能添加和程序错误修复。 有时,你可能需要回滚到任务的上一个点版本,通过此更新,我们添加了执行此操作的功能。 现在可以在 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 在代理和任务中的支持

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

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

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

新的导出功能将替换经典构建设计器中之前的“YAML 视图”功能。 此功能不完整,因为它只能检查 Web UI 上有关构建过程的信息,这有时会导致生成错误的 YAML。 新的导出功能会准确考虑管道的处理方式,并生成忠实于设计器管道的 YAML。

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

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

新的 Web 平台转换。

利用这种新体验,由于加载速度更快且添加了搜索筛选器,因此可以更轻松地在具有大量存储库的项目中导航。 还可以在“策略”选项卡下查看项目级别策略和跨存储库策略列表。

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

如果单击进入存储库,您可以查看在存储库级别设置的策略和权限。 在“策略”选项卡中,可以查看设置策略的每个分支的列表。 现在,单击该分支即可查看策略,且始终不离开存储库设置页。

选择分支以查看策略。

现在,当某个策略是从比你正在处理的更高范围继承而来时,我们会在每个具体策略旁边显示该策略的继承来源。 你还可以通过单击范围名称导航到设置了更高级别策略的页面。

显示策略的继承位置。

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

用于每个部分的搜索筛选器。

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

适用于 ServiceNowAzure Pipelines 应用可帮助你集成 Azure Pipelines 和 ServiceNow 更改管理。 通过此更新,我们进一步推动使 Azure Pipelines 了解由 ServiceNow 管理的更改管理过程,将其集成到 YAML 管道中。

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


ServiceNow 变更管理集成

您还可以在服务器作业中添加 UpdateServiceNowChangeRequest 任务,来使用部署状态、备注等信息更新变更请求。

文物

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

我们正在重新引入客户通过 Web 用户界面在本地部署和托管服务中创建和管理集合范围订阅源的功能。

现在,可以通过 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 参数

Name 必需 类型 描述
artifactId 路径 TRUE 字符串 包的构件 ID
喂养 路径 TRUE 字符串 源的名称或 ID
groupId 路径 TRUE 字符串 包的组 ID
集合 路径 TRUE 字符串 Azure DevOps 集合的名称
版本 路径 TRUE 包的版本
项目 路径 字符串 项目 ID 或项目名称
API版本 (api-version) 查询 TRUE 字符串 要使用的 API 版本。 这应设置为“5.1-preview.1”才能使用此版本的 API

请求正文

Name 类型 描述
观看次数 JsonPatchOperation 将包版本添加到的视图

有关详细信息,请参阅 REST API 文档 ,因为它已更新。

反馈

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


返回页首