Azure devops Devops多级管道只需一次批准

我有一个多级YAML管道：

Build Solution
     |
     ▼
Terraform DEV         \
     |                 |
     ▼                 |
Deploy Function App    |  DEV Environment (No Approval Required)
     |                 |
     ▼                 |
Provision API Mgmt    /
     |
     ▼
Terraform TEST        \
     |                 |
     ▼                 |
Deploy Function App    |  TEST Environment (Approval Required)
     |                 |
     ▼                 |
Provision API Mgmt    /

我配置了两个环境（

DEV

和

TEST

），在

TEST

环境上配置了批准，

Terraform TEST

阶段配置了部署作业，以使用

TEST

环境。这意味着，当管道到达

地形测试

阶段时，会向

测试

环境的审批人发送一封电子邮件，然后等待

当该阶段获得批准后，构建将继续

Deploy Function App

阶段也有一个部署作业，针对管道中该部分的环境。我的问题是，当它到达

测试

环境的

部署功能应用程序

时，它再次请求批准部署到

测试

环境

---

我的问题是：这是固定的行为吗？i、 e.每当在获得批准的情况下对环境进行部署时，是否需要新的批准？或者有没有办法改变它，使管道只需要一次批准就可以部署到特定环境中（根据需要多次部署）？

这是设计的。其中一种情况是，如果将更改回滚到以前的管道运行，那么最好的做法是在将代码重新部署到环境之前获得批准。对于有3个阶段的场景，每个阶段都需要：

一个阶段可以由多个作业组成，每个作业可以消耗多个资源。在开始执行阶段之前，必须满足对该阶段中使用的所有资源的所有检查。Azure Pipelines在每个阶段之前暂停管道的执行，并等待所有挂起的检查完成。根据每次检查中指定的重试间隔重新评估检查。如果在指定的超时之前所有检查都未成功，则该阶段不执行。如果任何检查最终失败（例如，如果您拒绝其中一个资源的批准），则该阶段不会执行

---

在您给定的场景中，我是否可以建议Terraform、function app和APIM部署属于同一阶段？它们中的每一个都可以在其他环境中重用。这将消除用户不正确地批准这些文件的可能性（除非您概述了dependsOn），或者Terraform应用是唯一发布的版本的可能性。

是的，我认为您是对的。我使用阶段来帮助实施依赖关系，因为实际的管道更复杂（即，有任意数量的部署作业，所有这些作业都需要在api提供阶段之前完成）。默认操作是作业相互依赖；然而，这一点。另一个选择是，如果你需要暂停。是的，我们似乎默认在多个代理上设置了并行构建（这对于真正的并行化步骤很有用），所以我只需要在模板文件中巧妙地命名作业。