在AWS CodePipeline中使用多个构建的手动批准

Question

我们设置CodePipeline进行构建，部署到QA ECS环境，然后手动批准步骤部署到Prod。

令人困惑的是，当有多个构建一个接一个地运行时。几个版本按顺序部署到QA，但是批准按钮似乎一次批准它们，并且当您点击它时，您不清楚您批准哪个版本。

我希望能够做的是批准最新版本，以防万一  早期的版本存在由后期版本修复的问题。什么是实现这一目标的最佳方式？

Answer 1

我遇到了同样的问题。手动批准令人困惑，因为几个流水线执行可能会排队，很容易丢失事情。我想我们可以归咎于CodePipeline糟糕的用户体验。

我解决的解决方法是为同一个项目提供两个相同的管道。它们具有相同的源阶段（相同的repo / branch）但不同的部署阶段（一个部署到QA，一个部署到prod）。没有更多的手动批准阶段。当需要手动释放Prod管道时，检测到源（repo / branch）中的更改时，QA管道设置为自动执行。

基本上，我们用手动发布替换了手动审批。与手动批准不同，手动释放始终从源代码发布最新版本。

Answer 2

您应该将部署和批准操作置于同一阶段。这使您可以准确地批准您测试的内容。为什么？因为在任何给定时间，只有一个管道执行可以处于管道阶段。

  

...批准最新版本，以防早期版本出现问题   由后来的版本修复。

如果您想让以后的版本赶上，请拒绝等待批准的早期版本。

Answer 3

如果您不想拥有多个管道，一个选项是默认情况下禁用阶段转换到需要受控释放的环境中。

准备好部署到环境中时，启用阶段转换以允许处理上一阶段的最新版本，然后再次禁用转换。

它仍然有点笨拙，但是一旦你习惯它，它会相当有效。必须拒绝通过的每个更改变得非常缓慢和繁琐，因此通过禁用转换，您选择何时推广发布。

IMO，如果在手动审批阶段暂停执行，CodePipeline应该可以选择自动取代执行。

Answer 4

嗯，我们可以解决这个问题，就像你用开发来描述它一样，但它也可能是一个过程故障。

例如：如果我们有开发分支，发布分支（分段）和主分支（生产），我们可以轻松解决此问题。

开发部门 我们开发的东西将经历开发分支阶段，我们不需要手动批准，因为我们不想检查每个变化。我们为此设置了自动化单元测试。

发布分支 这将部署到我们广泛测试软件质量的临时环境，也基于接受系统的验收链上的回归测试。这应该在合并到master分支之前防止所有重大问题。接下来，我们还可以在暂存环境中手动测试发布分支。如果这样可行，请快乐并轻松迁移到主人

主分公司 这将在实际部署之前通过手动批准部署到生产环境，确保您只会推送1个更改，即从发布到主服务器的合并，防止您在故障单中汇总的问题。

另一种方法是开发一个新的AWS功能，您可以在其中取消选中或选中一个复选框，说明：始终采用最新版本，但这无助于为管道集成增加价值，因为在没有足够测试的情况下推送内容。< / p>

Answer 5

在CodePipeline用户界面中，您可以在管道的 历史记录 中查看手动批准的历史记录。单击历史记录以查看正在进行的操作（尚未超时的手动批准将始终处于 progress 中）和触发该操作的源（git）短阴影（如果需要缩小到相关的提交）。

要了解您要批准的手动批准，请在“管道”视图中，单击“手动”步骤旁边的查看当前修订（以获取执行ID），然后在“历史记录”中找到匹配的执行ID （应该是最早的）。

我发现获得最新批准的唯一方法是在管道中击中n-1次拒绝（其中 n 是仍在进行中的手动批准），直到我只有1个批准左（或直到找到匹配的执行ID）。