我们有一个 CodePipeline，它在每次 GitHub 提交/合并到 main 分支时运行，构建应用程序并将其发布到我们可以手动测试应用程序的暂存环境。时不时地，临时的，每周的，等等，取决于项目，我们会手动发布到生产环境。为了实现这一点，我在暂存和生产之间向我的 CodePipeline 添加了一个 ManualApprovalStep，但这意味着我的管道永远不会是绿色的。它总是卡在蓝色:
这让我觉得我在这里使用了错误的工具。
我的心智模型来自 Heroku(忽略评论应用程序，我还没有解决这个挑战):
在 Heroku 中，有一个“测试”选项卡，如果测试通过，它会显示为绿色；还有一个管道，如果它已部署到暂存区，则显示为绿色。在 Heroku 中缺乏对生产的提升并不是 Heroku 中的非绿色状态，而是在 ManualApprovalStep 中。
AWS 是否提供了另一种工具来模拟我所缺少的这种工作方式？
更新:另一个很大的区别。 ManualApprovalStep 似乎堆积了每个更改并发布了每个更改，一个接一个，而不是将最后一个版本发布到暂存区，因此很明显它与 Heroku 的生产版本不同。
最佳答案
您是对的，ManualApprovalStep 不是一种自然的“晋升”机制。它们用于是-否批准，将导致 execution failure if rejected or after 7 days . Disabled Stage Transitions也会尴尬地坐在你的用例上。
pipeline.CodePipline 执行 (a) 在对源进行更改时触发，并且 (b) 旨在运行从开始到结束的所有阶段。执行是 hard to interrupt .要求独立部署环境的结果是环境最好建模为独立的管道，而不是单个管道中的阶段。
简单选项:2 个 github 分支，2 个管道
克隆您的管道设置。暂存管道与 staging 分支源相关联。对 main 分支的更改会触发 prod 管道。这种设置很容易推理，并且具有部署始终与您的源匹配的优势。但它并没有复制 Heroku 的“推广”概念。
复杂选项:1 个 github 分支，2 个管道？
您可能会得到一些更接近“促销”模式的东西，方法是使用一个用于暂存的 pipelines.CodePipeline 部署(绑定(bind)到 github)和一个单独的 codepipeline.Pipeline 管道对于产品。后者可以由 EventBridge 事件触发。在这种情况下， Assets 处理会很复杂。
[编辑:] 为前端放大 CI/CD，为后端放大 CodePipeline
AWS Amplify CI/CD为前端应用程序提供自动功能分支部署、PR 审查批准等。手动部署需要一种解决方法，但这是可能的。看这个related SO question . CDK supports扩大构建配置。问题是这些 CI/CD 好东西适用于前端应用程序，但不适用于任意基础设施堆栈。为了两全其美，请将应用程序一分为二。将 Amplify 用于高速前端，并坚持使用 CodePipeline 进行后端部署。
关于amazon-web-services - 使用 AWS CodePipeline 时，我应该如何从暂存到生产进行部署？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/70986194/