sürekli entegrasyon

• "continuous integration". bir yazılım geliştirme modeli ve bu modelde "akışı yöneten" yazılımlara verilen isim.
  
  burada "entegrasyon" tabiri geliştirme sürecinde takım üyelerinin yaptığı değişikliklerin ana koda dahil edilmesi anlamında kullanılır. yani kendisine "continuous merge" dense de olur. entegrasyonun yazılım geliştirmede biraz daha geniş bir anlamı var. izole geliştirilen ve test edilen yazılım bileşenlerinin bir arada çalışır hale getirilmesine de denir. (bkz: integration testing) (bkz: reverse integration).
  
  herkesin ana branch'e kod değişikliklerini commit edip sürekli push ettiği model aslında bir continuous integration modelidir. ancak kod yarım yamalak push'lanırsa, mesela derlenmez haldeyse bu sefer o halini çeken takım üyeleri ellerinde çalışmayan bir kod elde ederler (bkz: build break). bu takımın çalışmasını durdurur. herkesin o bozukluğu kafasına göre düzeltmeye çalışmasına, çakışmalara ve oldukça vakit kaybına yol açar.
  
  o yüzden her değişiklik push'landığında bunları derlemeye çalışıp hata varsa değişikliği yollayanı uyaran bir sistem gerekir. işte bunlara ci yazılımı deniyor. jenkins, hudson, travis gibi yazılımların temelde çıkış amacı bu.
  
  peki yazılım başarıyla derlense yetiyor mu? yetmiyor. adam belki kodun derlenmesini değil ama doğru çalışmasını bozan bir değişiklik push etti? bu sefer diğer takım üyeleri bu halini çekerlerse yazılımı doğru olarak test edemez hale geliyorlar. kendi geliştirme süreçleri yine duruyor.
  
  buna engel olmak için de ci yazılımlarına "unit testleri de çalıştır" özelliği eklenir. testler hata vermeye başlarsa değişikliği yapan uyarılır. takımın "bak bu halini çekersen elinde patlar düzeltilene kadar bekle" mesajı alması sağlanır.
  
  peki unit testler yetiyor mu? yetmiyor. belki sadece son kullanıcının kullanım senaryolarında bir hata ortaya çıktı? bunları da "ui test"lerle bulmak mümkün olabilir ama onları otomatik geliştirmesi ve her ui değişikliğinde güncel tutması zahmetli. ne yapılabilir? o durumda ci yazılımı kodun son halini alır bir yere çalışır halde koyar (aka deploy eder). böylece geliştiricilerin ve varsa testçilerin kodun son halini test etmesi ve bir hata varsa raporlaması mümkün olur.
  
  ci kullanılmasa ne olur? herkes kendi branch'lerinde çok uzun süre çalışırsa sonunda kod birleştirilemez bir hal alabilir. windows vista'nın geliştirme sürecinde başa gelen ve kodun en baştan yazılmasına yol açan meşhur longhorn reset olayı gibi mesela. tabi o çok uçuk ve büyük çaplı bir durum ama küçük projelerde dahi geliştiriciler birbirlerinden kopuk ilerlerse bir süre sonra kodları birbirlerini tanımaz hal alablir. ci bu açıdan iyidir. agile disiplinlerinde de tercih edilir.