Sürekli Entegrasyon

Kısaca CI olarak anılan sürekli entegrasyon, herkesin kendi çalışmasını çoğu zaman mainline denen paylaşılan ana branch'e en az günde bir kez birleştirdiği bir geliştirme pratiğidir. Her birleştirme otomatik bir derleme ve test çalıştırmasını tetikler; böylece ekip, birleşen kodun hâlâ çalışıp çalışmadığını dakikalar içinde öğrenir. Pratik, 1990'ların sonunda Extreme Programming ile adını aldı ve yayıldı; Martin Fowler'ın bu konudaki makalesi de onu geniş kitlelere tanıttı.

Uygulamada GitHub Actions, GitLab CI ya da Jenkins gibi bir CI servisi depoyu izler. Biri bir commit push'ladığında ya da bir pull request açtığında kodu temiz bir makinede çeker, bağımlılıkları kurar, projeyi derler, linter'ları ve otomatik testleri çalıştırır ve pull request'e yeşil ya da kırmızı bir durum bildirir. Kırmızı bir build ekibin en önemli önceliğidir: onu bozan kişi, başka hiçbir şey birleştirilmeden önce sorunu düzeltir ya da değişikliği geri alır. Geri bildirimi hızlı tutmak için ekipler yaklaşık on dakikalık bir build hedefler; bu hedef de Extreme Programming'den gelir.

Birlikte tek bir rapor yazan birkaç kişiyi düşünün. Her biri bir ay boyunca tek başına yazar ve her şey teslimden önceki gece birleştirilirse bölümler birbiriyle çelişir, birleştirme de günler sürer; geliştiriciler buna entegrasyon cehennemi (integration hell) der. Herkes kendi sayfalarını her gün ortak taslağa ekler ve bir editör onu hemen okursa çakışmalar küçük kalır ve henüz tazeyken düzeltilir.

Sürekli entegrasyon çoğu zaman sürekli teslimatla ya da yalnızca bir CI aracına sahip olmakla karıştırılır. CI, ana branch'te doğrulanmış kodla biter; sürekli teslimat oradan devralır ve bu kodu her an canlı ortama dağıtılabilir durumda tutar. Haftalarca yaşayan feature branch'lerde bir CI sunucusu çalıştırmak da asıl anlamıyla sürekli entegrasyon değildir: amaç küçük değişiklikleri ana branch'e sık sık entegre etmektir; bu yüzden CI, trunk-based development ile el ele gider.