为 PR 触发构建，但在 PR 完成之前阻止 CD

Question

我和我的团队正在努力在 ADO 中实施特定的 CI/CD 模式。

我们定义了一个名为“Develop”的构建管道和一个同名的发布管道。我们在我们的开发分支上设置了一个构建策略，要求“开发”构建管道在 PR 完成之前成功。我们还制定了审核/批准、评论解决和链接工作项的政策。

正如预期的那样，当提出 PR 时，我们的政策中引用的构建就会启动。同样如预期的那样，在构建成功之前无法完成 PR。然而，我们遇到的问题是，因为我们在发布管道上设置了一个 CD 触发器，所以 PR 触发的构建生成的工件将总是被部署，而不管其余的状态如何公关政策。

我们想要的顺序是这样的：

1. 提出 PR 会导致我们的“开发”构建管道执行。
   • 此构建必须成功才能完成 PR。
   • 存储此构建的工件，这样构建管道就不必在 PR 完成后再次运行，只需进行部署即可（构建需要一段时间）。
2. 构建管道成功执行。
   • 在满足其他政策之前，仍然无法完成 PR。
3. 其余的分支策略都得到满足。
4. PR 已完成。
   • 只有现在才能部署从构建管道生成的工件。
5. “开发”发布管道已执行，将工件部署到我们的测试环境。

在摆弄了我们管道的变体之后，我尝试在发布管道上简单地设置“拉取请求触发器”而不是“持续部署触发器”。我认为这需要 PR 导致创建工件，并且 PR 完成。我的假设是不正确的。有了这个新设置，提升 PR 会触发 Build Pipeline，而 Build Pipeline 成功会触发 Release Pipeline，即使 PR 尚未完成。

我们的 Build Pipeline 构建解决方案、运行测试、运行一些 PowerShell 脚本，最后将工件发布到 Azure Pipelines。也许这做得太多了。也许有一些方法可以构建、运行测试和脚本，然后以某种方式等待 PR 完成，然后再将工件传递到发布管道。我似乎无法弄清楚。有什么方法可以完成我上面列出的顺序吗？

需求，简而言之：

• 应在 PR 提出后立即开始构建。
• 构建不应多次执行（这需要很长时间，而且我们不能等待两次构建只是为了在“真正的”构建之前满足构建策略）。
• PR 完成应触发发布管道。

Answer 1

您的描述对 PR 触发有一些误解。

您可以配置一个拉取请求触发器，该触发器将创建一个新的 当拉取请求上传工件的新版本时发布。 启用触发器并添加拉取请求所针对的分支 你想激活这个触发器。

Pull request triggers

但是对于 CD 触发器，如果​​您只想在通过从某些分支编译代码生成构建时创建版本，则可以添加构建分支过滤器（仅适用于代码位于 TFVC 中的情况） 、Git 或 GitHub 存储库）或当构建具有某些标签时。这些可以是包含和排除过滤器。例如，使用 features/* 来包含 features 分支下的所有构建。您还可以在过滤器值中包含自定义变量。

或者，您可以指定一个过滤器以使用构建管道中指定的默认分支。 例如，当默认构建分支在每个开发冲刺中发生更改时，这很有用。这意味着您无需为每次更改都更新所有发布管道的触发器过滤器 - 而您只需更改构建管道中的默认分支。

更多详情请查看 Jeff Shepler 在此类似问题中的回复：VSTS release pull request build trigger