Elastic Beanstalk是否适合企业级CD？

我正在与一个使用Jenkins来构建微服务并将其部署到Elastic Beanstalk的项目一起工作。我们将集成分支部署到测试环境，将分支发布到暂存环境，然后将最终主版本构建到生产环境。我这样做有两个问题：首先，这意味着我们最终得到一个矩阵，该矩阵是每个项目每个环境一个构建的矩阵，需要重复的工作；第二，这意味着我们不会在生产中部署经过阶段验证的相同构建工件。

我倾向于放弃Beanstalk，而使用诸如Chef之类的东西迁移到普通的ASG。这将使我们每个项目只有一个构建，生成一个构建工件，并且我们可以将相同的工件部署到阶段中批准的生产中。但是，过渡的前期成本并不微不足道。有什么方法可以更好地使用Beanstalk，从而使CI / CD更可靠，更易于管理？

注意：推广相同的构建工件正是我想要做的，但是从文档中我看不到任何明确的方法；它说明了如何从您的应用程序源部署到EB，但没有说明如何将现有版本升级到另一个环境，除非我设法向右滚动。如果它可以在EB本身中使用，则Jenkins EB部署插件中可能会有一个限制，使其无法专门在Jenkins中完成，但是我还没有找到实现它的方法。

IMO认为您的问题不在那种情况下的Elastic Beanstalk，而是Jenkins，或者至少是您使用它的方式。无论该东西是什么，您实际上应该只专注于构建“一个东西”一次。

全面披露：我为ThoughtWorks工作，对GoCD抱有极大的偏见。我将尽我所能阐明中立的含义。我将使用我们工具的文档作为示例，但希望人们可以推断出他们的系统。

在开发流程的早期，您正在构建“工件”。这可能是代表整个或部分应用程序的二进制文件，也可能是从许多工具（例如测试工具）输出的二进制文件。这些工件应由系统存储，并且不再构建。然后，系统应在需要时从适当的修订版本中获取工件。

例如...

1. 我建立一个.jar文件，并在其上运行一些单元测试，这是基本的C / I东西。如果通过，则该.jar文件和测试输出将上传到该特定管道作业。
2. 下一个管道可能是您部署到更复杂的测试环境。它应该从构建它的确切工作中获取确切的 jar 。然后，它执行Elastic Beanstalk以将该jar部署到正确的环境。
3. 下一个管道是您的暂存部署。它一直回到第一个管道，并从构建它的确切作业中获取确切的 jar 。然后，执行人员将Elastic Beanstalk将该jar部署到正确的环境。

这些都是独立的管道，因为这使您可以并行运行或按需运行而不阻塞。

您可以使用Elastic Beanstalk，Chef，Puppet，Ansible，uDeploy或任何其他工具来进行实际部署。那不是您问题的出处。持续集成服务器最初并不是为此目的而构建的。当然，如果您愿意的话，可以使用很多插件来到达同一个地方。

诸如GoCD，Chef Automate和ConcourseCI之类的Continuous Delivery服务器是专门为解决此类问题而构建的。