O Elastic Beanstalk é adequado para CD de nível empresarial?

Estou trabalhando com um projeto que usa o Jenkins para criar e implantar microsserviços no Elastic Beanstalk. Implementamos uma ramificação de integração em um ambiente de teste, liberamos ramificações em um ambiente de preparação e, em seguida, uma construção principal final para produção. Tenho algumas preocupações em fazê-lo desta maneira: primeiro, significa que terminamos com uma matriz de uma compilação por projeto por ambiente, duplicando esforços; e dois, significa que não estamos implementando os mesmos artefatos de construção na produção que foram validados no preparo.

Estou inclinado a abandonar o Beanstalk e mudar para ASGs simples usando algo como Chef para implantações. Isso nos deixaria com uma construção por projeto, produzindo um artefato de construção, e poderíamos implantar o mesmo artefato na produção que foi aprovado na preparação. A transição tem um custo inicial não-insignificante, no entanto. Existe alguma maneira de usar o Beanstalk melhor que permita um IC / CD mais confiável e fácil de gerenciar?

Nota : Promover o mesmo artefato de construção é exatamente o que eu quero fazer, mas pelos documentos não vejo uma maneira clara de fazer isso; explica como implantar no EB a partir da fonte do aplicativo, mas não como promover uma versão existente para outro ambiente, a menos que eu tenha conseguido rolar a página. Se estiver disponível no próprio EB, pode haver uma limitação no plug-in de implantação do Jenkins EB que impede que seja feito especificamente no Jenkins, mas não vi uma maneira de fazê-lo.

Na opinião da IMO, seu problema não está no Elastic Beanstalk nesse cenário, é no Jenkins, ou pelo menos na maneira como você o está usando. Você realmente deve se concentrar em construir "uma coisa" apenas uma vez, independentemente do que seja.

Divulgação completa: Trabalho para a ThoughtWorks e sou incrivelmente inclinado ao GoCD. Vou tentar explicar o que quero dizer com o mais neutro possível. Usarei os documentos de nossa ferramenta como exemplos, mas espero que as pessoas possam extrapolar para seus sistemas.

Em algum lugar no início do seu pipeline, você está construindo "artefatos". Podem ser binários que representam a totalidade ou parte da sua aplicação ou podem ser produzidos a partir de qualquer número de ferramentas, como ferramentas de teste. Esses artefatos devem ser armazenados pelo sistema e nunca construídos novamente. O sistema deve buscar o artefato na revisão adequada, quando necessário.

Por exemplo...

1. Eu construo um arquivo .jar e executo alguns testes de unidade nele, coisas básicas de C / I. Se for aprovado, esse arquivo .jar e a saída dos testes serão carregados no trabalho de pipeline específico .
2. O próximo pipeline pode ser sua implantação em um ambiente de teste mais complexo. Deve buscar o exato frasco do exato trabalho que construiu. Em seguida, ele executa o Elastic Beanstalk para implantar esse jar no ambiente correto.
3. O próximo pipeline é sua implantação de preparação. Ele vai todo o caminho de volta para o primeiro oleoduto e vai buscar a exata frasco do exato trabalho que construiu. Em seguida, execute o Elastic Beanstalk para implantar esse jar no ambiente correto.

Esses são pipelines separados, porque isso permite que você execute mais em paralelo ou sob demanda sem bloquear.

Você pode usar o Elastic Beanstalk, Chef, Puppet, Ansible, uDeploy ou qualquer número de outras ferramentas para fazer as implantações reais. Não é daí que vem o seu problema. Os servidores de integração contínua não foram criados originalmente para fazer isso. Claro que existem muitos plugins que você pode usar para chegar ao mesmo lugar, se essa for sua preferência.

Servidores de entrega contínua como GoCD , Chef Automate e ConcourseCI foram construídos especificamente para resolver coisas como essa.