• "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.
  • (bkz: continuum)
  • yazılım geliştirirken geliştirmenin her aşamasında projeyi çalışabilir halde tutmak için geliştirilmiş disiplindir.
    örneğin her commit sonrası unit test 4 saatte bir integration test gecelik olarak functional testler bir ci server*** üzerinde çalıştırılır. bu build lerden herhangi birisini bozan işini gücünü bırakır ilgili sorunu fixler, fixlemezse product owner developerı bi güzel fixler.bu şekilde saldım çayıra mevlam kayıra metodolojisinden uzak durulur.
  • (bkz: jenkins)
    [http://jenkins-ci.org/ http://jenkins-ci.org/]
  • http://travis-ci.org/
  • tool olarak atlassian'in diger urunleri (jira, confluence) ile entegre calisan bamboo kullanilabilir.

    martin fowler'in ci hakkinda soyle guzel bir yazisi var okumaya deger.
  • (bkz: teamcity)
    link
  • (bkz: code is always releaseable)

    halen taraftari olamadigim management sistemi. ozeti :gunluk buildlerin ve build scriptlerin yerine kodu yaz build kos testlerini kos her zaman senden kod istendiginde elimde kod var diyebil.
    guzel bir yaklasim gelistirici takimlari icin ancak. gelistirme dongusu icinde buildle beraber test toolu entegre et, buildin yapisini degistirecek build scriptlerin olsun, ayri bir projede componentleri build edip birlestir, aksam gunluk build yap, sabah test toolundan cikan kritik hatalari coz, sonra gelistirmeye basla daha kaliteli kod olusturulmasini sagliyor. su anda cı ile gelistirilmis programlarin cogu masallah bocek yetistirme ciftligi gibi paso cakiyorlar. her taraflarinda memory allocation errorlar, guvenlik aciklari var. ancak bu sistem yuzunden mi kaynaklaniyor uyguluyacilar yuzunden mi kaynaklaniyor emin degilim.
  • hakkında ekşi duyuruda soru olan faydalı yaklaşım.
  • continious integration'ın scrum dostu implementasyonları ile çok güzel sonuçlar alınıyor.

    .net core ile linux üzerinde çalışan bir uygulamamızın geliştirme sürecinde scrum için yazılmış her story git üzerinde bir ya da birkaç branch şeklinde yaratılıyor. bu branch'ler code review'ların ardından yeni yazılan kodlar develop ile merge ediliyor. build server her commit ve merge sırasında unit test'leri çalıştırarak hem commit edilen kodun kendi sağlığını hem de develop'a commit edilmiş diğer kodların kırılıp kırılmadığını otomatik olarak kontrol ediyor. tüm bu süreç jira'dan ilgili story/sprint için izlenebiliyor çünkü tam entegre çalışıyor. gerçekten harika.

    burada anahtar kelime unit test'ler. programcılar ne kadar çok unit test yazarsa sistemin otomasyonu o kadar artıyor. deadline sıkıştırdıysa şirket içinde ortalığı ayağa kaldıracak error'lardan kaçınan çakallar ise unit test'leri mimimumda tutup hataları erteliyorlar. bunun önüne geçmenin yolu da unit test'lerin kaderini developer'ların insafına bırakmamak, üst yönetim seviyelerinde sıkı denetlemek.
hesabın var mı? giriş yap