Elemen Penting untuk Membangun Monorepo yang Produktif

• Mengadopsi monorepo memiliki keunggulan seperti konsistensi organisasi, berbagi kode, dan penguatan lingkungan tooling bersama, tetapi jika meniru mentah-mentah praktik perusahaan big tech, Anda akan menghadapi masalah dan tantangan baru
• Untuk membangun monorepo yang sukses, kita harus memegang prinsip bahwa semua pekerjaan utama harus berkompleksitas O(change), bukan O(repo), dan di setiap tahap build, test, serta CI/CD dibutuhkan alat dan strategi yang sesuai
• Untuk source control, mulai dari Git lalu pertimbangkan ekspansi bertahap seperti sparse checkout dan virtual filesystem seiring skala membesar
• Untuk build system, sebisa mungkin pertahankan satu bahasa saja, bertahan semaksimal mungkin dengan build tool bawaan tiap bahasa, lalu beralih bertahap ke Bazel/Buck2 hanya jika benar-benar diperlukan
• Untuk test·CI/CD, build, test, dan deployment harus dilakukan dengan cepat hanya pada cakupan yang terdampak oleh perubahan, dan pada monorepo skala besar strategi keandalan seperti retry otomatis untuk test dan isolasi flaky test juga wajib

---

Pendahuluan: Awal Perjalanan Menuju Monorepo

• Jika Anda adalah engineer di tim Developer Productivity yang baru, keputusan untuk mengadopsi monorepo akan memunculkan banyak pertanyaan tentang persiapan dan upaya apa saja yang diperlukan
• Praktik terbaik dari perusahaan besar seperti Google, Meta, dan Uber memang terlihat mengesankan, tetapi secara realistis mustahil mencapai hasil pada tingkat yang sama seperti mereka
• Setiap organisasi harus memutuskan adopsi monorepo berdasarkan alasan dan kebutuhannya sendiri, dan dalam proses itu dapat mengejar manfaat seperti konsistensi, integrasi organisasi, dan tooling bersama

Memperjelas Kebutuhan akan Monorepo

• Contoh dari perusahaan besar hanyalah gambaran kondisi akhir yang mereka capai, sehingga kurang tepat dijadikan rujukan untuk tahap awal
• Dalam praktiknya, berbagai masalah baru akan muncul, termasuk jenis isu yang berbeda dari pengelolaan banyak repo yang sudah ada
• Tujuan adopsi monorepo adalah menjaga konsistensi, menyatukan tooling di seluruh organisasi, serta menerapkan standar dan konvensi engineering
• Setiap tim perlu memperjelas tujuan yang sesuai dengan budaya dan arah mereka sendiri agar dapat memperoleh hasil yang efektif

Aturan Emas: Prinsip O(change)

• Semua alat yang terkait dengan repositori harus memiliki kompleksitas O(change), bukan O(repo), agar dapat berjalan cepat
• Pada kenyataannya, semakin besar monorepo, semakin menonjol pula inefisiensi dari alat-alat lama, sehingga desain struktural untuk mengatasi masalah performa menjadi sangat penting
• Inovasi yang sering dibahas di blog teknis perusahaan besar pada umumnya juga berfokus pada upaya mengatasi inefisiensi akibat O(repo)

Source Control

• Sebagian besar organisasi software menggunakan Git sebagai dasar, tetapi Git memiliki batas performa ketika diskalakan besar dalam lingkungan monorepo yang terpusat
  • Secara realistis, kebanyakan organisasi masih bisa bertahan cukup lama dengan git+GitHub
• Semakin cepat pertumbuhan skala, semakin dibutuhkan struktur seperti sparse checkout (partial clone) dan virtual filesystem (mengunduh file secara dinamis dari server saat diperlukan)
• Perusahaan besar menyesuaikan hal ini dengan melakukan fork pada Git atau membangun sistem terpisah (Microsoft: fork Git internal, Meta: fork Mercurial, Google: Piper)
  • Jujutsu dan source control generasi berikutnya lainnya juga layak dipertimbangkan
• Saat skalanya masih kecil, Git bisa digunakan tanpa banyak kendala, tetapi selama proses pertumbuhan perlu memikirkan strategi ekspansi
• Ada juga masalah praktis bahwa jika source code menyertakan kode hasil generate dari IDL (Interface Definition Language), ukuran repositori bisa meningkat secara eksponensial

Build System

• Bazel, Buck2, dan lainnya adalah build tool monorepo yang representatif, mendukung banyak bahasa dan graph build yang kompleks
  • Kuat, tetapi kompleksitas dan beban operasionalnya juga besar
• Jika build dipertahankan dalam satu bahasa, hidup akan jauh lebih mudah, dan build system per bahasa (misalnya Maven, Gradle, Cargo, Go) juga memiliki skalabilitas tinggi
• Peran utama build system adalah “membangun target build yang ditentukan secara efisien (menghasilkan artefak secara efisien)” dan “dengan cepat menghitung target yang terdampak oleh file yang berubah”
• Untuk itu diperlukan konsep target determinator (alat penentu target), dan di ekosistem seperti Rust, Go, dan Bazel sudah tersedia berbagai solusi
  • Rust: guppy
  • Go: go/packages
  • Bazel: target-determinator
• Remote execution dan caching secara praktis baru benar-benar dibutuhkan pada skala yang sangat besar, sedangkan bagi perusahaan umum target determination jauh lebih berguna secara praktis

Test

• Menjalankan seluruh test setiap saat tidak efisien, sehingga dibutuhkan sistem yang hanya menguji cakupan dampak perubahan
• Flaky test dapat menjadi masalah yang lebih serius dalam sistem pengujian berskala besar
• Sistem test perlu memiliki retry otomatis, penentuan cakupan dampak test secara otomatis, dan isolasi flaky test
• Beberapa bahasa (misalnya Rust dengan nextest, Java dengan JUnit, dll.) menyediakan fitur-fitur lanjutan ini secara bawaan atau melalui ekstensi
• Sistem test dalam monorepo harus terintegrasi erat dengan build system agar efektif

Integrasi Berkelanjutan (CI)

• Sistem CI harus secara otomatis menjalankan artefak build dan validasi yang diperlukan sesuai perubahan
• Performa dan efisiensi target determinator menjadi elemen inti dalam pipeline CI
• CI modern menggunakan berbagai strategi seperti “Merge Queue” untuk menyeimbangkan antara menjaga kualitas kode dan mengoptimalkan kecepatan merge
  • Misalnya, apakah semua pekerjaan validasi dijalankan pada setiap commit/PR, hanya sebagian yang dipilih, atau beberapa PR diproses secara batch
• Trade-off antara Throughput, Correctness, dan Tail latency harus didefinisikan dan dirancang sendiri oleh organisasi
• Pengelolaan merge dan peningkatan efisiensi CI pada monorepo besar masih merupakan tantangan yang belum memiliki solusi sempurna
• Rust (bors), Chromium, dan Uber masing-masing memilih strategi merge/validasi yang berbeda

Continuous Deployment (CD)

• Ilusi bahwa semua perubahan dalam monorepo akan ter-deploy secara atomik berbeda dengan kenyataan
• Dalam satu PR, antarmuka dan implementasi banyak service, bahkan kliennya, bisa diubah sekaligus, tetapi deployment nyata pada akhirnya berjalan secara asinkron sehingga masalah bisa muncul pada saat deploy
• Perubahan yang merusak contract antarservice dapat memicu gangguan serius saat deployment
• Strategi CD monorepo yang efektif memerlukan siklus sistem deployment, validasi contract layanan, serta kemampuan mendeteksi dan merespons masalah dengan cepat

Kesimpulan

• Monorepo adalah alat yang kuat untuk memperkuat konsistensi organisasi dan budaya engineering, tetapi memerlukan investasi berkelanjutan pada engineering dan tooling
• Kunci di setiap tahap adalah membangun otomatisasi, alat, dan budaya yang sesuai dengan prinsip O(change)
• Seiring pertumbuhan, tooling juga harus terus berevolusi, dan upaya pengelolaan yang sistematis dengan mencerminkan tujuan serta budaya organisasi menjadi penting
• Jika ada kesiapan, komitmen, dan investasi berkelanjutan yang memadai, monorepo pada akhirnya akan memberikan nilai yang sepadan

[bichi]

Artikel ini benar-benar sangat bermanfaat. Bukan hanya perlu alat yang kuat, kita juga harus siap membuat alat yang dibutuhkan saat diperlukan. Karena itu, kalau semuanya berjalan dengan baik, manfaat yang didapat juga besar.

[cosine20]

Saat kuliah S2, pembimbing saya pernah makan bersama seorang insinyur yang berasal dari Google dan tampaknya mendengar cerita tentang monorepo, lalu mengusulkan agar ke depannya kami juga mengelolanya dengan monorepo. Saya sampai susah payah membujuk beliau agar tidak jadi...

Memang ada banyak kelebihan dari monorepo, tetapi laboratorium kami, karena sifat pekerjaannya, cukup sering harus membagikan hasil kerja kepada orang luar. Kalau kami mengelola hasil kerja dengan monorepo, sepertinya kami akan sangat kesulitan terutama di bagian itu. Kalau multi-repo, kami tinggal mengatur cakupan publikasi untuk tiap hasil kerja.

[youngrok]

Menurut saya, kebanyakan kasus orang menderita saat memakai monorepo biasanya karena proyeknya sejak awal sudah dipecah terlalu kecil. Proyek yang sebenarnya cukup satu atau dua malah dipecah jadi sekitar 10, lalu ketika itu disatukan dan dikelola dengan monorepo, akhirnya harus memakai tool pengelolaan monorepo dan kompleksitasnya pun meningkat. Lebih baik proyeknya sendiri langsung digabung menjadi satu atau dua; kalaupun ada lebih dari dua proyek, akan lebih nyaman kalau tidak memakai tool pengelolaan terpisah dan cukup memikirkannya sebagai menaruh semuanya dalam satu repositori dengan direktori yang dipisah.

[GN⁺]

Opini Hacker News

• Melihat thread ini mengingatkan pada pembahasan lama tentang complexity merchants, jadi ingin berbagi pengalaman. Saya sama sekali tidak setuju dengan pendapat bahwa berpindah ke monorepo berarti ada pengorbanan teknis. Jika memahami kekuatan sistem berkas hierarkis, nilai monorepo akan terlihat jelas. CI/CD juga jauh lebih jelas jika disusun dalam satu monorepo daripada konfigurasi yang tersebar di banyak tempat. Inti monorepo adalah seluruh organisasi bisa membuat commit atomik. Saat harus mengoordinasikan banyak developer, manfaatnya sangat besar. Cukup satu kali rebase dan satu rapat besar. Bahkan jika anggota tim tidak akur dan tidak suka berkolaborasi, dari sisi manajemen monorepo tetap menjadi alat HR yang sangat berguna.

  • Belakangan ini developer cenderung berlebihan dalam pemisahan, microservices, banyak repo kecil, dan sangat menghindari monolit. Ini justru memperbesar kompleksitas dan mengubah masalah struktur organisasi menjadi masalah teknis di masa depan. Mereka juga tidak benar-benar memahami dependensi internal dalam sistem perangkat lunak. Sulit dipercaya berapa banyak waktu yang terbuang di pekerjaan sebelumnya hanya untuk memperbarui file skema protocol buffer. Untungnya, perusahaan saya sekarang tidak seperti itu.

  • Melacak commit di banyak proyek itu hanya sekadar nice-to-have, dan dalam praktiknya tidak terlalu berbeda untuk pelacakan dependensi atau pemicu pengujian downstream. Dengan otomasi multi-repo pun hal itu cukup bisa dilakukan. Monorepo memang membantu, tetapi tidak sempurna dan biayanya juga besar. Deployment atau build tidak diproses secara atomik. Saat skala monorepo membesar, Anda keluar dari git dan membutuhkan tool baru, dan itu pekerjaan yang sangat besar. Ini bukan hal yang mudah dibicarakan jika belum pernah mengalaminya.

  • Keuntungan monorepo memang jelas ada, tetapi biaya pengelolaannya lebih mahal daripada polyrepo. Tidak berarti dalam situasi apa pun monorepo selalu lebih baik. Untuk penjelasan rinci, lihat tulisan ini. Efektivitas dibanding biayanya bergantung pada situasi.

  • Ada aturan praktis yang berguna dalam merancang lingkungan pemrograman: makin banyak kekuasaan yang diberikan ke tim, makin banyak pula masalah yang muncul. Secara teknis commit atomik bukan kekuatan yang lebih besar, malah lebih kecil, tetapi karena memungkinkan orang bekerja dengan interface yang buruk, ia justru menjadi jenis kekuatan yang memicu masalah.

  • Ada pendapat bahwa keyakinan "perubahan jadi lebih atomik" setelah beralih ke monorepo adalah jebakan. [Kutipan asli: ilusi terbesar monorepo adalah bahwa commit atomik dimungkinkan di seluruh codebase. Kenyataannya ada beragam artefak deployment, dan meskipun layanan dan klien diubah sekaligus, deployment tetap terjadi secara asinkron. Di beberapa repo, pekerjaan harus dilakukan lewat beberapa PR sehingga kesadaran akan risikonya lebih terasa. CI di monorepo terutama berfungsi memverifikasi kontrak layanan (CI job), dan bila perlu kita harus menjelaskan alasan perubahan.]

• Ada dua jenis monorepo di big tech. Pertama adalah satu monorepo tingkat perusahaan seperti "THE" monorepo yang dibahas dalam artikel, yang membutuhkan VCS/CI kustom dan didukung 200 engineer. Google, Meta, dan Uber memakai pendekatan ini. Rasa sakit untuk mencapai level itu jauh melampaui imajinasi, dan biasanya dimulai dari monorepo yang lebih kecil di tingkat tim lalu berkembang bertahap. Tiap stack/bahasa/tim mengelola sendiri dengan tool seperti Bazel, Turborepo, atau Poetry, lalu seiring waktu digabung menjadi monorepo yang lebih besar. Namun keduanya sama-sama menuntut investasi jutaan dolar dan jutaan jam, baik dari sisi developer maupun bisnis, dan pada akhirnya dipertahankan oleh dukungan para developer yang telah melewati proses tersebut.

  • Saat bekerja di perusahaan dengan monorepo besar, saya jauh lebih menyukai monorepo. Satu monorepo sangat membantu untuk memahami keseluruhan dengan transparan, seperti service graph dan struktur pemanggilan kode. Di polyrepo, pengetahuan tersebar per tim, pengambilalihan kode baru pun sulit, dan memahami arsip kode terasa seperti menjelajahi labirin. Polyrepo terasa seperti pesan Discord/Slack lama yang terlupakan. Jika monorepo mahal, polyrepo juga mahal dengan cara yang berbeda. Monorepo itu seperti herbivora raksasa di sebuah benua; polyrepo seperti beragam spesies yang tenggelam dalam kegelapan.

  • Di perusahaan saya saat ini, backend terbagi ke sekitar 11 repo git, dan satu fitur memerlukan 4~5 merge request sehingga sangat merepotkan. Kami sedang mempertimbangkan monorepo untuk menyatukan beberapa proyek. Tapi jika repo tidak bisa digabung, apa alternatif monorepo yang ada?

  • Sampai sekarang belum ada sistem orkestrasi monorepo yang mudah dan kuat tanpa bergantung pada bahasa. Bazel kompleks dan sulit dipelajari, tetapi dokumentasinya belakangan banyak membaik. Ada opsi lain seperti Buck, NX, Pants, dan sebagainya, tetapi masing-masing punya karakteristik, dan dukungan web khususnya terbatas. Sebagian besar CI juga tidak benar-benar mendukung tool seperti ini, sehingga konfigurasi jadi rumit. Sebagai referensi, Rush dari Microsoft memberi pengalaman terbaik, khususnya untuk monorepo frontend/NodeJS; saya merekomendasikan Rush situs resmi Rush.

  • Kebanyakan monorepo pada kenyataannya tidak tumbuh sampai skala perusahaan seperti Google, Uber, atau Meta. Jumlah layanan juga berbeda di tiap perusahaan, dan bahkan jika ada sekitar 100 layanan, masalah skala VCS biasanya tidak muncul dan tag LSP pun tetap berjalan baik di laptop. Bahkan menjalankan semua pengujian secara mentah di CI biasanya masih aman. Kesimpulannya: tidak semua perusahaan membutuhkan skala seperti Google.

  • Perusahaan saya saat ini membangun monorepo per stack bahasa. Ini kompromi yang cukup bagus.

• Poin yang jarang muncul dalam diskusi monorepo vs multi-repo adalah munculnya 'hukum Conway terbalik'. Struktur repo memengaruhi struktur organisasi dan cara menyelesaikan masalah. Monorepo mendorong pekerjaan heroik dari tim infrastruktur bersama, dan saat menyentuh area umum ada lebih banyak potensi kerusakan, sehingga mengembangkan satu fitur pun jadi lebih sulit. Di multi-repo, memang dibutuhkan beberapa PR antar tim, koordinasi, dan politik internal, tetapi lebih banyak developer bisa berbagi peran untuk menanganinya.

  • Bahkan di monorepo, jika perubahannya bersifat sentral dan sangat terhubung, penerapannya bisa dibagi dalam beberapa tahap. Dalam proses itu tetap harus menghadapi beberapa PR, koordinasi, dan isu politis, tetapi justru karena monorepo, situasi rollout bisa terlihat lebih jelas.

  • Di polyrepo, perubahan di area umum sering kali tidak diterapkan ke repo downstream, sehingga tiap repo terkunci pada versi berbeda dan akhirnya menderita karena bertahun-tahun tidak diperbarui. Kasus seperti ini jauh lebih umum.

  • Ada pertanyaan apakah asumsi bahwa organisasi sejak awal memilih arah lewat struktur repo lalu pilihan teknis menyusul itu benar. Dalam praktiknya, yang lebih dulu ada adalah filosofi organisasi yang lebih mendasar daripada struktur repo itu sendiri, seperti fragmentasi vs berbagi. Bahkan jika arahnya berubah, cara pengelolaan kode masih bisa diubah. Meski multi-repo, engineer bisa tetap mendapat akses ke hampir semua kode, dan monorepo pun bisa menerapkan isolasi yang kuat serta aturan CI atau deployment yang terpisah.

  • Di monorepo, perubahan antarpoyek yang mudah dilakukan justru jauh lebih sering benar-benar dicoba, sedangkan di polyrepo perubahan seperti itu sering kali terlalu merepotkan sampai orang tidak jadi mencobanya sama sekali.

• Dari pengalaman di perusahaan teknologi besar, pengelolaan build system memang membutuhkan tim khusus. Monorepo besar berbasis virtual file system yang mengunduh source file saat diperlukan. Hal yang tidak disebut dalam artikel adalah bahwa hampir semua pengembangan dilakukan di development server yang berjalan di data center, memakai lingkungan 50~100 core atau container on-demand yang terus diperbarui ke commit terbaru. IDE terintegrasi dengan dev server, dan persiapan awal/konfigurasi otomatis per bahasa atau layanan juga diotomatisasi dengan chef/ansible. Sangat jarang orang mengembangkan monorepo skala besar langsung di laptop sendiri, kecuali untuk kasus seperti mobile/Mac app.

  • Mungkin pernah bekerja di tim build yang sama. Baik lingkungan pengembangan monorepo itu lokal maupun remote, reproducibility lebih penting. Jika memakai remote dev server yang bisa di-image, semuanya jadi lebih mudah dan lebih dapat dipercaya.

  • Ada juga pengalaman memakai lingkungan pengembangan data center di tim yang lebih kecil. Dengan harga dan kepadatan hardware saat ini, membangun rack sendiri untuk menjalankan tool on-demand seperti dev/staging/test justru jauh lebih masuk akal. Jika Anda berbagi lingkungan pengembangan yang mirip produksi, pendekatan monorepo akan terasa sangat berbeda. Namun perusahaan kecil-menengah tidak punya ruang untuk berinvestasi pada build system, dan masalah build system sebesar itu sendiri biasanya memang tidak muncul. Bahkan pada skala minimal 10~20 orang dengan produk yang sangat kompleks sekalipun, pemeliharaannya bisa jadi hanya kerja paruh waktu.

• Ada cerita dari tim kecil di Molnett (serverless cloud) yang mengalami efisiensi luar biasa dengan monorepo berbasis Bazel. Timnya kecil, hanya 1,5 orang full-time. Dengan Tilt+Bazel+Kind, seluruh platform termasuk operator Kubernetes bisa dijalankan di laptop, mendukung Mac/Linux. Mereka juga bisa memverifikasi OS berbasis Bottlerocket dan Firecracker secara lokal. Dengan membangun tool layer, semua developer memakai versi go/kubectl yang sama tanpa perlu instalasi lokal. Memang butuh usaha untuk mengelolanya, tetapi ini dimungkinkan karena ada mantan anggota Google SRE. Ke depan mereka hanya ingin bekerja dengan cara seperti ini. (Bahasa utama: Golang, Bash, Rust)

  • Kalau hanya tim kecil 1,5 orang, repo tunggal memang sudah sewajarnya. Pengalaman saya dengan Bazel sangat buruk, tetapi untuk proyek skala besar mungkin tetap layak dipakai. Untuk skala kurang dari 2 orang, Kind+Tilt saja justru sudah cukup. Tool layer pun untuk Go sebagian sudah ditangani oleh go.mod. kubectl juga bisa dibuat serupa. Tingkat gaji ex-Googler juga perlu dipertimbangkan. Semoga biaya pemeliharaan Bazel tetap sepadan ke depannya.

  • Di perusahaan kami, deployment dilakukan dengan layanan berbasis systemd dan ansible playbooks, lalu tmuxinator otomatis menjalankan semua layanan backend/DB/search engine/frontend sekaligus dalam mode dev. Dari root cukup satu perintah tmuxinator dan seluruh lingkungan dev langsung siap. Monorepo tunggal jauh lebih nyaman dibanding sebelumnya.

  • Situasinya mirip, dan saya juga mengalami efek maksimal dari adopsi Bazel. Berkat tool layer, lingkungan pengembangan bisa dijaga tetap konsisten. Tetapi harus menjalankan bazel run secara langsung, jadi saya penasaran apakah ada cara otomasi yang lebih baik. Tolong jelaskan bagaimana itu bekerja.

  • Untuk tim berukuran 2 orang, pola microservices/K8s itu sendiri sudah overengineering. Pada skala sekecil ini, cara apa pun sebenarnya tidak masalah. Dulu Dropbox/SVN/MS VCS dan apa pun juga tetap bisa dipakai—memang ada ketidaknyamanan, tapi bukan masalah besar. Pada ukuran ini, semua orang masih bisa memetakan seluruh proses di kepala mereka. Pengalaman saya menunjukkan bahwa tool atau infrastruktur yang rumit bukan faktor penentu keberhasilan.

• Ada freelancer yang membagikan pengalaman telah tiga kali menyiapkan monorepo di beberapa perusahaan selama 4 tahun terakhir. Karena terbatas pada frontend, ia hanya memakai ekosistem JavaScript/TypeScript sehingga pengelolaannya relatif lebih mudah. Monorepo yang baik pada praktiknya bekerja seperti polyrepo secara internal: tiap proyek bisa dikembangkan, dideploy, dan di-host secara mandiri, tetapi hidup bersama dalam satu codebase, komponen bersama seperti UI pun dapat dibagikan dengan bebas, dan tampilan serta nuansanya tetap konsisten. Sebagai panduan praktis, ia merekomendasikan referensi ini.

  • Ini sebenarnya bukan polyrepo, melainkan contoh monorepo yang dibangun dengan benar.

• Pada akhirnya, semuanya bergantung pada konteks. Di perusahaan kami ada sekitar 40 repo git yang dikelola dengan CI terpisah, lalu setelah build/test/packaging dibuat image file system terintegrasi untuk integration test. Komponen berkomunikasi lewat pesan Flatbuffers dan flatbuffers juga dikelola sebagai submodule. Menangani dependensi downstream memang sulit, tetapi ada fleksibilitas tertentu berkat progressive enhancement. Dalam kasus seperti ini pun sulit menilai apakah ini multi-repo atau monorepo dengan banyak submodule. Belum jelas apakah berpindah ke monorepo akan membawa keuntungan. Pada akhirnya ini soal trade-off dan memilih jenis ketidaknyamanan yang ingin ditanggung.

• Penulis blog tentang tool monorepo membagikan pengalamannya. Orang-orang sering hanya menekankan keuntungan monorepo, tetapi dalam kenyataannya kompleksitas untuk menjalankan monorepo yang sukses sebagian besar ditanggung diam-diam oleh tim devops/devtools. Karena itu adopsinya harus hati-hati, tetapi bila dibangun dengan baik nilainya tetap sangat besar.

• Pengalaman dengan monorepo yang dikelola dengan baik begitu menyenangkan sampai saya tidak ingin kembali ke workflow lain. Tetapi pendekatan setengah matang seperti "ayo kita pakai monorepo juga" adalah mimpi buruk. Jika ada yang menjual paket lingkungan dan tool monorepo yang benar-benar siap, menurut saya peluang bisnisnya akan besar.

  • NX memang sudah menjalankan bisnis seperti itu. Di startup sebelumnya, kami mengembangkan dari awal dengan NX dan dengan tim R&D 15 orang pun bisa mewujudkan standardisasi setara organisasi 100 orang. Di perusahaan baru saya sekarang (yang mengakuisisi startup itu), percobaan "kita juga pakai monorepo" tanpa rencana berakhir sebagai bencana. Sekarang sedang dimigrasikan ke NX, dan hasilnya sangat bagus.

• Dari pengalaman di organisasi besar, monorepo justru bisa sangat membatasi dependensi antar tim sehingga menurunkan reuse kode. Jika tim library ingin mengubah sesuatu, semua pengguna downstream harus diperbarui, dan perubahan itu jadi rumit karena ada tim yang memakainya dengan cara tak terduga (Hyrum's Law). Pada akhirnya, perusahaan besar sering berujung pada copy-paste internal, fork, kontrol akses yang ketat, dan persetujuan perubahan yang lambat.

  • Saat membuat library yang akan dipakai secara umum, desain API harus dipikirkan hati-hati. Sebisa mungkin API jangan diubah; jika harus, rencanakan perubahan besar dengan matang atau ganti dengan fungsi baru sambil menandai versi lama sebagai deprecated. Untuk kode kecil, copy-paste pun tidak masalah.

  • Meski begitu, kelebihan monorepo tetap ada: semua lokasi penggunaan bisa ditemukan dengan mudah, dan bila perlu perubahan/perbaikan bisa dilakukan secara atomik.

  • Semua perangkat lunak tetap harus mempertimbangkan relasi dependensi, dan monorepo justru memberi wewenang lebih besar baik ke library maupun penggunanya untuk saling mengubah.

  • Di monorepo, perubahan sesuai kebutuhan sendiri jauh lebih mudah, sehingga kemungkinan reuse kode lebih tinggi daripada di polyrepo.