Czy Elastic Beanstalk nadaje się do płyt CD klasy korporacyjnej?

Pracuję z projektem wykorzystującym Jenkinsa do tworzenia i wdrażania mikrousług na Elastic Beanstalk. Wdrażamy gałąź integracji w środowisku testowym, wypuszczamy gałęzie do środowiska pomostowego, a następnie finalną wersję główną do produkcji. Mam kilka obaw związanych z robieniem tego w ten sposób: po pierwsze, oznacza to, że otrzymujemy matrycę jednej kompilacji na projekt na środowisko, powielając wysiłki; a po drugie, oznacza to, że nie wdrażamy tych samych artefaktów kompilacji do produkcji, które zostały sprawdzone podczas przemieszczania.

Skłaniam się do porzucenia Beanstalk i przejścia do zwykłych ASG przy użyciu czegoś takiego jak szef kuchni do wdrożeń. To dałoby nam jedną kompilację na projekt, tworząc artefakt kompilacji, i moglibyśmy wdrożyć ten sam artefakt do produkcji, która została zatwierdzona podczas przygotowywania. Przejście na system wiąże się jednak z niewielkimi kosztami wstępnymi. Czy jest jakiś sposób na lepsze wykorzystanie Beanstalk, które pozwoliłyby na bardziej niezawodne, łatwiejsze w zarządzaniu CI / CD?

Uwaga : Promowanie tego samego artefaktu kompilacji jest dokładnie tym, co chcę zrobić, ale z dokumentów nie widzę żadnego wyraźnego sposobu, aby to zrobić; wyjaśnia, jak wdrożyć do EB ze źródła aplikacji, ale nie jak promować istniejącą wersję w innym środowisku, chyba że udało mi się przewinąć tuż obok niej. Jeśli jest dostępny w samym EB, może istnieć ograniczenie we wtyczce wdrażania Jenkins EB, które uniemożliwia wykonanie go w Jenkins, ale nie widziałem w ogóle sposobu, aby to zrobić.

Zdaniem IMO twój problem nie dotyczy Elastic Beanstalk w tym scenariuszu, dotyczy Jenkins, a przynajmniej sposobu, w jaki go używasz. Powinieneś naprawdę skoncentrować się na budowaniu „rzeczy” tylko raz, niezależnie od tego, co to jest.

Pełne ujawnienie: Pracuję dla ThoughtWorks i jestem niewiarygodnie stronniczy w stosunku do GoCD. Spróbuję wyjaśnić, co mam na myśli, tak neutralny, jak to tylko możliwe. Będę korzystać z dokumentów naszego narzędzia, które są przykładami, ale mam nadzieję, że ludzie będą mogli ekstrapolować swoje systemy.

Gdzieś na początku swojej rurociągu budujesz „artefakty”. Mogą to być pliki binarne reprezentujące całość lub część aplikacji lub dane wyjściowe z dowolnej liczby narzędzi, takich jak narzędzia testujące. Te artefakty powinny być przechowywane przez system i nigdy więcej nie budowane. W razie potrzeby system powinien pobrać artefakt z odpowiedniej wersji.

Na przykład...

1. Buduję plik .jar i uruchamiam na nim kilka testów jednostkowych, podstawowe rzeczy dotyczące C / I. Jeśli przejdzie, ten plik .jar i wyniki testów zostaną przesłane do tego konkretnego zadania potoku .
2. Kolejnym potokiem może być wdrożenie w bardziej złożonym środowisku testowym. Należy pobrać dokładnie słoik z dokładnym pracy, która go zbudował. Następnie wykonuje Elastic Beanstalk, aby wdrożyć ten słoik w odpowiednim środowisku.
3. Kolejnym potokiem jest wdrożenie etapowe. Przechodzi z powrotem do pierwszego rurociągu i pobiera dokładny słoik z dokładnego zadania, które go zbudowało. Następnie wykonaj Elastic Beanstalk, aby wdrożyć ten słoik w odpowiednim środowisku.

Są to osobne potoki, ponieważ pozwala to na uruchamianie większej liczby równolegle lub na żądanie bez blokowania.

Możesz użyć Elastic Beanstalk, Chef, Puppet, Ansible, uDeploy lub dowolnej liczby innych narzędzi do wykonania rzeczywistych wdrożeń. Nie z tego pochodzi twój problem. Serwery ciągłej integracji nie zostały pierwotnie zbudowane w tym celu. Oczywiście istnieje wiele wtyczek, których możesz użyć, aby dostać się do tego samego miejsca, jeśli takie są twoje preferencje.

Serwery Continuous Delivery, takie jak GoCD , Chef Automate i ConcourseCI, zostały zbudowane specjalnie w celu rozwiązania takich problemów.