20 dakikadan uzun boru hattı, boru hattı değildir

Küçük ekiplerde sürekli entegrasyon (CI) iki hâlden birinde bulunuyor: ya hiç kurulmamış, ya da kurulmuş ama kimse çıktısına bakmıyor çünkü sürekli kırmızı.

İkincisi birincisinden daha kötü — çünkü kırmızıya alışmış bir ekip, gerçek bir hatayı da gürültü sanıyor.

Neden 20 dakika

Bu sayı keyfi değil, davranışsal. Bir boru hattı 20 dakikayı geçtiğinde geliştirici sonucu beklemiyor, başka işe geçiyor. Sonuç geldiğinde bağlam kaybolmuş oluyor; düzeltme maliyeti artıyor. Yeterince yavaş bir hat, pratikte hiç olmayan bir hatla aynı şeye dönüşüyor.

Hedef: her değişiklik için 10 dakikanın altı.

Hızlandırmanın sırası

1. Önbelleği doğru kur

En büyük kazanç genelde burada. Bağımlılık indirmesi çoğu hattın en uzun adımı ve tamamen önbelleklenebilir.

Anahtar seçimi kritik: kilit dosyasının (package-lock.json, yarn.lock, pnpm-lock.yaml) özetini kullanın. Dal adına göre önbellekleme yaparsanız isabet oranı düşük olur.

2. İşleri paralelleştir

Statik analiz, tip kontrolü ve testler birbirini beklemiyor. Sıralı çalıştırıldığında süre toplanır, paralel çalıştırıldığında en uzun olanla sınırlanır.

3. Değişene göre çalıştır

Tek bir paketin değiştiği bir depoda bütün testleri çalıştırmak israf. Çoğu araç zinciri (Nx, Turborepo, Bazel ya da basit bir git diff betiği) etkilenen kısmı belirleyebiliyor.

Dikkat: bu optimizasyon yanlış kurulduğunda sessizce test atlar. Ana dala birleştirmede tam çalıştırma yapmak, bu riski dengeliyor.

4. En hızlı testi öne al

Sıralama şöyle olmalı: biçim/statik analiz (saniyeler) → birim testleri (dakikalar) → entegrasyon testleri → uçtan uca testler.

Bir sözdizimi hatası yüzünden 15 dakikalık uçtan uca test kümesini çalıştırmanın anlamı yok. Erken başarısızlık, hattın en ucuz özelliği.

Kararsız testler (flaky tests)

Kırmızıya alışmanın bir numaralı sebebi. Kararsız bir test, güven veren bir sinyali gürültüye çeviriyor.

İşleyen politika:

1. Kararsız test tespit edildiğinde hemen karantinaya alınır (ana hattan çıkarılır, ayrı çalıştırılır).
2. Bir görev açılır ve bir sahibi olur.
3. Bir hafta içinde düzeltilmezse silinir.

Üçüncü madde tartışma yaratıyor ama gerekli: kimsenin güvenmediği bir test, sıfır değerlidir ve negatif maliyetlidir. Silmek, onu "bir gün bakarız" diye tutmaktan dürüsttür.

Kararsızlığın en yaygın üç kaynağı: gerçek zamana bağımlılık (sleep, tarih), testler arası paylaşılan durum ve sıraya bağımlı testler. Üçü de düzeltilebilir.

Küçük ekip için asgari hat

Üç aşamalı, sade bir yapı çoğu ekip için yeterli:

Aşama 1 — her değişiklikte (hedef: 5 dk)

• Biçim ve statik analiz
• Tip kontrolü
• Birim testleri
• Derleme

Aşama 2 — ana dala birleştirmede (hedef: 15 dk)

• Aşama 1'in tamamı
• Entegrasyon testleri (gerçek veritabanına karşı)
• Veri göçlerinin ileri-geri çalıştığı testi

Aşama 3 — dağıtım sonrası

• Duman testi: uygulama ayakta mı, ana akış çalışıyor mu
• Otomatik geri alma tetikleyicisi

Aşama 3 sıklıkla atlanıyor ama en yüksek getirili olanı: dağıtımdan sonraki iki dakika içinde çalışan basit bir sağlık kontrolü, hataların çoğunu kullanıcıdan önce yakalıyor.

Sırların yönetimi

Küçük ekiplerde CI'ya sır (API anahtarı, veritabanı şifresi) koyma işi genelde aceleyle yapılıyor ve iki hata çıkıyor:

• Aynı sır her ortamda. Üretim anahtarının test hattında bulunması, en yaygın ve en riskli kurulum hatası.
• Çatal (fork) depolardan gelen değişikliklerde sırların açılması. Açık kaynak bir depoda bu, sırların dışarı sızması demek.

Her ikisi de CI aracının ayarlarından kapatılabiliyor; varsayılanlara güvenmeyin, kontrol edin.

Ölçü

Hattınızın iyi olup olmadığını anlamak için tek bir soru yeterli: son bir ayda kaç kez "CI kırmızı ama umursamadım" dediniz?

Sıfırdan büyük her cevap, hattı düzeltmeyi yeni özellik yazmaktan öne alması gereken bir ekibi işaret ediyor.