İnşa otomasyonuna karşı dağıtım otomasyonuna karşı sürekli entegrasyon

Daha verimli olmak istiyorum ve ops araçlarını verimli kullanmak istiyorum.

Bunu göz önünde bulundurarak, sürekli entegrasyon hakkında daha fazla bilgi edinmek istedim, ancak görünüşe göre bu konuda birçok farklı şey var.

Aslında işimde Jetbrains takımlarıyla çalışıyorum (IntelliJ, WebStorm ...), bu yüzden onları kullanmaya devam etmek istedim ve sürekli entegrasyon için birçok eklentiye sahip harika bir araç gibi görünen TeamCity'yi kullanmak istedim.

Benim sorunum arasındaki farkların ne olduğunu bilmiyorum:

• bina otomasyonu (TeamCity bu tür bir yazılımdır): Uygulamamızı uzak bir VCS deposu ile oluşturabileceğimizi biliyorum ve harika, ama bunun ana amacı nedir? Bunu yaparken ne tür bilgiler önemlidir? Aslında, yazılımımın yerel olarak oluşturulup oluşturulmadığını ve takım arkadaşlarımın da zaten olduğunu biliyorum. Peki, otomasyonu dağıtmadan kullanmanın amacı nedir?

• otomasyon dağıtma (TeamCity bunu kolayca yapmıyor gibi görünüyor)

• sürekli entegrasyon (yukarıdaki ikisinin birleşimi gibi görünüyor)
• sürekli dağıtım (bu tam olarak nedir? neden sürekli entegrasyondan farklıdır?)

Bunu biraz daha anlamama yardımcı olabilir misiniz?

Wikipedia, bu terimlerin çoğunun oldukça iyi özetlerini verir. İşte onları almam:

• Derleme otomasyonu , derleyiciyi manuel olarak çağırmak yerine yazılımın nasıl oluşturulacağını otomatikleştiriyor . Bu, örneğin, Make veya Ant gibi araçlar vasıtasıyla gerçekleştirilebilir .

• Dağıtım otomasyonu yerleşik yazılımınızı alıyor ve bir test veya üretim sistemine dağıtıyor veya kuruyor.

• Sürekli entegrasyon , geliştiricilerin kodu kontrol ettiği ve otomatik olarak kodun çalıştığından emin olmak için birim testleri uyguladığı için yazılımınızı sürekli olarak otomatik hale getirmek anlamına gelir . Örneğin, bir sunucu her 15 ila 30 dakikada bir uyanabilir, yeni check-in'ler için VCS'yi tarayabilir , ardından herhangi bir değişiklik yapılırsa projeyi güncelleyebilir ve oluşturabilirsiniz. Derleme adımlarını gerçekleştirmenin yanı sıra, otomatik birim testleri ve kod kalitesi denetimleri yapmak için de harika bir fırsattır .

• Sürekli dağıtım , yazılım yapılarının da bir test sistemine dağıtıldığı önceki kavramların bir birleşimidir, isteğe bağlı olarak yapılan testler ve oluşturulan raporlarla.

En azından, yapı otomasyonuna, yani bir çeşit yapı komut dosyasına sahip olmanız gerekir . Bu, projenizi oluşturmak için bir düğmeyi tıklamanız veya bir komut vermenizi sağlar. Bunun yararı, manuel olarak çalışan adımlardan kaynaklanan hataları azaltmaktır. Karmaşık yapı ortamları, kod oluşturmayı ( yapılandırmalardan DAO'ları , JAXB gibi arabirim kodunu düşünün ), kodu derlemeyi, paketlemeyi, meta verileri özelleştirmeyi vb. İçerebilir . oluşturma komut dosyası ve çalıştırmak için bir araç? Hataları azaltır ve tutarlılık sağlar.

Sıradaki CI: Bu gerçekten iyi ama kesinlikle gerekli değil. Sorunları erken teşhis etmeye yardımcı olur. Gün boyunca kodu kontrol eden ve belki de kendi çalışma alanlarını sürekli olarak senkronize etmeyen birden fazla geliştiriciniz varsa, değişikliklerinin birbirlerini etkileme riski vardır. Özellikle sürüm kontrolü çakışmalarına değil, statik kod hatalarına atıfta bulunuyorum. Bir CI derleme sunucusu bu riski azaltacaktır.

Son olarak dağıtım adımlarımız var. Buradaki fikir, zamandan tasarruf etmek ve yazılımı manuel olarak dağıtmaktan kaynaklanan hatayı azaltmaktır. Yapı otomasyonu gibi, bir yazılım dağıtımını kapatmanın yüz yolu vardır. Yarın tesise gelecek müşteriler için işleyen bir sisteme ihtiyaç duyduğumuzda birçok durumda manuel dağıtım sorunlarını gidermek için şahsen ofiste geç kaldım. Birden fazla sistemi otomatikleştirmek daha fazla risk doğurur: Muhtemelen çökecek veya garip hatalar olan bir sistem yerine artık birden çok sistemimiz varyanlış gidebilecek sistemler. Bununla birlikte, bu risk, bir kontrol listesinde bir adımı atlamayan veya yanlış komut veren ve bir dağıtımı bozan birinden çok daha düşüktür. Şanslıysanız, bir DB yedeklemesini geri yükleyebilir ve baştan başlayabilirsiniz, eğer şanssızsanız, bir hata sistemin yanlış çalışmasına neden olabilir. Bir yazılım hatası mı? Teknisyen yapılandırmayı doğru bir şekilde ayarlamadı mı? Bu işlemin teşhis edilmesi, sahip olamayacağınız zaman ve süreci otomatik hale getirirseniz harcanmaması gereken zaman alır.

• Sürekli Entegrasyon , tüm geliştiricilerin değişikliklerini günde birkaç kez paylaşılan bir ana hatta birleştirme uygulamasıdır. Bu uygulama şimdi o kadar yaygındır ki, önemli görünmeyebilir, ancak geleneksel olarak takımlar yazılım üzerinde haftalarca hatta aylarca tecrit halinde çalışacaktır. Sonuç, ayrı iş akışları bir araya getirildiğinde "Entegrasyon Cehennemi" oldu. Sürekli Entegrasyon normalde sorunları erken bulmak için paylaşılan ana hattın otomatik yapıları ile kullanılır, ancak DevOps'tan daha sık taahhüt ve geliştirici iş akışı ile ilgilidir.

• Otomatik derlemeler, derlemenin yerel olarak geçmesine neden olabilecek ancak derleme sunucusunda başarısız olmasına neden olabilecek sorunları toplamak için değerlidir (örneğin, bir dosyayı teslim etmeyi unuttunuz, derleme sunucusundaki bağımlılıklar eşleşmiyor). Yapı sunucusunun bu sorunları algılaması, takım arkadaşlarınız yapmadan önce bunları düzeltebileceğiniz anlamına gelir.

• Sürekli Teslimat, yazılımınızın sürekli olarak dağıtılmasını, çalıştırılmasını ve test edilmesini içerir. Otomatik derlemeler, yazılımınızın gerçekten derlendiğini (ve birim sınamalarının geçtiğini) sağlarken, dağıtım komut dosyalarınızın hala çalıştığı veya yazılımınızın gerçekten uçtan uca çalıştığı anlamına gelmez. Sürekli Teslimatın amacı, ana hattın üretime konuşlandırmaya uygun bir durumda kalmasını sağlayan bir dizi kontrole sahip olmaktır.

• Sürekli Dağıtım, bir sonraki mantıksal adımdır - sürekli dağıtım kanalından başarıyla geçen her taahhüdü otomatik olarak dağıtır. Bu uygulamanın çeşitli faydaları vardır, ancak benim için, burada ana fikir, küçük, sık taahhütlerin daha az riskli olmasıdır.

Daha fazla bilgi için bu kitabı okumanızı tavsiye ederim:

• Sürekli Teslimat: Derleme, Test ve Dağıtım Otomasyonu ile Güvenilir Yazılım Sürümleri

Takım araçlarının çoğu gibi Teamcity, birçok farklı görevi çalıştırmanıza izin veren merkezi bir uygulamadır. Bu, CI derlemeleri gibi tam derlemeler gerçekleştirmeyi, tam sürüm derlemeleri içerir ve dağıtımları gerçekleştirmenizi sağlar. Bir çözüm dosyasında msbuild'i çalıştırmak için ant veya nant'ı çağırmak için teamcity kullanıyorsanız, dağıtımları gerçekleştirecek nant komut dosyalarını da çağırabilirsiniz. Biraz komut dosyası gerektirebilir, ancak bu zor değildir.

Tam CI'ler, Veritabanı CI'ları için teamcity ve bambu kullanıyoruz ve INTegration ortamına dağıtılıyoruz. Daha sonra tam sürüm sürümleri ve otomatik olarak db geçiş komut dosyaları oluşturmak için teamcity kullanıyoruz. Bunlar, nant komut dosyalarına çağrılan teamcity işleri aracılığıyla SVN'de kontrol edilir. Konuşlandırmalar için, tahmin ettiniz, konuşlandırma görevlerini gerçekleştirmek için nant çağırmak için teamcity kullanıyoruz. Teamcity aracısı teamcity sunucusuyla konuştuğundan ve aracı, kodu bir güvenlik duvarı vb. .