CI yang Butuh 14 Menit per Push, dan Kenapa Aku Akhirnya Berhenti Mengabaikannya

Empat belas menit. Itu rata-rata waktu dari aku ngetik git push sampai badge CI di repo proyek sampingan aku berubah hijau — atau merah. Enggak kelihatan parah di atas kertas, tapi delapan bulan jalan dengan angka itu diam-diam mengubah kebiasaan kerjaku: aku berhenti push kecil-kecil, mulai numpuk tiga-empat commit sebelum sekali push, dan baru buka tab CI lagi 20 menit kemudian sambil ngerjain hal lain. Minggu lalu, satu migration database yang salah lolos review cuma karena aku udah keburu pindah fokus pas CI-nya masih jalan — dan baru ketahuan setelah ter-merge, bukan sebelum.

Empat Belas Menit yang Diam-Diam Mengubah Cara Aku Kerja

Proyek ini monorepo kecil, tiga workspace (api, web, worker) dikelola pakai pnpm, jalan di GitHub Actions tiap push ke branch mana pun. Awalnya 14 menit itu enggak kerasa masalah — aku kerja sendirian, enggak ada orang lain yang nunggu review PR-ku. Tapi begitu mulai nerima kontribusi dari satu kolaborator paruh waktu, pola itu ketahuan jelek: dia push, nunggu 14 menit, lupa buka lagi, dan commit berikutnya numpuk di atas commit yang ternyata gagal test. Rata-rata butuh dua siklus push-tunggu-lupa sebelum satu PR beneran hijau. Enggak ada yang nyadar ini masalah struktural — kita cuma mikir "ya emang gitu CI-nya lambat" dan jalan terus delapan bulan.

Yang Sebenarnya Makan Waktu: Bukan Testnya

Sebelum sok tahu motong apa, aku profiling tiap step di run log GitHub Actions selama seminggu, dicatat durasinya satu-satu. Hasilnya di luar ekspektasi:

• Install dependency (pnpm install): ~5 menit — tiap run download ulang dari registry npm, enggak ada cache sama sekali meskipun pnpm-lock.yaml jarang berubah.
• Build image Docker buat api dan worker: ~6 menit — base image dan layer dependency di-build ulang dari nol tiap kali, padahal isinya sering identik dengan run sebelumnya.
• Jalanin test suite: ~3 menit — ini bagian yang justru paling masuk akal, cuma jalan serial padahal ada 340-an test case yang saling independen.

Jadi dari 14 menit, cuma 3 menit yang beneran "kerja" nge-test logic. Sisanya 11 menit itu kerjaan berulang yang hasilnya hampir selalu sama dengan run sebelumnya — kandidat jelas buat di-cache, bukan di-skip pelan-pelan dengan ngurangin test.

Tiga Perubahan yang Motong 14 Menit ke Bawah Empat

Aku kasih diri sendiri satu hari penuh buat ini, bukan nyicil pelan-pelan di sela kerjaan lain — karena kalau nyicil, biasanya enggak pernah selesai.

1. actions/cache dikunci ke hash pnpm-lock.yaml. Begitu lockfile enggak berubah, step install tinggal restore cache node_modules dari run sebelumnya. Dari ~5 menit jadi di bawah 20 detik di cache-hit.
2. Docker build pakai buildx dengan cache-from/cache-to ke GitHub Container Registry, bukan build dari nol tiap kali. Layer dependency (yang enggak sering berubah) langsung ke-reuse, cuma layer kode aplikasi yang di-build ulang. 6 menit jadi sekitar 90 detik kalau cuma kode yang berubah.
3. Test suite di-split jadi 3 shard paralel pakai flag bawaan test runner (--shard=1/3, --shard=2/3, --shard=3/3), jalan di tiga job GitHub Actions bersamaan bukan satu job serial. 3 menit jadi sekitar 70 detik karena ketiga shard jalan bersamaan, dibatasi sama shard paling lambat doang.

Totalnya: 14 menit jadi 3 menit 40 detik di kondisi cache-hit normal (lockfile dan base image enggak berubah) — bukan kondisi ideal yang cuma kejadian sekali, tapi angka yang konsisten muncul di hampir semua push harian sejak itu.

Bukti Nyata: Bug yang Ketahuan di Menit Keempat, Bukan Setelah Merge

Dua minggu setelah perubahan ini jalan, kolaboratorku push satu migration yang salah urutan kolom — tipe bug yang biasanya baru ketahuan pas staging udah kebagi data rusak. Kali ini CI selesai dalam waktu dia masih di depan laptop nungguin, bukan udah pindah ke tab lain. Dia lihat merah, langsung revert sebelum sempat ke-merge sama siapa pun. Enggak ada insiden, enggak ada rollback database, cuma empat menit nunggu yang beneran ditunggu, bukan ditinggal.

Takeaway

Delapan bulan aku nganggep 14 menit itu "ya emang segitu, CI kan gitu" — enggak pernah diukur, cuma diterima. Begitu beneran di-profiling, ternyata 11 dari 14 menit itu kerjaan berulang yang bisa di-cache, bukan logic yang beneran butuh dihitung ulang tiap kali. Pipeline yang lambat enggak cuma bikin nunggu lama; diam-diam dia ngubah kebiasaan kerja ke arah yang lebih malas — numpuk commit, lupa cek hasil, ninggal tab. Kalau ada proses yang "ya emang gitu" di tim kamu, worth it buat sekali dalam hidup diukur betulan sebelum diterima sebagai takdir.

Sumber gambar: Florian Olivo di Unsplash Sumber gambar: Philipp Katzenberger di Unsplash Sumber gambar: Christopher Gower di Unsplash Sumber gambar: Glenn Carstens-Peters di Unsplash