Kenapa 14 repo jadi masalah

Ketika sebuah produk tumbuh, repositori sering ikut beranak-pinak: satu untuk frontend, satu untuk API, satu untuk layanan pembayaran, dan seterusnya. Mulanya rapi. Lama-lama, 14 codebase terpisah berarti 14 cara berbeda mengatur dependensi, 14 pipeline, dan perubahan kecil yang merembet lewat banyak repo sekaligus.

Yang paling menyakitkan adalah perubahan lintas-layanan: memperbarui satu kontrak API berarti membuka belasan pull request di repo berbeda, menjaga semuanya tetap sinkron, dan berdoa tidak ada yang tertinggal. Konsistensi jadi pekerjaan manual yang melelahkan.

Inti masalah

Bukan kodenya yang buruk, tapi batas-batasnya. Terlalu banyak repo membuat perubahan yang seharusnya satu langkah menjadi belasan langkah yang rawan tidak sinkron.

Kenapa monorepo

Monorepo — satu repositori yang menampung banyak proyek/layanan — menyelesaikan justru masalah batas itu. Satu perubahan lintas-layanan bisa dilakukan dalam satu commit yang konsisten. Dependensi bersama dikelola di satu tempat. Dan tim melihat keseluruhan sistem, bukan potongan-potongan terpisah.

Ini bukan soal "monorepo selalu lebih baik" — keduanya punya tempat. Tapi untuk sistem dengan banyak bagian yang saling bergantung erat, monorepo mengembalikan kewarasan. Pendekatan engineering serius semacam ini yang kami bawa ke jasa pembuatan software kami.

Strategi tanpa downtime

Kunci migrasi ini: layanan tidak boleh berhenti sedetik pun. Garis besar yang kami tempuh:

  • Pertahankan riwayat. Setiap repo dipindahkan dengan menjaga histori commit-nya, bukan sekadar menyalin file.
  • Migrasi bertahap, bukan big bang. Satu layanan dipindahkan dan diverifikasi sebelum lanjut ke berikutnya.
  • Jalankan paralel sementara. Sistem lama dan baru berjalan berdampingan hingga yang baru terbukti stabil.
  • Pipeline lebih dulu. Build dan deploy di monorepo disiapkan dan diuji sebelum trafik nyata dialihkan.
  • Bisa mundur kapan saja. Setiap langkah punya jalan kembali jika ada yang tidak beres.

Jebakan yang kami temui

  • Waktu build membengkak. Tanpa pengaturan, satu perubahan kecil bisa memicu build seluruh repo. Solusinya: build hanya yang terdampak.
  • Dependensi yang bentrok. Versi paket yang berbeda antar-proyek harus diselaraskan dengan hati-hati.
  • Hak akses & struktur. Satu repo besar butuh konvensi folder dan aturan yang jelas agar tidak kembali berantakan.

Pelajaran

Migrasi besar bukan soal keberanian satu malam, tapi disiplin langkah kecil yang bisa diverifikasi dan dibatalkan. Yang membuat migrasi ini berhasil tanpa downtime bukan satu trik ajaib, melainkan kesabaran: pindahkan satu, pastikan, lanjut. Filosofi yang sama kami pakai saat membangun dan merawat sistem klien kami — perubahan besar dilakukan dengan langkah yang aman.