Merusak build: apa itu, penyebab dan cara menghindari dalam proyek

Apa itu merusak build dalam pengembangan

Merusak build adalah situasi ketika setelah melakukan perubahan, proyek berhenti dibangun. Dalam konteks CI/CD, ini berarti pipeline kompilasi berakhir dengan kesalahan dan artefak tidak dibuat.

Dalam dunia pengembangan mobile dan web, build adalah proses transformasi kode sumber menjadi file eksekusi atau paket. Untuk Android ini adalah kompilasi APK atau AAB melalui Gradle, untuk iOS — kompilasi melalui Xcode, untuk proyek web — pembangunan melalui Webpack atau Vite. Build dapat rusak pada salah satu dari tahapan ini.

Sistem kontrol versi modern dan alat CI/CD, seperti Jenkins, GitHub Actions dan GitLab CI, secara otomatis mendeteksi build yang rusak dan memberi tahu tim. Di sebagian besar proyek ada aturan: jika build rusak, prioritas semua tugas lainnya diturunkan sampai kompilasi diperbaiki.

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // Baris ini merusak build
    val number: Int = "not a number"
}

Dalam contoh ini, menetapkan string ke variabel bertipe Int menyebabkan kesalahan kompilasi. Type mismatch — salah satu penyebab paling umum build rusak dalam bahasa bertipe statis.

Penyebab utama kerusakan kompilasi

Ada beberapa kategori kesalahan yang menyebabkan build rusak. Menurut analitik GitLab tahun 2024, distribusi penyebabnya adalah sebagai berikut.

Kategori paling berbahaya — masalah dependensi. Pembaruan pustaka di satu modul dapat merusak build di modul tetangga, jika API atau perilaku metode berubah.

Kesalahan sintaks, sebaliknya, terdeteksi dengan cepat — kompiler menunjukkan baris dan jenis kesalahan yang tepat. Oleh karena itu, bahasa bertipe statis dianggap lebih andal dalam konteks stabilitas kompilasi daripada bahasa bertipe dinamis.

Bagaimana build yang rusak memengaruhi tim

Build yang rusak secara langsung memengaruhi produktivitas tim. Ketika kompilasi gagal, pengembang tidak bisa mendapatkan versi proyek saat ini dari repositori, dan pipeline CI diblokir untuk semua perubahan selanjutnya.

Penelitian Atlassian tahun 2023 menunjukkan bahwa proyek di mana build tetap rusak lebih dari empat jam kehilangan rata-rata 25% waktu produktif tim. Pengembang terpaksa mengalihkan perhatian ke diagnosis masalah alih-alih menjalankan tugas mereka.

Selain produktivitas, iklim moral juga menderita. Pengembang yang merusak build merasakan tekanan dari rekan kerja. Di tim yang sehat ada aturan: jangan menghukum karena build rusak, tetapi tuntut perbaikan segera. Blameless culture — pendekatan di mana insiden dianalisis sebagai masalah sistem, bukan kesalahan seseorang.

Di tim terdistribusi, build yang rusak dapat memblokir kerja karyawan di zona waktu lain. Jika pengembang dari Eropa merusak build sebelum pulang, tim dari Asia bisa kehilangan satu hari kerja penuh menunggu perbaikan.

Cara mencegah build yang rusak

Pencegahan build yang rusak dimulai dengan pemeriksaan lokal sebelum commit. Setiap pengembang harus menjalankan tes dan kompilasi sebelum mengirim perubahan. Metode pencegahan utama dibagi menjadi beberapa tingkatan.

• Pre-commit hook — pemeriksaan otomatis sebelum membuat commit, termasuk linter dan formatter
• Kompilasi lokal — menjalankan kompilasi sebelum push, terutama untuk bahasa bertipe statis
• Unit test — menutupi modul kunci dengan tes untuk deteksi dini regresi
• Code review — pemeriksaan perubahan oleh rekan sebelum merge ke cabang utama

Tingkat kedua — konfigurasi pipeline CI/CD. Setiap Pull Request harus melalui kompilasi dan pengujian otomatis sebelum merge. Jika kompilasi gagal, PR diblokir hingga perbaikan. Pendekatan ini disebut gated commit dan digunakan di sebagian besar proyek modern.

Tingkat ketiga — pemantauan dan statistik. Tim melacak metrik waktu pemulihan kompilasi — MTTR (Mean Time To Repair). Semakin rendah indikator ini, semakin cepat tim bereaksi terhadap build yang rusak. Nilai target — tidak lebih dari 30 menit.

Apa yang harus dilakukan jika build rusak

Ketika build rusak, langkah pertama adalah menentukan pengembang mana yang terakhir melakukan perubahan. Git menyediakan alat git bisect yang memungkinkan menemukan commit yang merusak kompilasi melalui pencarian biner.

# Mulai bisect dengan commit baik dan buruk yang diketahui
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Git memeriksa commit di tengah
# Bangun dan uji, lalu tandai:
git bisect good  # if build passes
git bisect bad   # if build fails

# Setelah ~log2(n) langkah, git menunjukkan pelakunya
git bisect reset

Setelah menemukan commit bermasalah, ada dua opsi tindakan. Pertama — mengembalikan perubahan melalui git revert, jika perbaikan memerlukan waktu. Ini adalah pendekatan paling aman, terutama ketika build memblokir seluruh tim.

Opsi kedua — perbaikan segera dengan commit baru. Pendekatan ini lebih disukai jika masalah bersifat lokal dan jelas. Setelah perbaikan, push perubahan dan pastikan build berhasil. Bagaimanapun, waktu pemulihan kompilasi tidak boleh melebihi satu jam.