GitHub, aynı kod için bazı durumlarda derlemenin bozulup bazı durumlarda geçtiği derlemeleri flaky build olarak tanımlıyor; bu tür sorunların ilgili kodu yazan kişi tarafından çözülmesi ve başkalarını etkilememesi için otomasyon devreye alınarak flaky build oranının 18'de 1'e indirildiğini söylüyor.
GitHub, kurum içi CI sisteminde flaky build'leri takip ediyor, sorunlu durumları derliyor ve bu soruna neden olmuş olabileceği düşünülen kişiye atıyor.
-
Flaky build'leri takip ettiklerinde sıklıklarının farklı olduğunu gördüler; 100 kereden fazla başarısız olan flaky build'ler toplamın %0,4'ünü oluşturuyordu. Bu yüzden bu %0,4'lük kısma odaklanmaya karar verdiler.
-
2016'da bunu devreye aldıklarında şu iki yöntemle yaklaştılar.
-
Derleme bittiğinde, aynı commit ile çalıştırılan derlemeleri bulup sonuçlar farklıysa bunu flaky build olarak işaretleme
-
Aynı derlemede yeniden deneme yapıldığında sonuç farklıysa flaky build olarak işaretleme
-
-
Bu yöntemle tüm flaky build'lerin yalnızca %25'ini ayırt edebildiler.
İyileştirme
-
3 kez yeniden çalıştırma yöntemi kullanıldı
-
Aynı süreç içinde yeniden denenir. Bu tür flaky build'ler koddaki rastlantısallık veya race condition nedeniyle ortaya çıkar.
-
Aynı süreçte ama zaman geçtikten sonra yeniden denenir. Bu tür flaky build'ler, zamanla ilgili yanlış varsayımlar yapıldığında ortaya çıkar.
-
Tamamen farklı bir host üzerinde yeniden denenir. Bu tür flaky build'ler, test sırası bağımlılığı veya paylaşılan durum nedeniyle ortaya çıkar.
-
Bu yöntem sayesinde %90'ını otomatik olarak tespit edebilir hale geldiler.
Etkinin ölçülmesi
Öncelik belirlemek için etkiyi nicel olarak ölçmenin bir yoluna ihtiyaçları vardı.
Derleme, branch, yazar ve commit gibi bilgileri kullanarak ne kadar sık başarısız olduğu ve diğer branch'leri ya da geliştiricileri ne kadar etkilediği üzerinden bir etki puanı veriliyor.
Belirli bir puanın üzerine çıkarsa, geliştiricilerin düzeltebilmesi için bir issue oluşturulup ilgili geliştiriciye atanıyor.
1 yorum
Benim durumumda gradle'ın unittest aşamasında flaky build'e sık sık rastlandığı için aşağıdaki çözümleri uygulamıştım.
https://plugins.gradle.org/plugin/org.gradle.test-retry eklentisini kullanırsanız, unittest için flaky build'i takip etmede çok yardımcı olur.
https://docs.gradle.org/current/dsl/… kullanırsanız, belirli bir süreden sonra yeni bir process'te çalıştırıldığı için flaky build hafifleyebilir.
gradle enterprise'ı devreye alırsanız flaky build'in eğilimini kolayca görebilirsiniz. https://gradle.com/blog/flaky-tests/