使用独占锁检查时对顺序部署的支持

  • 项目

在此冲刺中，我们扩展了 Azure Pipelines 中独占锁检查的功能，以支持顺序部署。 现在，可以在环境中对多个运行进行排队，一次只允许执行其中一个运行。

有关详细信息，请查看以下功能说明。

Azure Boards

Azure Pipelines

Azure Boards

工作项中的 开发部分 显示相关提交和拉取请求的列表。 可以查看提交或拉取请求的作者以及关联的时间。 在此更新中，我们修复了作者头像在视图中显示错误的问题。

Azure Pipelines

仅当使用独占锁检查时，才支持顺序部署而不是最新部署

在 YAML 管道中，检查用于控制 受保护资源上阶段的执行。 可以使用的常见检查之一是独占锁检查。 此检查仅允许从管道进行单个运行。 当多个运行尝试同时部署到环境时，检查会取消所有旧运行，并允许部署最新的运行。

如果发布是累积版本的，并且包含以前运行的所有代码更改，则取消旧运行是一种很好的方法。 但是，在某些管道中，代码更改不是累积的。 使用此新功能，可以选择允许所有运行继续并按顺序部署到环境，或保留以前取消旧运行并仅允许最新运行的行为。 可以使用管道 YAML 文件中名为 lockBehavior 的新属性指定此行为。 值 sequential 表示所有运行都按顺序获取受保护资源的锁。 值 runLatest 表示只有最新的运行才能获取资源的锁。

若要将独占锁检查用于sequential部署或 runLatest，请执行以下步骤：

  1. 在环境 (或其他受保护资源) 上启用独占锁检查。
  2. 在管道的 YAML 文件中，指定名为 lockBehavior的新属性。 可以针对整个管道或给定阶段指定此值：

在舞台上设置：

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

在管道上设置：

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

如果未指定 ， lockBehavior则假定 runLatest为 。

支持魁北克版 ServiceNow

Azure Pipelines 与 ServiceNow 的现有集成。 集成依赖于 ServiceNow 中的应用和 Azure DevOps 中的 扩展 。 现在，我们已将应用更新为使用魁北克版 ServiceNow。 经典管道和 YAML 管道现在都适用于魁北克。 若要确保此集成正常工作，请从 Service Now 存储升级到应用 (4.188.0) 的新版本。 有关详细信息，请参阅 与 ServiceNow 更改管理集成。

在 Microsoft 托管的 Windows 和 macOS 代理上更改 .NET SDK 预安装策略

最近，我们 宣布对 Microsoft 托管的 Ubuntu 代理的 .NET SDK 预安装策略进行了更改。 我们现在正在对 Microsoft 托管的 Windows 和 macOS 代理进行相同的更改。

目前，我们在 Microsoft 托管的 Windows 和 macOS 代理上安装所有可用和支持的 .NET SDK (2.1.x、3.1.x、5.0.x) 。 此方法将更改，转而为每个功能版本安装最新的修补程序版本。 进行此更改是为了提供更多的可用空间和新的工具请求。

它意味着什么？

SDK 版本由以下部分组成： x.y.znn。 z 是功能版本，是 nn 修补程序版本。 例如，对于 2.1.302，功能版本为 3，02 为修补程序版本。 根据新方法，我们将仅为每个功能版本安装最新的修补程序版本，即仅针对 2.1.3x 安装 2.1.302，2.1.4x 仅安装 2.1.403，等等。 所有不是最新修补程序版本的 .NET SDK 版本将于 9 月 6 日从 Windows 和 macOS 映像中删除。 此更改会影响 Microsoft 托管代理上所有版本的 Windows 和 macOS。

目标日期

更新后的映像的部署将于 9 月 6 日开始，需要 3-4 天。

可能的影响

如果使用 global.json 文件，则生成将在以下情况下受到影响：

如果 global.json 文件包含 rollForward: disable 属性和 SDK 版本不是最新修补程序版本，则生成将失败。 例如：

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "disable"
  }
}

如果 global.json 文件包含 rollForward: patch 属性，则 .NET SDK 版本将自动更改为最新修补程序。 例如：

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "patch"
  }
}

rollForward如果未在 global.json 文件中指定字段，则不会有任何更改。 使用最新安装的修补程序级别。

如果需要使用不是最新修补程序的确切 .NET SDK 版本，请使用任务UseDotNet在生成过程中安装它：

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk'
  inputs:
    version: <dotnet version>

对 PublishBuildArtifacts 和 DownloadBuildArtifacts 任务的更改

Azure Pipelines 支持两组用于发布/下载项目的任务。 PublishPipelineArtifact 和 DownloadPipelineArtifact 是执行这些步骤的更新和推荐任务。

PublishBuildArtifacts 和 DownloadBuildArtifacts 是较旧的任务，它们的性能和存储优化与相应的 PipelineArtifact 任务不同。 这些旧任务在实现方式方面也存在规模限制。 我们的一些大型客户已遇到这些限制。

虽然我们希望所有客户都迁移到 PipelineArtifact 任务，但我们也必须采取一些步骤来解决较旧的 BuildArtifact 任务的可伸缩性。 作为最近更新的一部分，以提高其可伸缩性，Azure Pipelines 代理现在将通过 blob 存储域 (直接与生成项目交互，而不是通过 tfs 域) 路由。 这些管道将开始访问早就位于 Azure DevOps 允许列表 上的 IP 地址和域，但特定管道以前可能未使用过这些地址和域。

BuildArtifact 任务的更新实现需要代理升级，除非已专门禁用自动升级或防火墙配置错误，否则应自动进行。

如果代理在未遵循链接说明的防火墙环境中运行，则在更新代理或 PublishBuildArtifacts 或 DownloadBuildArtifacts 任务中，它们可能会看到失败，直到防火墙配置得到更正。

此问题的一个常见症状是与 ssl 握手或项目下载失败相关的突然错误，通常是在Release Management定义所针对的部署池上。 或者，如果代理升级被阻止，你可能会发现发布正在等待池中永远不会到达的代理，或者代理在更新 (后者与错误地阻止代理 CDN) 的环境相关。

后续步骤

注意

这些功能将在未来两到三周内推出。

前往 Azure DevOps 并了解一下。

转到 Azure DevOps

如何提供反馈

我们很想听听你对这些功能的看法。 使用帮助菜单报告问题或提供建议。

提出建议

你还可以在 Stack Overflow 上获取社区的建议和问题解答。

此致

亚伦·霍尔伯格