Elastic Beanstalk convient-il aux CD d'entreprise?

Je travaille avec un projet qui utilise Jenkins pour créer et déployer des microservices sur Elastic Beanstalk. Nous déployons une branche d'intégration dans un environnement de test, libérons des branches dans un environnement intermédiaire, puis une version finale du master en production. J'ai quelques inquiétudes à faire de cette façon: premièrement, cela signifie que nous nous retrouvons avec une matrice d'une construction par projet et par environnement, en dupliquant les efforts; et deuxièmement, cela signifie que nous ne déployons pas les mêmes artefacts de génération en production qui ont été validés lors de la préparation.

Je suis enclin à abandonner Beanstalk et à passer à des ASG simples en utilisant quelque chose comme Chef pour les déploiements. Cela nous laisserait une génération par projet, produisant un artefact de génération, et nous pourrions déployer le même artefact en production qui a été approuvé dans la mise en scène. La transition a cependant un coût initial non négligeable. Existe-t-il un moyen d'utiliser mieux Beanstalk qui permettrait un CI / CD plus fiable et plus facile à gérer?

Remarque : La promotion du même artefact de construction est exactement ce que je veux faire, mais d'après les documents, je ne vois aucun moyen clair de le faire; il explique comment déployer sur EB à partir de la source de votre application, mais pas comment promouvoir une version existante dans un autre environnement, sauf si j'ai réussi à la faire défiler à droite. S'il est disponible dans EB lui-même, il peut y avoir une limitation dans le plugin de déploiement Jenkins EB qui l'empêche de se faire spécifiquement dans Jenkins, mais je n'ai pas vu de moyen de le faire du tout.

L'OMI pense que votre problème n'est pas avec Elastic Beanstalk dans ce scénario, c'est avec Jenkins, ou du moins la façon dont vous l'utilisez. Vous devez vraiment vous concentrer sur la construction d'une «chose» une seule fois, quelle que soit cette chose.

Divulgation complète: Je travaille pour ThoughtWorks et je suis incroyablement partisan du GoCD. J'essaierai de préciser ce que je veux dire en étant aussi neutre que possible. J'utiliserai les documents de notre outil comme exemples, mais j'espère que les gens pourront extrapoler à leurs systèmes.

Quelque part au début de votre pipeline, vous créez des "artefacts". Il peut s'agir de fichiers binaires représentant tout ou partie de votre application, ou ils peuvent être générés par un certain nombre d'outils tels que des outils de test. Ces artefacts doivent être stockés par le système et ne plus jamais être reconstruits. Le système doit ensuite récupérer l'artefact de la révision appropriée en cas de besoin.

Par exemple...

1. Je crée un fichier .jar et exécute des tests unitaires dessus, des trucs de base C / I. S'il réussit, ce fichier .jar et la sortie des tests sont téléchargés vers ce travail de pipeline spécifique .
2. Le prochain pipeline pourrait être votre déploiement dans un environnement de test plus complexe. Il faut aller chercher l' exacte pot de l' exacte travail qui l'a construit. Il exécute ensuite Elastic Beanstalk pour déployer ce pot dans l'environnement approprié.
3. Le prochain pipeline est votre déploiement intermédiaire. Il va tout l'arrière de façon à la première canalisation et va chercher l' exacte pot de l' exacte travail qui l'a construit. Exécutez ensuite Elastic Beanstalk pour déployer ce pot dans l'environnement approprié.

Ce sont chacun des pipelines distincts, car cela vous permet d' exécuter davantage en parallèle ou à la demande sans blocage.

Vous pouvez utiliser Elastic Beanstalk, Chef, Puppet, Ansible, uDeploy ou un certain nombre d'autres outils pour effectuer les déploiements réels. Ce n'est pas de là que vient votre problème. Les serveurs d'intégration continue n'ont pas été conçus à l'origine pour ce faire. Bien sûr, il existe de nombreux plugins que vous pouvez utiliser pour vous rendre au même endroit si vous le souhaitez.

Les serveurs de livraison continue comme GoCD , Chef Automate et ConcourseCI ont été construits spécifiquement pour résoudre des problèmes comme celui-ci.