Skip to main content

> ci/cd_güvenilirliği:_kararsız_(flaky)_testleri_karantinaya_alma_modelleri_ve_boru_hattı_güvenini_yeniden_kazanma

CI/CD Güvenilirliği: Kararsız (Flaky) Testleri Karantinaya Alma Modelleri ve Boru Hattı Güvenini Yeniden Kazanma

Bazen geçip bazen patlayan kararsız (flaky) testler yazılım çıkış hızını neden yok eder ve canlıya gerçek hataların kaçmasına yol açar; otomatik karantinaya alma boru hattı güvenini nasıl geri kazanır?

Senior (L5)

⚡ÖZET VE TEKNİK CEVAP

Bir test hiçbir kod değişikliği olmamasına rağmen aynı commit üzerinde bazen geçip bazen kalıyorsa buna 'Kararsız / Güvenilmez Test' (Flaky Test) denir (yarış durumları, asenkron zamanlama hataları veya veritabanı kirliliğinden kaynaklanır). Zayıf takımlarda mühendisler bunu normal bir durum sanır: PR derlemesi patladığında mühendis hiç loglara bakmadan 'Yeniden Çalıştır' butonuna 4 kez basar, tesadüfen yeşil yandığı anda kodu canlıya birleştirir. Bu durum CI/CD'de Kırık Cam Sendromu yaratır: Mühendisler testlere olan tüm inancını kaybeder. Canlıyı çökertecek gerçek bir hata testi patlattığında bile 'Yine kararsız testlerden biridir' diyerek tekrar çalıştırıp bozuk kodu canlıya salarlar. Elit mühendislik takımları Otomatik Test Karantina Yönetişimi uygular:
1
Sıfır Tolerans Kuralı: Bir test alakasız PR'larda 2'den fazla kez patlarsa bir bot testi derhal Karantina Paketine (@quarantined) taşır.
2
Temiz ve Hızlı Boru Hattı: Ana CI hattı temiz kalır ve geliştirme kilitlenmez.
3
Otomatik P1 Düzeltme Bileti: Sahip takıma testi 7 gün içinde tamir etmesi veya silmesi için acil bir görev açılır.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma
Kararsız test karantina otomasyonu algoritmik hata tespit sistemleriyle işler:
1
Kararsızlık Tespit Analizi: Datadog CI Visibility veya BuildPulse aracı testlerin geçmişini tarayarak kod değişmeden patlama oranını ölçer.
2
Otomatik Karantina PR'ı: Kararsızlık oranı %5'i aştığında bot testin başına otomatik olarak @quarantined etiketini ekleyen bir PR açıp main dalına birleştirir.
3
İzole Karantina Çalışması: Karantinadaki testler arka planda ayrı bir bloklamayan hatta çalışır; hata verse bile geliştiricinin PR'ını durdurmaz.
4
7 Günlük Tamir Süresi: Ekip 7 gün içinde testin kök nedenini (koddaki sleep(5) beklemelerini düzeltip dinamik yoklamaya geçerek) çözmek veya testi kalıcı olarak silmek zorundadır.

🎯2. Doğru Kullanım Senaryosu

Kapsam
Büyük uçtan uca (E2E) tarayıcı test paketleri, karmaşık mikroservis entegrasyon testleri, mobil UI testleri ve büyük ölçekli CI/CD boru hattı optimizasyonları.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk
  • ✓
    50 tane kararsız testin ana CI hattında kalmasına izin verip PR'ların %80'inin rastgele patlamasına yol açmak ve mühendislerin günde 2 saatini 'Yeniden Çalıştır' butonuna basmakla harcaması
  • ✓
    gerçek bir hatayı yakalayan bir testi incelemeden karantinaya alıp canlıyı patlatmak

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler
  • ✓
    Mühendislerin GitHub Actions'ta derlemeyi 3 kez yeniden başlatmayı alışkanlık haline getirmesi
  • ✓
    bir PR'ın ancak 3. denemede yeşil yanabilmesi
  • ✓
    yazılımcıların 'O testin kalmasını boşver, hep patlıyor zaten' demesi

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler
  • ✓
    Otomatik kararsız test tespit araçları (BuildPulse) kurun
  • ✓
    kararsız testleri tespit edildikten sonra 1 saat içinde bloklamayan karantina paketine taşıyın
  • ✓
    karantinadaki testlerin 7 gün içinde düzeltilmesi veya silinmesini zorunlu kılın

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim
Otomatik karantinaya alma CI/CD boru hattına olan %100 güveni geri kazandırır ve boşa giden saatleri kurtarır; ancak karantinaya alınan testlerin unutulmaması ve hızla tamir edilmesi için sıkı bir mühendislik disiplini gerektirir.
📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ
Bir SaaS şirketinin 450 testlik uçtan uca Cypress test paketi vardı. 18 test asenkron animasyonlar ve harici Stripe API gecikmeleri yüzünden kararsızdı. Sonuç olarak açılan PR'ların %65'i rastgele patlıyor ve mühendisler haftada toplam 40 saati testleri tekrar çalıştırmakla harcıyordu. Daha da kötüsü, geliştirici testin yine sebepsiz patladığını sanıp onayladığı için canlıya kritik bir kimlik doğrulama hatası kaçtı. Yazılım Direktörü BuildPulse'ı devreye aldı:
1
18 kararsız test anında karantinaya taşındı ve ana hattın başarı oranı %99,4'e çıktı,
2
PR çıkış süresi 4 saatten 12 dakikaya indi, ve
3
Frontend takımı 18 testi düzgün Cypress kontrolleriyle baştan yazdı. 5 günde tüm testler temizlendi ve CI sistemine olan güven %100 yeniden sağlandı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Sürekli Entegrasyonda (CI/CD) 'Kararsız / Güvenilmez Test' (Flaky Test) nedir?

Kaynak kodda veya test mantığında hiçbir değişiklik olmamasına rağmen, aynı commit üzerinde deterministik olmayan bir şekilde bazen geçen bazen patlayan güvenilmez testtir.
Q2

Kararsız testleri yönetmede 'Karantina Modeli' (Quarantine Pattern) nedir?

Tespit edilen kararsız testleri geliştiriciyi bloklayan ana CI hattından çıkarıp izole ve bloklamayan ayrı bir karantina paketine taşımak; böylece ana boru hattını temiz tutarken takıma acil bir tamir görevi açmaktır.

CI/CD Güvenilirliği: Kararsız (Flaky) Testleri Karantinaya Alma Modelleri ve Boru Hattı Güvenini Yeniden Kazanma — Sıkça Sorulan Sorular

Patlayan CI derlemelerinde 'Yeniden Çalıştır' butonuna basmak neden tehlikeli bir mühendislik alışkanlığıdır?

Çünkü mühendislere test hatalarını görmezden gelmeyi öğretir; canlıyı çökertecek gerçek bir hata çıktığında bile yazılımcı testi tekrar tekrar çalıştırarak bozuk kodu canlıya kaçırır.

Web uygulamalarındaki kararsız testlerin en yaygın teknik kök nedeni nedir?

Dinamik asenkron arayüz güncellemelerini beklemek için deterministik kontroller (`waitForElement()`) yerine koda gömülmüş rastgele bekleme süreleri (`sleep(3000)`) kullanılmasıdır.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸
    Kararsız testler CI güvenini yok eder ve gerçek yazılım hatalarının gözden kaçmasına yol açar.
  • ▸
    Sıfır tolerans uygulayın: Kararsız testleri otomatik olarak Karantina paketine taşıyın.
  • ▸
    Karantinaya alınan testler geliştiricinin PR derlemesini ASLA durdurmamalıdır.
  • ▸
    Sahip takımın testi 7 gün içinde düzeltmesi veya silmesi için katı bir süre sınırı koyun.

Yaygın Yanılgılar

  • ✗
    Yanılgı: Tüm testlere otomatik 3 kez tekrar deneme (retry: 3) koymak kararsızlığı çözer (Gerçek: Tekrarlar yarış durumlarını maskeler, derlemeyi uzatır ve canlı hatalarını gizler).
  • ✗
    Yanılgı: Büyük yazılım projelerinde kararsız testlerin olması kaçınılmazdır (Gerçek: Kararsızlık test mimarisindeki ciddi bir hatadır; elit ekiplerde bu oran %0,1'in altındadır).

Karar Kılavuzu & Önceliklendirme

CI/CD boru hattına olan güveni %100 yeniden kazanmak için deterministik olmayan testleri anında izole eden otomatik tespit ve karantinaya alma araçlarını kurun.

Doğrulanmış Kaynaklar & Referanslar