CI Continuous Integration (Sürekli Entegrasyon), CD ise Continuous Delivery (Sürekli Teslimat) ya da (Continuous Deployment) Sürekli Dağıtım kısaltmasını ifade etmektedir.
Continuous Integration (Sürekli Entegrasyon)
Sürekli entegrasyon mimarisi yapılan değişiklikler/geliştirmeler sonucu oluşan yeni sürümün, bir boru hattı (pipeline) vasıtasıyla, mevcut sürüm ile sürekli şekilde otomatik olarak birleştirilmesini sağlar. Burada önemli olan nokta sürecin bir boru hattı (pipeline) üzerinden yürütülüyor olmasıdır.
Boru hattı (pipeline) dediğimiz şey aslında süreçleri uç uca eklemek ve ihtiyaçlarımız doğrultusunda akışlara yön vererek otomatize edilmiş bir düzen oluşturmaktır.
CI pipeline içerisinde kabul kriterlerimiz için boru hatları oluşturur ve bunları bir araya getirerek yeni paketin ancak bir dizi otomatik kontrol sonrasında hedef sürüm ile birleştirilmesini sağlayabiliriz.
Şimdi örnek bir senaryo üzerinden anlamaya çalışalım;
dev adında bir branch (dal) olsun ve bu branch bizim canlıya çıkmaya aday sürümümüz olsun. Geliştirdiğimiz feature branch dev’e, dev branch’de master’a kapanıyor olacak. master bizim için canlıdaki (production) branch ifade ediyor.
Biz feature branch içerisinde geliştirmelerimizi tamamlarız. Ardından bu yeni paketin kontrollerinin/değerlendirmelerinin sağlanabilmesi için mevcut dev sürümü ile birleştirilmek üzere bir Pull Request (PR) oluştururuz. İşte bu PR’i açmamız ile birlikte CI pipeline feature > dev için çalışmaya başlayacaktır…
Yukarıdaki görsele baktığımızda PR sonrasında içerisinde kabul kriterlerimizin (acceptance criterias) bulunduğu bir CI Pipeline bulunmakta.
Buradaki CI Pipeline’ı bize ne anlatıyor?
- Yeni oluşturduğumuz sürümde projenin derlenmesine engel bir sorun olmaması gerekiyor. Eğer yeni gelen paketin derlenme (build) sürecinde bir hata olursa akış kesilecek ve hedef sürüm ile birleşimine izin verilmeyecektir.
- Eğer derlenme sürecinde bir sorun yaşanmazsa artık birim testlerimiz (Unit Test) çalışacak. Buradaki kabul kriterimiz ise birim testlerinin tamamının başarılı şekilde çalışması olacaktır. Eğer birim testleri çalışırken içlerinden bir test bile başarısız olursa süreç yine kesilecek ve yeni gelen paketin hedef sürüm ile birleşimine izin verilmeyecektir.
- Birim testlerimizinde başarılı şekilde çalıştığı durumda ise entegrasyon testleri (integration test) çalışacaktır. Aslında bir önceki adım ile bu adımı gruplamak gerekirse testlerimizi çalıştırdığımızı söyleyebiliriz.
Bu örnek boru hattına code coverage (testlerin kodun ne kadarını test ettiğinin ölçülmesi) limitlerinin kontrolünü, kod kalitesi/güvenlik ölçümleme araçlarının (örn: sonarqube) çalışmasını ve sonucunda çıkan rapora göre yeni paketin projeye dahil edilip edilmeyeceğine karar verebiliriz. Hatta başka bir geliştiricinin/takım liderinin vs. PR’i onaylaması koşullarını içeren borular ekleyebiliriz.
CI Pipeline tamamiyle proje/şirket kültürü ya da ihtiyaçları doğrultusunda şekillenen bir süreçtir. (Örn: CI pipeline içerisine stres testleri, penetration testler, veritabanı performans kontrolleri vs. gibi daha ileri seviye süreçler ekleyebilirsiniz.)
CI sürecini kendinize özel bash scriptler vs. ile kurgulayabileceğiniz gibi Jenkins vb. araçlarda kullanabilirsiniz.
Continuous Delivery (Sürekli Teslimat)
Sürekli teslimat ise istenilen bir sürümün istenilen bir ortama elle tetiklemek suretiyle deploy edilebilmesidir. Yani biz istemedikçe deployment sağlanmaz, deployment istediğimizde süreci manuel olarak başlatırız.
Normalde ilgili bir sürümü deploy etmek için manuel gerçekleştirdiğimiz tüm adımları komut dosyaları vs. aracılığıyla otomatize ederiz.
Yani görselleştirmek gerekirse artık akışımız aşağıdaki şekilde olacaktır;
Fakat otomatize ettiğimiz bu akışın başlaması için elle (manuel) tetikleriz. Peki ya bu sürecide otomatiğe bağlasak, CI süreci tamamlandığında ilgili ortamlara biz tetiklemeden deploy olsa ister misiniz..?
Continuous Deployment (Sürekli Dağıtım)
Sürekli dağıtım ise CI sonrasında ilgili ortamlara deploymentin otomatik olarak yapılmasıdır. CI pipeline’i CD pipeline’a bağlarız ve bu sayede güncel sürümün yayınlanmasını istediğimiz ortamlara otomatik deploy ederiz.
Örnek üzerinden ilerleyecek olursak;
dev branch’te bir güncelleme olduğunda internal ya da staging ortamlarına deploy olmasını, master branch’te bir güncelleme olduğunda pre-prod ya da prod ortamlarına deploy olmasını sağlayabiliriz.
CD pipeline içerisinde migrationların çalışması, trafiğin yeni sürüme iletilmesi için swap/routing işlemleri, cdn önbellek temizliği, log rotation vs. hedef ortamın ve mimarinizin dinamiklerine göre dilediğiniz işlevleri dahil edebilirsiniz.
Yorumlamakta zorlanmadığınız artifact’leriniz, rotate ederken kaybetmediğiniz ve ihtiyaç duyduğunuzda kolayca ulaşabileceğiniz loglarınız olması dileğiyle…
Selamlar ben docker dökümantasyonlarını okurken CI / CD terimlerine denk geldim. Araştırma yaparken yazınızı gördüm fakat yeni olduğum için tam anlayamadım çok karışık geldi.
Aslında Docker ile CI/CD doğrudan ilişkisi bulunmuyor. CI/CD süreçlerinizde Docker kullanabilirsiniz ama kullanmadanda kurgulayabilirsiniz (ki yakın geçmişe kadar böyle yapılıyordu).