如何通过 11 个环境和独特任务简化复杂的 Azure DevOps 发布管道

Question

我目前正在使用 Azure DevOps Release Pipelines（经典 UI，而不是 YAML）开发一个整体应用程序。该应用程序需要部署到 11 个生产环境，每个环境都需要自己独特的任务集，以确保零停机更新。

我面临的问题是：

• 复杂的 UI：为了适应所有 11 个生产环境，发布管道现在具有大量阶段。我已经到了 29 个阶段，而且我还没有完成所有环境的配置。管理和可视化管道变得异常困难。

• 重新运行失败的阶段：如果我尝试将多个环境分组在一个阶段中以减少阶段数量，问题是如果该阶段中的任何作业失败，我将被迫重新运行整个阶段。 Azure DevOps 经典管道不允许在一个阶段内重新运行单个作业，当只有一个环境发生故障时，这会令人沮丧。

• 无停机时间：每个环境都需要特定的任务和作业，以确保无停机更新。这些任务因环境而异，因此我无法使用“一刀切”的方法或共享模板。

我想要一种更清晰的方式来构建此发布管道以实现以下目标：

• 适用于所有 11 个生产环境的单一发布管道。
• 更少的阶段来简化 UI 并提高可管理性。
• 如果出现故障，能够仅重新运行特定环境/作业，而无需重新运行整个阶段。
• 保留特定于环境的任务，以确保在不停机的情况下进行更新。

我尝试过的：

• 将任务合并为更少的阶段：这减少了阶段数量，但使故障更难以管理，因为我无法重新运行单个作业。
• 阶段内并行作业：有助于减少运行时间，但不能解决重新运行问题。
• 任务组：虽然任务组有助于提高可重用性，但它们并没有解决管道结构的核心复杂性。

是否有更好的方法来简化这个经典的 Azure DevOps 发布管道？我需要这样的东西：

• 减少级数。
• 允许对失败的环境/作业进行更精细的控制。
• 仍然可以适应特定环境的任务。

必须有一种方法可以做到这一点，或者发布管道是否不适合单片应用程序需要通过一个阶段？我只能使用 YAML 吗？

提前致谢！

Answer 1

这可能不是您期望听到的答案，但是巨大的管道或阶段将如何解决您面临的问题？您的第一个（可能也是最重要的）目标应该是减少复杂性，而不是管道、阶段和/或作业的数量。

在短期/中期策略中）考虑：

1. 为每组任务创建任务组，以便跨管道/阶段/作业重用功能

2. 为每个环境创建管道，以降低复杂性并能够独立管理每个环境

3. 根据功能逻辑地组织阶段和作业，并考虑哪些阶段和作业可以（或应该）一起运行，以防失败

这 3 个步骤应该可以帮助您解决大部分问题。

长期策略是使用 YAML 管道和可重用的模板来管理您的管道。