【发布时间】：2021-10-20 05:23:48
【问题描述】：
我已经为此奋斗了一段时间。我已经能够让它与两个单独的发布管道一起工作，但不是一个。似乎在一个管道中，用于发布的 PR 触发器会针对所有环境触发，即使使用单独的构建工件也是如此。
目标是在一个发布管道中包含以下内容：
PR 到 dev 并合并到 dev 部署到开发环境
PR 到主要部署到 QA 环境
将上述 PR 版本的主要内容合并到 prod（通过手动批准步骤）。
如果能得到这个单一的发布管道会很棒，因为这将减少开销和管理等。
我已经尝试了各种关于工件发布触发器和环境预部署条件的变体，但无济于事。
我什至尝试过使用 2 个单独的构建管道（一个用于主管道，一个用于开发），然后将两者作为工件加载并尝试以这种方式分离，但即使只有 1 个构建管道运行，它也会触发 PR 发布条件两种环境。
【问题讨论】：
-
将 PR 部署到静态环境并没有真正的意义。不同的 PR 将相互叠加部署，甚至存在多个 PR 尝试同时部署的竞争条件。如果您希望部署 PR，请设计您的部署过程以建立一个临时环境，该环境在 PR 关闭时可以轻松拆除。
-
您使用的是经典版本还是较新的管道？
-
虽然我同意建立一个临时环境会更好，但我不同意 PR 进入静态环境没有价值。
-
使用我认为是“经典”的版本。您可以查看 yml，但不能直接对其进行编辑。我们正在使用基于 Yyml 的构建管道。我相信您现在可以将发布步骤放入其中，这可能是一个解决方案。
标签： azure-devops git-flow