CI / CD nedir? Sürekli entegrasyon ve sürekli teslimat açıklaması

Sürekli entegrasyon (CI) ve sürekli teslimat (CD), uygulama geliştirme ekiplerinin kod değişikliklerini daha sık ve güvenilir bir şekilde sunmasını sağlayan bir kültür, çalışma ilkeleri kümesi ve uygulamalar koleksiyonunu içerir. Uygulama aynı zamanda CI / CD ardışık düzeni olarak da bilinir . 

CI / CD, ekiplerin uygulamaya koyması için en iyi uygulamalardan biridir. Aynı zamanda, yazılım geliştirme ekiplerinin iş gereksinimlerini karşılamaya, kod kalitesine ve güvenliğe odaklanmasını sağladığından çevik bir metodoloji en iyi uygulamasıdır çünkü dağıtım adımları otomatikleştirilmiştir.

CI / CD tanımlı

Sürekli entegrasyon  , geliştirme ekiplerini küçük değişiklikleri uygulamaya ve kodu sürüm kontrol havuzlarına sık sık teslim etmeye yönlendiren bir kodlama felsefesi ve uygulamalar kümesidir. Çoğu modern uygulama, farklı platformlarda ve araçlarda kod geliştirmeyi gerektirdiğinden, ekibin değişikliklerini entegre etmek ve doğrulamak için bir mekanizmaya ihtiyacı vardır.

CI'nin teknik amacı, uygulamaları oluşturmak, paketlemek ve test etmek için tutarlı ve otomatik bir yol oluşturmaktır. Entegrasyon sürecindeki tutarlılık sayesinde, ekiplerin kod değişikliklerini daha sık gerçekleştirme olasılığı daha yüksektir ve bu da daha iyi işbirliği ve yazılım kalitesi sağlar.

Sürekli teslimat  , sürekli entegrasyonun bittiği yerden başlar. CD, uygulamaların seçilen altyapı ortamlarına teslimini otomatikleştirir. Çoğu ekip, geliştirme ve test ortamları gibi üretim dışındaki birden çok ortamla çalışır ve CD, kod değişikliklerini bunlara iletmenin otomatik bir yolunu sağlar.

CI / CD araçları, her teslimatta paketlenmesi gereken ortama özgü parametreleri depolamaya yardımcı olur. CI / CD otomasyonu daha sonra web sunucularına, veritabanlarına ve yeniden başlatılması gerekebilecek veya uygulamalar devreye alındığında diğer prosedürleri izlemesi gerekebilecek diğer hizmetlere gerekli hizmet çağrılarını gerçekleştirir.

Sürekli entegrasyon ve sürekli teslimat, sürekli test  gerektirir  çünkü amaç, kullanıcılara kaliteli uygulamalar ve kod sunmaktır. Sürekli test genellikle bir dizi otomatik gerileme, performans ve CI / CD ardışık düzeninde yürütülen diğer testler olarak uygulanır.

Olgun bir CI / CD geliştirme uygulaması, uygulama değişikliklerinin CI / CD ardışık düzeninden geçtiği ve geçiş yapılarının doğrudan üretim ortamlarına dağıtıldığı sürekli dağıtım uygulama seçeneğine sahiptir. Sürekli teslimat uygulayan ekipler, her iş uygulaması için sürekli teslimat her zaman ideal olmasa da, üretime günlük veya hatta saatlik bir programda dağıtmayı seçerler.  

İlgili video: CI / CD ile kodun daha hızlı iletilmesi

Sürekli entegrasyon, işbirliğini ve kaliteyi nasıl iyileştirir?

Sürekli entegrasyon, süreç mekaniği ve bazı otomasyonlarla desteklenen bir geliştirme felsefesidir. CI pratiği yaparken, geliştiriciler kodlarını sürüm kontrol havuzuna sıklıkla kullanırlar ve çoğu takımın en azından günlük olarak minimum bir kod işleme standardı vardır. Bunun arkasındaki mantık, kusurları ve diğer yazılım kalitesi sorunlarını tanımlamanın uzun zaman aralıklarında geliştirilen daha büyük olanlardan ziyade daha küçük kod farklılıklarındaki daha kolay olmasıdır. Ek olarak, geliştiriciler daha kısa tamamlama döngüleri üzerinde çalışırken, birden fazla geliştiricinin aynı kodu düzenlemesi ve taahhütte bulunurken bir birleştirme gerektirmesi olasılığı daha düşüktür.

Sürekli entegrasyon uygulayan ekipler genellikle sürüm kontrol yapılandırması ve uygulama tanımlarıyla başlar. Kodu kontrol etme sık sık yapılsa da, özellikler ve düzeltmeler hem kısa hem de daha uzun zaman dilimlerinde uygulanır. Sürekli entegrasyon uygulayan geliştirme ekipleri, hangi özelliklerin ve kodun üretime hazır olduğunu kontrol etmek için farklı teknikler kullanır.

Çoğu ekip , çalışma zamanında özellikleri ve kodu açmak veya kapatmak için bir yapılandırma mekanizması olan özellik bayraklarını kullanır . Hala geliştirilmekte olan özellikler, koddaki özellik bayraklarıyla sarmalanır, ana dal ile üretime dağıtılır ve kullanıma hazır olana kadar kapatılır. Yakın zamanda yapılan bir ankete göre, özellik bayraklarını kullanan ekiplerin yüzde 63'ü daha iyi test ve daha kaliteli yazılım bildiriyor. CloudBees Rollout, Optimizely Rollouts ve LaunchDarkly gibi özellik işaretleme araçları, CI / CD araçlarıyla entegre olur ve özellik düzeyinde yapılandırmaları etkinleştirir.

Özellikleri yönetmek için başka bir teknik,  sürüm kontrol dallarına ayırmadır . Yeni kodun geliştirme, test etme ve üretim için standart dallarla nasıl birleştirildiği üzerine protokolleri tanımlamak için Gitflow gibi bir dallanma stratejisi seçilir. Daha uzun geliştirme döngüleri alacak olanlar için ek özellik dalları oluşturulur. Özellik tamamlandığında, geliştiriciler özellik dallarındaki değişiklikleri birincil geliştirme dalında birleştirebilirler. Bu yaklaşım iyi çalışıyor, ancak aynı anda geliştirilen birçok özellik varsa yönetimi zor hale gelebilir.

Derleme sürecinin kendisi daha sonra tüm yazılım, veritabanı ve diğer bileşenleri paketleyerek otomatik hale getirilir. Örneğin, bir Java uygulaması geliştiriyorsanız CI, HTML, CSS ve JavaScript gibi tüm statik web sunucusu dosyalarını Java uygulaması ve herhangi bir veritabanı komut dosyasıyla birlikte paketler.

CI yalnızca tüm yazılım ve veritabanı bileşenlerini paketlemekle kalmaz, aynı zamanda otomasyon birim testlerini ve diğer testleri de yürütür. Bu test, geliştiricilere kod değişikliklerinin mevcut birim testlerini bozmadığı konusunda geri bildirim sağlar.

Çoğu CI / CD aracı, geliştiricilerin sürüm kontrol havuzundaki kod işlemleriyle veya tanımlanmış bir programla tetiklenen isteğe bağlı olarak derlemeleri başlatmasına izin verir. Ekiplerin, ekibin boyutu, beklenen günlük taahhütlerin sayısı ve diğer uygulama konuları için en iyi şekilde çalışan oluşturma programını tartışmaları gerekir. Kaydetme ve derlemelerin hızlı olmasını sağlamak için en iyi uygulama, aksi takdirde hızlı kodlamaya ve sık sık işlem yapmaya çalışan ekiplerin ilerlemesini engelleyebilir.

Sürekli test, test otomasyonunun ötesine geçer

Otomatik test çerçeveleri, kalite güvence mühendislerinin, geliştirme ekiplerinin bir yazılım derlemesinin başarılı olup olmadığını bilmesine yardımcı olabilecek çeşitli test türlerini tanımlamasına, yürütmesine ve otomatikleştirmesine yardımcı olur. Her sprint sonunda geliştirilen ve tüm uygulama için bir regresyon testinde toplanan işlevsellik testlerini içerirler . Bu regresyon testleri daha sonra, ekibe bir kod değişikliğinin, test kapsamının olduğu uygulamanın tüm fonksiyonel alanlarında geliştirilen testlerden bir veya daha fazlasında başarısız olup olmadığını bildirir.

En iyi uygulama, geliştiricilerin yerel ortamlarında regresyon testlerinin tamamını veya bir alt kümesini çalıştırmasını sağlamak ve zorunlu kılmaktır. Bu adım, geliştiricilerin kodu yalnızca regresyon testleri kod değişikliklerini geçtikten sonra sürüm kontrolüne işlemesini sağlar.

Regresyon testleri sadece başlangıçtır. Performans testi, API testi, statik kod analizi, güvenlik testi ve diğer test formları da otomatikleştirilebilir. Önemli olan, bu testleri komut satırı, webhook veya web hizmeti aracılığıyla tetikleyebilmek ve bunların başarılı veya başarısız durum kodlarıyla yanıt vermesidir.

Test otomatikleştirildikten sonra, sürekli test, otomasyonun CI / CD ardışık düzenine entegre edildiği anlamına gelir. Bazı birim ve işlevsellik testleri, entegrasyon süreci öncesinde veya sırasında sorunları işaretleyen CI'ya entegre edilebilir. Performans ve güvenlik testi gibi tam bir teslimat ortamı gerektiren testler genellikle CD'ye entegre edilir ve yapılar hedef ortamlara teslim edildikten sonra gerçekleştirilir.

CD ardışık düzeni, birden çok ortamda yapılan değişiklikleri otomatikleştirir

Sürekli teslimat, uygulamaları teslimat ortamlarına iten otomasyondur. Çoğu geliştirme ekibi, tipik olarak, uygulama değişikliklerinin test ve gözden geçirme için hazırlandığı bir veya daha fazla geliştirme ve test ortamına sahiptir. Adımları otomatikleştirmek ve raporlama sağlamak için Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo veya Travis CI gibi bir CI / CD aracı kullanılır.

Tipik bir CD ardışık düzeni oluşturma, test etme ve dağıtma aşamalarına sahiptir. Daha karmaşık ardışık düzenler şu adımların çoğunu içerir:

  • Sürüm denetiminden kod çekme ve bir derlemeyi yürütme.
  • Bulut altyapısını ayağa kaldırmak veya yıkmak için kod olarak otomatikleştirilen gerekli altyapı adımlarını yürütme.
  • Kodu hedef bilgi işlem ortamına taşıma.
  • Ortam değişkenlerinin yönetilmesi ve hedef ortam için yapılandırılması.
  • Uygulama bileşenlerini web sunucuları, API hizmetleri ve veritabanı hizmetleri gibi uygun hizmetlerine gönderme.
  • Hizmetleri yeniden başlatmak veya yeni kod gönderimleri için gerekli olan hizmet uç noktalarını çağırmak için gereken adımların yürütülmesi.
  • Testler başarısız olursa sürekli testler ve geri alma ortamları yürütme.
  • Teslimat durumu hakkında günlük verileri ve uyarılar sağlamak.

Örnek olarak, Jenkins kullanıcıları işlem hatlarını derleme, test etme ve devreye alma gibi farklı aşamaları açıklayan bir Jenkins dosyasında tanımlar. Ortam değişkenleri, seçenekler, gizli anahtarlar, sertifikalar ve diğer parametreler dosyada bildirilir ve ardından aşamalar halinde başvurulur. Gönderi bölümü, hata koşullarını ve bildirimleri ele alır.  

Daha karmaşık CD, veri senkronizasyonlarının gerçekleştirilmesi, bilgi kaynaklarının arşivlenmesi veya uygulama ve kitaplık yamalarının gerçekleştirilmesi gibi başka adımlara sahip olabilir. CI / CD araçları genellikle bir eklenti pazarını destekler. Örneğin, Jenkins, üçüncü taraf platformlar, kullanıcı arabirimi, yönetim, kaynak kodu yönetimi ve derleme yönetimiyle entegrasyonu destekleyen 1.500'den fazla eklenti listeler.

Bir CI / CD aracı seçildikten sonra, geliştirme ekipleri tüm ortam değişkenlerinin uygulama dışında yapılandırıldığından emin olmalıdır. CI / CD araçları, bu değişkenlerin ayarlanmasına, parolalar ve hesap anahtarları gibi değişkenlerin maskelemesine ve hedef ortam için dağıtım sırasında yapılandırılmasına izin verir.

CD araçları ayrıca gösterge tablosu ve raporlama işlevleri sağlar. Derlemeler veya teslimatlar başarısız olursa, geliştiricileri hatalarla ilgili bilgilerle uyarırlar. Sürüm kontrolü ve çevik araçlarla entegre olurlar, böylece bir derlemeyi oluşturan kod değişikliklerini ve kullanıcı hikayelerini aramak için kullanılabilirler.

Kubernetes ve sunucusuz mimarilerle CI / CD ardışık düzenlerini uygulama 

Bulut ortamlarında CI / CD ardışık düzenlerini çalıştıran birçok ekip, Docker gibi konteynerler ve Kubernetes gibi düzenleme sistemleri de kullanır. Konteynerler, standart, taşınabilir yollarla paketleme ve nakliye uygulamalarına izin verir. Konteynerler, değişken iş yüklerine sahip ortamların ölçeğini büyütmeyi veya yıkmayı kolaylaştırır.

Kapsayıcıları, altyapıyı kod olarak ve CI / CD ardışık düzenlerini birlikte kullanmak için birçok yaklaşım vardır. Jenkins ile Kubernetes veya Azure DevOps ile Kubernetes gibi öğreticiler aracılığıyla çalışarak seçenekleri keşfedebilirsiniz.

Sunucusuz bilgi işlem mimarileri, uygulamaları dağıtmak ve ölçeklendirmek için başka bir yol sunar. Sunucusuz bir ortamda altyapı, bulut hizmet sağlayıcısı tarafından tamamen yönetilir ve uygulama, yapılandırmasına bağlı olarak kaynakları gerektiği kadar tüketir. Örneğin AWS'de Lambda işlevleri olarak çalışan sunucusuz uygulamalar ve dağıtımlar, bir eklenti ile Jenkins CI / CD ardışık düzenine entegre edilebilir. 

CI / CD, daha sık kod dağıtımlarına olanak tanır

Özetlemek gerekirse, CI yazılım derlemelerini paketler ve test eder ve değişiklikleri herhangi bir birim testinde başarısız olursa geliştiricileri uyarır. CD, altyapıda değişiklikler sağlayan ve ek testler gerçekleştiren otomasyondur. 

CI / CD ardışık düzenleri, uygulamaları sık sık iyileştirmek isteyen ve güvenilir bir teslimat sürecine ihtiyaç duyan işletmeler için tasarlanmıştır. Derlemeleri standartlaştırmak, testler geliştirmek ve dağıtımları otomatikleştirmek için ek çaba, kod değişikliklerini dağıtmak için üretim sürecidir. Bir kez yerleştirildiğinde, ekiplerin uygulamaları geliştirme sürecine odaklanmalarına ve bunu bilgi işlem ortamlarına sunmanın sistem ayrıntılarına daha az odaklanmalarına olanak tanır.

CI / CD, kararlı uygulamalar isteyen işlemlerle, sık sık değişiklik yapmak isteyen geliştiriciler arasındaki yanlış hizalamayı ele aldığı için geliştirici bir en iyi uygulamadır. Otomasyon mevcut olduğunda, geliştiriciler değişiklikleri daha sık zorlayabilir. Ortamlar standart yapılandırmalara sahip olduğu, teslimat sürecinde sürekli testler yapıldığı, ortam değişkenleri uygulamadan ayrıldığı ve geri alma prosedürleri otomatikleştirildiği için operasyon ekipleri daha fazla kararlılık görüyor.

CI / CD ardışık düzenlerinin uygulanmasının etkisi, devops anahtar performans göstergesi (KPI) olarak ölçülebilir. Bir olaydan dağıtım sıklığı, değişim sağlama süresi ve ortalama kurtarma süresi (MTTR) gibi KPI'lar, sürekli testli CI / CD uygulandığında genellikle iyileştirilir. Bununla birlikte, CI / CD, bu gelişmeleri sürdürebilen yalnızca bir işlemdir ve dağıtım sıklıklarını iyileştirmek için başka ön koşullar vardır.

CI / CD'ye başlamak, geliştirme ekiplerinin ve operasyon ekiplerinin teknolojiler, uygulamalar ve öncelikler üzerinde işbirliği yapmasını gerektirir. Takımların, işleri ve teknolojileri için doğru yaklaşımlar üzerinde fikir birliği geliştirmeleri gerekir, böylece CI / CD yerleştirildikten sonra, takım sürekli olarak aşağıdaki uygulamaları takip eder.