Monorepo vs Polyrepo: Cara Memilih Setup yang Tepat

Monorepo vs Polyrepo: Cara Memilih Setup yang Tepat untuk Tim Anda

Monorepo versus polyrepo adalah perdebatan yang muncul lagi setiap kali tim engineering Anda berkembang lebih cepat daripada kecepatan build. Jawaban singkatnya: monorepo menang ketika tim berbagi kode secara rutin dan mengoordinasikan perubahan di permukaan bersama; polyrepo menang ketika tim benar-benar independen dan deploy tanpa pernah menunggu satu sama lain. Segala sesuatu di antaranya tergantung pada seberapa erat kode Anda terikat, dan berapa banyak overhead koordinasi yang Anda bersedia serap. Artikel ini membahas trade-off nyata, sinyal yang menunjuk ke satu arah atau lainnya, dan kerangka praktis untuk membuat keputusan.

Yang Benar-Benar Penting: Coupling, Bukan Jumlah Repo

Kebanyakan perdebatan monorepo versus polyrepo dimulai dengan pertanyaan yang salah. Jumlah repo bukan masalahnya. Masalahnya adalah apakah tim Anda perlu bergerak bersama.

Jika perubahan Tim A secara rutin memerlukan Tim B memperbarui sesuatu dalam siklus release yang sama, Anda memiliki pekerjaan yang terikat erat. Satu repo untuk hal itu hampir selalu jawaban yang lebih bersih. Jika Tim A dan Tim B ship pada jadwal mereka sendiri, menyentuh bagian berbeda dari sistem, dan tidak pernah menunggu satu sama lain, repo terpisah masuk akal.

Hasil terburuk yang mungkin: dua repo terpisah untuk kode yang masih perlu deploy bersama. Anda mendapat semua biaya koordinasi polyrepo tanpa manfaatnya. Tim Anda berakhir membuka PR di repo A dan repo B secara bersamaan, berharap keduanya pass CI pada waktu yang sama. Pola ini mengejutkan umum di organisasi yang memilih polyrepo lebih awal dan kemudian membiarkan layanan mereka tumbuh lebih saling bergantung daripada yang direncanakan.

Langkah pertama sebelum memilih apa pun adalah menggambar peta ketergantungan sederhana. Daftar setiap layanan atau paket yang Anda miliki dan tarik panah di mana yang satu bergantung pada yang lain. Jika panah membentuk kluster padat, kluster itu milik satu repo.

Mengapa Google, Meta, dan Microsoft Semua Memilih Monorepos pada Skala Besar

Google menyimpan sebagian besar kodenya dalam satu repositori yang diperkirakan memiliki lebih dari 80 TB data dan 2 miliar baris kode. Meta dan Microsoft melakukan hal yang sama untuk permukaan produk inti mereka. Ini bukan karena perusahaan besar mencintai kompleksitas: ini karena pada skala, menjaga ketergantungan tetap sinkron di ratusan repo menjadi masalah engineering full-time.

Satu perubahan API dalam perpustakaan bersama mungkin memerlukan pembaruan terkoordinasi di 40 repo berbeda. Dalam monorepo, itu adalah satu pull request. Satu review. Satu merge. Satu rollback jika ada yang salah.

Menurut penelitian yang dipublikasikan oleh Sourcegraph, 63% perusahaan dengan 50 atau lebih developer sekarang menggunakan monorepo setidaknya untuk sebagian codebase mereka, meningkat tajam dari angka tiga tahun sebelumnya.

Manfaat konkret yang paling penting: atomic commits. Ketika perubahan breaking dalam API Anda juga memerlukan pembaruan frontend dan backend, monorepo membiarkan Anda landing ketiga perubahan dalam satu PR, test bersama, dan rollback ketiga sebagai unit jika ada yang salah. Dengan polyrepo, Anda membuka tiga PR terpisah, menunggu tiga siklus review terpisah, dan mengelola window di mana layanan Anda menjalankan versi tidak cocok.

Satu tim engineering melaporkan pindah dari deployment sesekali menjadi lebih dari 40 app release per minggu setelah migrasi paket frontend mereka ke monorepo Nx. Upgrade Angular yang sebelumnya memakan waktu berbulan-bulan menjadi tugas rutin yang tim tangani tanpa menghentikan pekerjaan lain.

Biaya Koordinasi Tersembunyi Polyrepo

Polyrepo memiliki keuntungan nyata yang patut diambil serius. Setiap tim mengontrol pipeline CI/CD sendiri, jadwal release sendiri, kontrol akses sendiri. Tim security dan compliance sering lebih menyukainya: akses ke kode dapat dibatasi pada personel named pada basis per-repo, yang penting di industri terregulasi. Komponen open-source hidup lebih bersih di repo publik mereka sendiri tanpa menampilkan kode internal.

Untuk tim yang benar-benar independen, keuntungan ini nyata. Tim layanan kecil yang memiliki data pipeline berjalan pada jadwal sendiri dan tidak menyentuh kode bersama punya sedikit yang bisa didapat dari duduk di dalam monorepo lebih besar.

Namun organisasi polyrepo secara diam-diam mengumpulkan biaya yang tidak muncul dalam keputusan asli. Dependency versioning di seluruh repo menjadi disiplin sendiri. Perpustakaan utility bersama menjadi ketinggalan di beberapa repo sambil tetap current di yang lain. Seseorang harus mempertahankan matriks kompatibilitas hanya untuk tahu versi mana dari library mana yang bekerja dengan versi mana dari layanan mana.

Satu metrik yang patut diketahui: median PR cycle time dalam monorepos sekitar 19 jam, versus sekitar 2 jam dalam polyrepos. PR di monorepos cenderung lebih besar karena mereka menyentuh lebih banyak permukaan, yang memperlambat review. Tapi ketika perubahan polyrepo memerlukan tiga PR terkoordinasi di tiga repo untuk landing satu fitur, waktu cycle agregat sering melampaui angka monorepo, dengan risiko tambahan merge parsial yang meninggalkan layanan dalam keadaan tidak konsisten.

Pola yang mengejutkan tim: "kami mulai dengan repo terpisah untuk independensi, tapi sekarang setiap release memerlukan pembukaan PR di empat tempat." Pada titik itu Anda memiliki yang terburuk dari kedua dunia.

Waktu Build Berhenti Menjadi Faktor Keputusan pada 2024

Keberatan klasik terhadap monorepo adalah waktu build. Jika repo Anda memiliki 200 package dan Anda mengubah satu file, apakah Anda benar-benar ingin rebuild semua 200?

Argumen ini kedaluwarsa sekitar tahun 2022 hingga 2024, tergantung stack Anda.

Alat build modern menggunakan caching yang sadar konten. Mereka hanya rebuild yang berubah, dan skip apa pun dengan input yang identik. Perubahan ke package payments tidak memicu rebuild design-system jika tidak ada yang berubah di design-system. GitHub Actions menyediakan 10 GB free cache storage sebelum Anda perlu solusi cache remote berbayar.

Turborepo menangani sebagian besar tim JavaScript dan TypeScript dengan baik hingga sekitar 20 package. Konfigurasinya adalah single turbo.json, remote caching bekerja di Vercel secara gratis atau self-hosted, dan learning curve cukup rendah sehingga tim dapat produktif dalam sehari.

Melewati 20 package, atau ketika build mencakup multiple language, pendekatan Nx yang lebih terstruktur cenderung mengbenarkan learning curve yang lebih curam. Nx menambahkan code generation, automatic CI distribution, dan fine-grained dependency tracking yang menjadi semakin berharga saat repo tumbuh.

Untuk organisasi besar yang menjalankan ribuan package di seluruh multiple language, Bazel (build system open-source Google) adalah satu-satunya alat yang dirancang untuk skala itu. Biaya setup signifikan dan hampir selalu memerlukan dedicated platform engineering team.

Empat Pertanyaan yang Menyelesaikan Perdebatan untuk Tim Anda

Tidak ada jawaban universal yang tepat, tapi ada kerangka yang dapat diandalkan.

1. Apakah tim Anda berbagi kode yang sering berubah? Jika ya: design system bersama, shared API client library, shared authentication logic. Monorepo hampir selalu pilihan lebih baik. Menjaga perpustakaan bersama tetap sinkron di seluruh multiple repo memerlukan disiplin konstan dan hampir selalu drift.

2. Apakah tim Anda deploy secara independen? Jika layanan Tim A ship pada Selasa dan Tim B ship pada Kamis tanpa koordinasi apa pun diperlukan, polyrepo mendapat tempatnya. Jika merilis satu layanan memerlukan simultaneous release layanan lain, biaya coupling itu milik persamaan.

3. Berapa banyak engineer yang menyentuh codebase ini? Di bawah 20 engineer, struktur repo penting lebih sedikit daripada yang Anda pikir. Di atas 50, biaya koordinasi polyrepo mulai terakumulasi terlihat. Di atas 200, kasus monorepo menjadi sangat kuat kecuali tim benar-benar siloed oleh produk dan teknologi.

4. Apakah Anda memiliki persyaratan security atau compliance yang mengisolasi kode per-tim? Di industri terregulasi: finance, healthcare, beberapa konteks pemerintah. Akses ke kode mungkin perlu dibatasi pada named personnel. Constraint itu dapat menimpas jawaban lain. Jika hard code isolation adalah requirement compliance, polyrepo bukan pilihan, itu constraint.

Jika Anda menjawab "ya" untuk pertanyaan 1 dan "tidak" untuk pertanyaan 4, monorepo hampir pasti jawaban tepat. Jika Anda menjawab "tidak" untuk pertanyaan 1 dan "ya" untuk pertanyaan 2, polyrepo adalah pilihan yang dapat dipertahankan. Segala sesuatu yang lain adalah judgment call.

Apa yang Benar-Benar Dilakukan Tim yang Berkembang

Sangat sedikit organisasi engineering mature beroperasi di salah satu ekstrem. Pola yang paling sering muncul: monorepo untuk produk inti (frontend, shared libraries, backend services yang saling bergantung), dan repo terpisah untuk komponen benar-benar independen.

Pipeline data yang berjalan pada jadwal sendiri dan tidak membagikan kode dengan produk utama milik di luar monorepo. Alat internal yang dipertahankan oleh tim one-person milik di luar. Perpustakaan open-source yang memerlukan public visibility milik di luar.

Ini bukan compromise. Ini adalah jawaban tepat untuk pertanyaan yang jarang punya jawaban binary clean. Simpan hal-hal bersama yang perlu bergerak bersama. Pisahkan apa yang benar-benar independen.

Hal penting adalah membuat keputusan dengan sengaja, bukan secara default. Kebanyakan tim yang berakhir dengan polyrepo sprawl tidak memilihnya: mereka memulai satu layanan, kemudian yang lain, kemudian yang lain, dan tidak pernah berhenti bertanya apakah layanan tersebut perlu hidup bersama.

Peralatan yang Membuat Kedua Pendekatan Benar-Benar Bekerja

Untuk monorepos:

• Nx: strongest feature set, good untuk polyglot builds dan tim melewati 20 package. Higher learning curve tapi scales lebih jauh.

• Turborepo: lebih sederhana untuk start, excellent untuk JS/TS team di bawah 20 package. Native Vercel caching atau opsi self-hosted.

• Bazel: untuk very large multi-language repo pada enterprise scale. Significant setup investment diperlukan.

Untuk polyrepos:

• Disiplin versioning untuk shared libraries bukan optional. Tanpa semantic versioning dan consistent changelog process, dependency drift menjadi norma dalam enam bulan.

• CI/CD tooling yang trigger cross-repo pipelines ketika shared dependency berubah. GitHub Actions support ini via workflow_dispatch dan repository_dispatch events antara repos.

• Dependency registry (npm private registry, GitHub Packages, Artifactory) untuk mengelola shared package distribution.

Keputusan tentang mana yang digunakan masih kembali ke empat pertanyaan itu.