当使用AWS CodePipeline时，我应该如何从阶段部署到生产？

Question

我们有一个CodePipeline，它运行在每个GitHub提交/合并到main分支上，构建应用程序并将其发布到一个可以手动测试应用程序的暂存环境中。不时地，临时的，每周的，等等，取决于项目，我们会手动发布到生产。为了实现这一点，我在暂存和生产之间向我的CodePipeline添加了一个CodePipeline，但这意味着我的管道从来都不是绿色的。它总是卡在蓝色里：

​

​

这让我觉得我使用了错误的工具。

我的心智模型来自Heroku (忽略评论应用程序，我还没有应对这个挑战)：

​

​

在Heroku中有一个测试选项卡，如果测试通过，该选项卡是绿色的；如果部署到暂存阶段，则有一个管道是绿色的。在Heroku缺乏对生产的推广，在Heroku不是一个非绿色的状态，而是在ManualApprovalStep。

还有AWS给我提供的另一个工具来模拟我所缺少的这种工作方式吗？

更新：另一个很大的区别。ManualApprovalStep似乎将每个更改堆在一起，并一个一个地发布每个更改，而不是发布最后一个版本到阶段，所以很明显，它与Heroku所拥有的版本并不类似。

Answer 1

你是对的，ManualApprovalStep不是一个自然的“促进”机制。他们是为了是-没有批准，并将导致如果拒绝执行或7天后执行失败。残疾阶段过渡也会笨拙地使用您的用例。

pipeline.CodePipline执行是(a)在对源的更改时触发的，(b)意味着从开始到完成运行所有阶段。执行死刑是很难打断。独立部署环境的需求的一个结果是，最好将环境建模为独立的管道，而不是单个管道中的各个阶段。

简单选择:2个github分支，2个管道

克隆你的管道设置。暂存管道绑定到staging分支源。main分支的更改将触发prod管道。此设置易于推理，并具有部署始终与源匹配的优点。但它并没有复制Heroku的“推广”概念。

复杂选项:1 github分支，2管道？

您可能可以通过为暂存(绑定到github)的pipelines.CodePipeline部署和用于prod的单独的codepipeline.Pipeline管道，使其更接近“升级”模式。后者可以由EventBridge事件触发。在这种情况下，资产处理将是复杂的。

编辑:前端放大CI/CD，后端放大CodePipeline

AWS扩增CI/CD为您提供了前端应用程序的自动特性分支部署、PR评审审批等。手动部署需要一个解决办法，但是可能的。看这个与此相关的问题。CDK支持放大构建配置。问题是这些CI/CD的好东西适用于前端应用程序，但不适用于任意的基础结构栈。为了充分利用这两个世界，将应用程序分成两部分。高速前端使用放大，后端部署使用CodePipeline .