Di GitHub, build untuk kode yang sama tetapi kadang gagal dan kadang lolos didefinisikan sebagai flaky build. GitHub mengatakan mereka berhasil mengurangi flaky build hingga 1/18 dengan memperkenalkan otomatisasi agar flaky ditangani oleh orang yang menulis kode tersebut dan tidak berdampak pada orang lain.
Di CI internal GitHub, mereka melacak flaky build, merangkum situasi masalahnya, lalu menetapkannya kepada orang yang diperkirakan menyebabkan masalah tersebut.
-
Setelah melacak flaky build, terlihat bahwa frekuensinya berbeda-beda; flaky build yang gagal lebih dari 100 kali hanya mencakup 0,4% dari keseluruhan. Karena itu, mereka memutuskan untuk fokus pada 0,4% ini.
-
Saat pertama kali diperkenalkan pada 2016, mereka mendekatinya dengan dua cara berikut.
-
Setelah build selesai, mereka mencari build yang dijalankan dengan commit yang sama, lalu jika hasilnya berbeda maka ditandai sebagai flaky build
-
Jika build yang sama dicoba ulang tetapi hasilnya berbeda, maka ditandai sebagai flaky build
-
-
Dengan cara ini, mereka hanya bisa membedakan 25% dari seluruh flaky build.
Perbaikan
-
Menggunakan metode menjalankan ulang 3 kali
-
Mencoba ulang di proses yang sama. Flaky build jenis ini terjadi karena unsur kebetulan dalam kode atau race condition.
-
Mencoba ulang di proses yang sama tetapi setelah waktu berlalu. Flaky build jenis ini terjadi ketika ada asumsi yang keliru terkait waktu.
-
Mencoba ulang di host yang benar-benar berbeda. Flaky build jenis ini terjadi karena ketergantungan pada urutan pengujian atau shared state.
-
Dengan metode ini, mereka akhirnya dapat mendeteksi 90% secara otomatis.
Mengukur dampak
Mereka memerlukan cara untuk mengukur dampak secara kuantitatif agar bisa menentukan prioritas.
Dengan memanfaatkan informasi seperti build, branch, penulis, dan commit, mereka memberi skor dampak berdasarkan seberapa sering gagal dan seberapa besar pengaruhnya terhadap branch atau pengembang lain.
Jika melewati skor tertentu, mereka membuat issue agar pengembang dapat memperbaikinya lalu menetapkannya kepada pengembang tersebut.
1 komentar
Dalam kasus saya, flaky build sering ditemukan pada unittest Gradle, jadi saya pernah menerapkan solusi-solusi berikut.
Jika menggunakan plugin https://plugins.gradle.org/plugin/org.gradle.test-retry, ini sangat membantu untuk melacak flaky build pada unittest.
Dengan menggunakan https://docs.gradle.org/current/dsl/…, pengujian akan dijalankan di proses baru setelah periode tertentu, sehingga flaky build bisa berkurang.
Jika menerapkan Gradle Enterprise, Anda bisa dengan mudah melihat tren flaky build. https://gradle.com/blog/flaky-tests/