我正在将我们的部署管道从TeamCity + Octopus Deploy迁移到AWS Pipeline（使用AWS CodeBuild + AWS CodeDeploy）。我已经能够为1个环境设置整个管道。我正在努力将部署推广到其他环境。
例如，初始部署是在测试环境中进行的。测试实例上的CodeDeploy代理处理配置转换（即用测试值替换连接字符串等）。现在，我想将相同的工件（无需重建）部署到生产环境中，以便代理执行相同的操作，并在生产环境中运行应用程序。
在Octopus Deploy中，此功能是内置的。您只需单击“升级”按钮，然后选择目标环境。是否可以通过AWS CodePipeline服务实现相同的目的？
答案 0 :(得分：1)
在CodeDeploy中，“应用程序”映射到将在其中部署代码的“部署组”。部署组可以是一组EC2实例或ECS / Lambda。在“部署组”中没有“环境”（开发/测试/生产）的概念。
在AWS世界中，您需要一个CodePipeline，它具有多个阶段，可以使用CodeDeploy作为部署提供程序进行部署。这些多个CodeDeploy应用程序（处于不同的CodePipeline阶段）将映射到不同的环境（dev / test / etc），因为这些CD应用程序的部署组将映射到不同的实例集。馈送到这些Deploy阶段的工件（在CodePipeline中）应该相同，并且您可以使用手动批准操作将部署“控制”到例如生产环境。
答案 1 :(得分：0)
我目前正在试用相同的迁移，发现它不适用于我们当前的流程，要充分利用它，您必须改用更线性或基于主干的方法。
正如 shariqmaws 指出的那样，没有环境，但是您可以将每个管道类似于一个八达通频道，因此您将拥有一个 Live 管道，它可以构建 master、部署到 Staging/UAT，然后等待升级到 Live，然后您可以有一个用于不稳定更改的开发管道。
这一切都很好，但棘手的一点是 Dev/QA 分支在章鱼中很容易管理，我们在合并之前进行了测试，因此有必要创建或更改现有的 Dev/QA 管道以指向任何功能您要部署用于测试的分支，这不是很实用，因为您需要另一个管道来管理此管道！
Octopus 是一个“自动化部署和发布管理工具”，而 CodePipeline 只是一个持续集成/部署工具，所以你不能用它来真正取代章鱼。