Elastik Beanstalk kurumsal sınıf CD için uygun mu?

Elastik Beanstalk'a mikro hizmetler oluşturmak ve dağıtmak için Jenkins kullanan bir proje ile çalışıyorum. Bir test ortamına bir entegrasyon dalı dağıtırız, bir hazırlama ortamına dalları serbest bırakırız ve daha sonra üretime son bir ana yapı oluştururuz. Bunu bu şekilde yapmakla ilgili birkaç endişem var: ilk olarak, çevre başına proje başına bir derleme, çabaları çoğaltmamız anlamına gelir; ve ikincisi, aynı yapıdaki yapay yapıları üretime, evrelemede onaylanmış olarak dağıtmadığımız anlamına gelir.

Beanstalk'ı terk etmeye ve konuşlandırmalar için Chef gibi bir şey kullanarak düz ASG'lere geçmeye meyilliyim. Bu, bizi bir yapı artefaktı üreten proje başına bir yapı ile bırakacaktı ve aynı artefaktı, evrelemede onaylanan üretime uygulayabiliriz. Bununla birlikte, geçişin önemsiz olmayan bir ön maliyeti vardır. Beanstalk'u daha güvenilir, daha kolay yönetilen CI / CD'ye olanak sağlayacak bir şekilde kullanmanın bir yolu var mı?

Not : Aynı yapı artefaktını tanıtmak tam olarak yapmak istediğim şeydir, ancak dokümanlardan bunu yapmanın net bir yolunu görmüyorum; uygulama kaynağından EB'ye nasıl dağıtım yapılacağını açıklar, ancak tam olarak ilerlemediğim sürece mevcut bir sürümü başka bir ortama nasıl tanıtacağınızı açıklamaz. EB'nin kendisinde mevcutsa, Jenkins EB dağıtım eklentisinde özellikle Jenkins'te yapılmasını engelleyen bir sınırlama olabilir, ancak bunu yapmanın bir yolunu görmedim.

IMO, sorununuz bu senaryoda Elastik Beanstalk ile değil, Jenkins ile veya en azından nasıl kullandığınızla ilgilidir. Gerçekten de, bir şeyin ne olduğuna bakılmaksızın, bir şeyi "bir kez" oluşturmaya odaklanmalısınız.

Tam Açıklama: ThoughtWorks için çalışıyorum ve GoCD'ye inanılmaz derecede önyargılıyım. Ne demek istediğimi nötr olabildiğince anlatmaya çalışacağım. Aracımızın belgelerini örnek olarak kullanacağım, ancak umarım insanlar sistemlerine tahmin edebilirler.

Boru hattınızın erken bir yerinde "eserler" inşa ediyorsunuz. Bu, uygulamanızın tamamını veya bir kısmını temsil eden ikili dosyalar olabilir veya test araçları gibi herhangi bir sayıda araçtan çıkarılabilir. Bu eserler sistem tarafından saklanmalı ve bir daha inşa edilmemelidir . Sistem daha sonra gerektiğinde artefaktı uygun revizyondan almalıdır.

Örneğin...

1. Ben bir .jar dosyası oluşturmak ve bazı birim testleri, temel C / I şeyler çalıştırın. Başarılı olursa, bu .jar dosyası ve testlerin çıktısı ilgili boru hattı işine yüklenir .
2. Bir sonraki boru hattı, daha karmaşık bir test ortamına konuşlandırmanız olabilir. Tam kavanozu, onu inşa eden tam işten almalıdır . Daha sonra bu kavanozu doğru ortama yerleştirmek için Elastik Beanstalk yürütür.
3. Bir sonraki ardışık düzen aşamalı dağıtımınızdır. İlk boru hattına tüm yol sırtını gider ve getirir kesin dan kavanozu kesin inşa işi. Sonra o kavanozu doğru ortama yerleştirmek için Elastik Beanstalk executus.

Bunların her biri ayrı boru hatlarıdır, çünkü bu, engellemeden paralel veya isteğe bağlı olarak daha fazla çalışmanıza izin verir .

Gerçek dağıtımları yapmak için Elastik Beanstalk, Şef, Kukla, Ansible, uDeploy veya başka herhangi bir araç kullanabilirsiniz. Sorununuz buradan gelmiyor. Sürekli Entegrasyon sunucuları başlangıçta bunu yapmak için tasarlanmamıştır. Tabii ki tercihinize göre aynı yere ulaşmak için kullanabileceğiniz birçok eklenti var.

GoCD , Chef Automate ve ConcourseCI gibi Sürekli Teslim sunucuları özellikle bu gibi şeyleri çözmek için oluşturuldu.