एक प्रोडक्टिव monorepo बनाने के लिए ज़रूरी तत्व

• Monorepo अपनाने से संगठन में consistency, code sharing, और shared tooling environment को मज़बूती जैसे फायदे मिलते हैं, लेकिन अगर Big Tech के उदाहरणों को ज्यों-का-त्यों अपनाया जाए तो नई समस्याओं और चुनौतियों का सामना करना पड़ता है
• एक सफल monorepo के लिए यह सिद्धांत ज़रूरी है कि सभी प्रमुख काम O(repo) नहीं बल्कि O(change) हों, और build·test·CI/CD के हर चरण में इसके अनुरूप tools और strategies की ज़रूरत होती है
• Source control के लिए Git से शुरुआत की जा सकती है, लेकिन scale बढ़ने पर sparse checkout, virtual filesystem जैसी gradual scaling strategies पर विचार करना चाहिए
• Build system में जहाँ तक संभव हो single language बनाए रखना बेहतर है, हर भाषा के native build tools पर अधिकतम टिके रहें, और केवल वास्तव में ज़रूरी होने पर Bazel/Buck2 जैसे विकल्पों की ओर धीरे-धीरे बढ़ें
• Test·CI/CD में केवल बदलाव से प्रभावित दायरे को जल्दी पहचानकर build·test·deploy करना चाहिए, और बड़े monorepo में automatic test retry, flaky test isolation जैसी reliability strategies भी अनिवार्य हैं

---

परिचय: monorepo की यात्रा की शुरुआत

• अगर आप नई Developer Productivity team के engineer हैं, तो monorepo अपनाने का फ़ैसला होने के बाद किन तैयारियों और प्रयासों की ज़रूरत होगी, इस पर गंभीरता से सोचना पड़ता है
• Google, Meta, Uber जैसी बड़ी कंपनियों की best practices आकर्षक लगती हैं, लेकिन व्यवहारिक रूप से उनके समान स्तर के नतीजे पाना संभव नहीं होता
• हर संगठन को अपने कारणों और ज़रूरतों के आधार पर monorepo अपनाने का निर्णय लेना चाहिए, और इस प्रक्रिया में consistency, organizational integration, shared tooling जैसे लाभों का लक्ष्य रखा जा सकता है

monorepo की ज़रूरत को स्पष्ट करना

• बड़ी कंपनियों के उदाहरण दरअसल अंतिम अवस्था की तस्वीर हैं; शुरुआती चरण में उन्हें सीधे reference के रूप में लेना उपयुक्त नहीं है
• वास्तविकता में नई समस्याएँ सामने आती हैं, और ये मौजूदा multi-repo management से अलग तरह के issues पैदा करती हैं
• monorepo अपनाने का उद्देश्य consistency बनाए रखना, organization-wide tooling integration, engineering standards और conventions को लागू करना है
• प्रभावी परिणाम पाने के लिए हर team को अपनी culture और दिशा के अनुरूप लक्ष्य स्पष्ट करने होंगे

गोल्डन रूल: O(change) का सिद्धांत

• सभी repository-related tools को तेज़ी से काम करने के लिए O(repo) नहीं बल्कि O(change) complexity रखनी चाहिए
• वास्तव में, monorepo जितना बड़ा होता जाता है, मौजूदा tools की inefficiency उतनी स्पष्ट होती जाती है, इसलिए performance समस्याओं से निपटने के लिए structural design अनिवार्य है
• बड़ी कंपनियों के tech blogs में जिन innovations का ज़िक्र मिलता है, वे भी ज़्यादातर O(repo) से पैदा होने वाली inefficiency को दूर करने पर केंद्रित होते हैं

Source control

• अधिकांश software organizations Git को base के रूप में इस्तेमाल करती हैं, लेकिन centralized monorepo environment में बड़े scale पर Git की performance limitations सामने आती हैं
  • व्यवहार में अधिकांश संगठन git+GitHub के साथ काफ़ी लंबे समय तक काम चला सकते हैं
• जैसे-जैसे growth तेज़ होती है, sparse checkout (partial clone) और virtual filesystem (ज़रूरत पड़ने पर server से dynamically files डाउनलोड करना) जैसी संरचनाओं की आवश्यकता बढ़ती है
• बड़ी कंपनियाँ इसके लिए Git को fork करती हैं या अलग systems विकसित करती हैं (Microsoft: custom Git fork, Meta: Mercurial fork, Google: Piper आदि)
  • Jujutsu जैसे next-generation source control पर भी विचार किया जा सकता है
• छोटे scale पर Git को बिना कठिनाई इस्तेमाल किया जा सकता है, लेकिन growth के दौरान scaling strategy को ध्यान में रखना ज़रूरी है
• अगर source code में IDL(Interface Definition Language) से generated code शामिल हो, तो repository size के geometric रूप से बढ़ जाने जैसी व्यावहारिक समस्या भी आती है

Build system

• Bazel, Buck2 आदि monorepo build tools के प्रमुख उदाहरण हैं, जो कई languages और complex build graphs को support करते हैं
  • ये powerful हैं, लेकिन complexity और operational burden भी बड़ा होता है
• अगर build को single language तक रखा जाए तो काम बहुत आसान हो जाता है, और हर language के build systems (जैसे Maven, Gradle, Cargo, Go) भी अच्छी scalability रखते हैं
• Build system की मुख्य भूमिका है “दिए गए build target को efficiently build करना (efficient artifact generation)” और “changed files से प्रभावित targets को तेज़ी से पहचानना”
• इसके लिए target determinator (target determination tool) की अवधारणा ज़रूरी है, और Rust, Go, Bazel जैसी ecosystems में इसके लिए पहले से कई समाधान मौजूद हैं
  • Rust: guppy
  • Go: go/packages
  • Bazel: target-determinator
• Remote execution और caching वास्तव में केवल बहुत बड़े scale पर ही आवश्यक होते हैं; सामान्य कंपनियों में target determination अधिक व्यावहारिक होता है

Test

• हर बार पूरा test suite चलाना inefficient है, इसलिए ऐसा system चाहिए जो केवल बदलाव से प्रभावित दायरे का test करे
• Flaky tests बड़े test systems में और भी गंभीर समस्या बन सकते हैं
• test system में automatic retry, test impact range का automatic determination, और flaky test isolation जैसी सुविधाएँ होनी चाहिए
• कुछ languages (जैसे Rust का nextest, Java का JUnit आदि) ऐसी advanced capabilities को built-in या extension के रूप में उपलब्ध कराती हैं
• monorepo का test framework, build system के साथ क़रीबी integration में होना चाहिए तभी वह प्रभावी बनता है

Continuous Integration (CI)

• CI system को changes के अनुसार ज़रूरी build artifacts और validation अपने-आप चलानी चाहिए
• Target determinator की performance और efficiency, CI pipeline का मुख्य तत्व बन जाती है
• आधुनिक CI “Merge Queue” जैसी strategies का उपयोग करती है ताकि code quality बनाए रखने और merge speed optimize करने के बीच संतुलन रखा जा सके
  • जैसे हर single commit/PR पर सभी validations चलानी हैं या केवल कुछ, या कई PRs को batch में process करना है
• Throughput, Correctness, और Tail latency के बीच के trade-off को संगठन को स्वयं परिभाषित और design करना होगा
• बड़े monorepo में merge management और CI efficiency को मज़बूत करना अब भी ऐसा challenge है जिसका कोई perfect solution नहीं है
• Rust(bors), Chromium, Uber आदि ने अलग-अलग merge/validation strategies चुनी हैं

Continuous Deployment (CD)

• यह भ्रम कि monorepo के भीतर होने वाला हर बदलाव atomically deploy होगा, वास्तविकता से अलग है
• एक PR में कई services के interface, implementation, और clients को एक साथ बदला जा सकता है, लेकिन वास्तविक deployment अंततः asynchronous ढंग से होता है, इसलिए deploy के समय समस्याएँ आ सकती हैं
• services के बीच contract तोड़ने वाले changes deployment के दौरान गंभीर outages पैदा कर सकते हैं
• प्रभावी monorepo CD strategy के लिए deployment system की cadence, service contract validation, और समस्या होने पर तेज़ detection व response capability आवश्यक है

निष्कर्ष

• Monorepo संगठनात्मक consistency और engineering culture को मज़बूत करने का एक शक्तिशाली tool है, लेकिन इसके लिए लगातार engineering और tooling investment की आवश्यकता होती है
• हर चरण में O(change) सिद्धांत के अनुरूप automation, tools, और culture का निर्माण ही कुंजी है
• growth के साथ tools को भी लगातार evolve करना होगा, और organization के goals व culture को दर्शाने वाला systematic management effort महत्वपूर्ण है
• पर्याप्त तैयारी, commitment, और निरंतर investment हो, तो monorepo अंततः उतनी ही बड़ी value पैदा करता है

[bichi]

यह बेहद सारगर्भित लेख है। सिर्फ़ शक्तिशाली tools ही नहीं, ज़रूरत पड़ने पर ज़रूरी tools खुद बनाने की तैयारी भी रखनी चाहिए। इसलिए अगर यह अच्छी तरह चलने लगे, तो मिलने वाले फायदे भी बहुत होते हैं।

[cosine20]

मास्टर्स के दौरान एक बार मेरे गाइड प्रोफेसर Google के एक पूर्व इंजीनियर के साथ खाना खाकर आए थे, और शायद वहीं से monorepo की बात सुनकर उन्होंने भी आगे से monorepo में मैनेज करने का प्रस्ताव रखा था, लेकिन उन्हें समझाकर रोकने में काफ़ी मशक्कत करनी पड़ी थी...
monorepo के कई फ़ायदे ज़रूर हैं, लेकिन हमारी लैब की प्रकृति ऐसी थी कि हमें अपने आउटपुट अक्सर बाहरी लोगों के साथ शेयर करने पड़ते थे, और अगर हम उन्हें monorepo में मैनेज कर रहे होते तो शायद यहीं सबसे ज़्यादा दिक्कत होती। multi-repo में तो बस हर आउटपुट के हिसाब से access range नियंत्रित कर सकते हैं।

[youngrok]

मोनोरेपो करते समय ज़्यादातर परेशानी शायद तब होती है जब प्रोजेक्ट को पहले ही बहुत छोटे-छोटे हिस्सों में बाँट दिया गया हो। जो चीज़ मूल रूप से एक-दो प्रोजेक्ट में हो सकती थी, उसे लगभग 10 हिस्सों में बाँटकर फिर उसे मोनोरेपो में इंटीग्रेट करके मैनेज करना पड़े, तो मोनोरेपो मैनेजमेंट टूल भी इस्तेमाल करने पड़ते हैं और जटिलता भी बढ़ जाती है। बेहतर है कि प्रोजेक्ट को ही एक-दो हिस्सों में समेकित कर दिया जाए, और अगर दो से ज़्यादा प्रोजेक्ट हों भी, तो अलग मैनेजमेंट टूल इस्तेमाल करने के बजाय बस directories अलग रखकर उन्हें एक ही repository में रखने की तरह सोचा जाए, तो कहीं ज़्यादा आराम से मैनेज किया जा सकता है।

[GN⁺]

Hacker News प्रतिक्रिया

• इस थ्रेड को पढ़ते हुए पुराने "complexity merchants" की चर्चा याद आ गई — अनुभव साझा करने का अनुरोध। monorepo में जाने पर तकनीकी बलिदान देना पड़ता है, इस बात से बिल्कुल सहमत नहीं हूँ। अगर आप hierarchical file system की ताकत समझते हैं, तो monorepo की वैल्यू समझ आएगी। CI/CD भी इधर-उधर बिखरी configuration की तुलना में एक monorepo में कहीं अधिक स्पष्ट होता है। monorepo का मूल यह है कि पूरी organization atomic commit कर सकती है। बहुत सारे developers को coordinate करते समय इसका फायदा भारी होता है। एक बार rebase और एक बड़ी meeting काफी होती है। भले ही team members एक-दूसरे को पसंद न करें और सहयोग न भी करें, management के नज़रिए से monorepo एक बड़ा HR tool जैसा काम करता है.

  • हाल के developers में separation, microservices, बहुत सारे छोटे repositories, और monolith से चरम स्तर तक बचने की प्रवृत्ति है। इससे complexity बढ़ती है और organizational structure की समस्याएँ भविष्य की technical problems में बदल जाती हैं। software system की internal dependencies को भी ठीक से पहचाना नहीं जाता। पिछली नौकरी में protocol buffer schema files अपडेट करने में जितना समय बर्बाद हुआ, वह अविश्वसनीय था। शुक्र है, मेरी मौजूदा कंपनी ऐसी नहीं है.

  • कई projects में commits को track करना अच्छा तो है, लेकिन dependency tracking या downstream test trigger के मामले में इससे बहुत बड़ा फर्क नहीं पड़ता। multi-repo automation से भी यह पर्याप्त रूप से किया जा सकता है। monorepo मदद करता है, लेकिन यह पूर्ण समाधान नहीं है, और इसकी लागत भी बड़ी है। deploy या build वास्तव में atomic नहीं होते। monorepo का आकार बढ़ने पर git से आगे बढ़कर नए tools की ज़रूरत पड़ती है, और यह बहुत बड़ा काम है। बिना अनुभव के इस बारे में हल्के में कहना आसान है.

  • monorepo के फायदे निश्चित रूप से हैं, लेकिन इसका management cost polyrepo से अधिक महंगा है। हर स्थिति में monorepo ही सबसे अच्छा हो, ऐसा नहीं है। विस्तार से समझने के लिए यह लेख देखें. cost-benefit हर situation पर निर्भर करता है.

  • programming environment design में एक उपयोगी rule of thumb यह है कि टीम को जितनी अधिक power देंगे, समस्याएँ भी उतनी बढ़ेंगी। तकनीकी रूप से atomic commit ज़्यादा शक्तिशाली power नहीं, बल्कि कम power है, लेकिन यह खराब interfaces के साथ काम करना संभव बनाता है, इसलिए उल्टा समस्याएँ पैदा करने वाली power बन जाती है.

  • monorepo में बदलने पर बदलाव अधिक atomic हो जाते हैं — यह मान्यता एक जाल है। [मूल उद्धरण: monorepo का सबसे बड़ा भ्रम यह है कि पूरे codebase पर atomic commit संभव है। वास्तविकता में विभिन्न deployment artifacts होते हैं, और भले ही services व clients को एक साथ बदला जाए, deployment asynchronous होता है। कई repos में काम करने पर कई PRs की ज़रूरत पड़ती है, इसलिए जोखिम की समझ स्वाभाविक रूप से बनी रहती है। monorepo का CI मुख्यतः service contracts (CI jobs) की जाँच करता है, और ज़रूरत पड़ने पर परिवर्तन का कारण स्पष्ट करना पड़ता है.]

• big tech monorepo के दो प्रकार होते हैं। पहला वह company-wide single "THE" monorepo है, जिसका लेख में ज़िक्र है; इसके लिए custom VCS/CI चाहिए और 200 engineers इसे support करते हैं। Google, Meta, Uber इसी मॉडल पर हैं। इस स्तर तक पहुँचने का दर्द कल्पना से परे होता है, और आमतौर पर यह छोटे "team-level" monorepo से धीरे-धीरे फैलता है। हर stack/language/team अपने-अपने tools जैसे Bazel, Turborepo, Poetry से manage करती है, और समय के साथ यह बड़े monorepo में मिल जाता है। लेकिन इन दोनों मॉडलों में developers और business — दोनों की तरफ से millions of dollars और millions of hours का investment लगता है, और अंत में इसे वही developers चलाते हैं जिन्होंने यह प्रक्रिया झेली होती है.

  • जब मैंने बड़े monorepo वाली कंपनी में काम किया, तब मुझे monorepo बहुत ज़्यादा पसंद आया। single monorepo से service graph, code call structure आदि पूरे सिस्टम को transparent तरीके से समझना बहुत आसान हो जाता है। polyrepo में knowledge टीमों में बिखर जाती है, नए code को अपनाना भी कठिन होता है, और code archive को समझना किसी भूलभुलैया की खोज जैसा लगता है। polyrepo पुरानी Discord/Slack messages की तरह भुला दिया जाता है। अगर monorepo महंगा है, तो polyrepo भी है — बस उसकी लागत अलग तरह की है। monorepo एक विशाल महाद्वीपीय शाकाहारी जानवर जैसा है, polyrepo अलग-अलग species की तरह अंधेरे में बिखरा रहता है.

  • मेरी मौजूदा कंपनी में backend करीब 11 git repos में बँटा है, और एक feature के लिए 4~5 merge requests चाहिए होते हैं, जो बहुत झंझट भरा है। कई projects को एक साथ लाने के लिए monorepo अपनाने पर विचार हो रहा है। लेकिन अगर repos को जोड़ा ही नहीं जा सकता, तो monorepo का विकल्प क्या है — यह जानना चाहता हूँ.

  • language-agnostic, आसान और शक्तिशाली monorepo orchestration system अभी तक मौजूद नहीं है। Bazel जटिल है और सीखना कठिन है, लेकिन हाल में इसकी documentation काफी सुधरी है। Buck, NX, Pants जैसे अन्य विकल्प भी हैं, लेकिन सबकी अपनी-अपनी विशेषताएँ हैं, और खासकर web support सीमित है। ज़्यादातर CI systems इन tools को ठीक से support नहीं करते, इसलिए configuration मुश्किल होती है। वैसे, Microsoft का Rush सबसे अच्छा अनुभव देता है, खासकर frontend/NodeJS monorepo के लिए Rush की सिफारिश है Rush आधिकारिक साइट.

  • वास्तविकता यह है कि अधिकांश monorepos Google, Uber, Meta जैसी कंपनियों के पैमाने तक नहीं बढ़ते। services की संख्या भी हर कंपनी में अलग होती है, और अगर 100 तक भी हों, तो VCS scale की समस्या नहीं आती, और LSP tags भी laptop पर आराम से चल जाते हैं। CI में सारे tests बिना सोचे-समझे चला दें, तब भी अक्सर कोई बड़ी समस्या नहीं होती। निष्कर्ष: हर कंपनी को Google-जैसे scale की ज़रूरत नहीं होती.

  • हमारी मौजूदा कंपनी language stack के हिसाब से monorepo बना रही है। यह काफ़ी अच्छा समझौता है.

• monorepo vs multi-repo बहस में एक point अक्सर नहीं आता: "inverse Conway's Law"। repo structure organization structure और problem solving approach — दोनों को प्रभावित करता है। monorepo common infrastructure teams पर heroic work थोप देता है; shared areas को छूते समय breakage की संभावना बढ़ जाती है, जिससे एक feature विकसित करना भी कठिन हो जाता है। multi-repo में teams के बीच कई PRs, coordination और internal politics चाहिए होती है, लेकिन काम ज़्यादा developers में बाँटा जा सकता है.

  • monorepo में भी अगर बदलाव central और deeply connected हो, तो उसे कई stages में rollout किया जा सकता है। इस प्रक्रिया में कई PRs, coordination और political issues भी होते हैं, लेकिन monorepo होने के कारण rollout की स्थिति कहीं अधिक स्पष्ट दिखती है.

  • polyrepo में shared areas में हुए बदलाव downstream repos तक नहीं पहुँचते, इसलिए हर repo अलग version पर अटका रह जाता है, और सालों तक update न होने के कारण परेशानी होने के मामले कहीं ज़्यादा आम हैं.

  • सवाल यह है कि क्या सचमुच organization पहले repo structure चुनती है और बाद में technical choices उसका अनुसरण करती हैं? असल में specific repo structure से भी अधिक बुनियादी organizational philosophy — fragmentation बनाम sharing — पहले तय होती है। दिशा बदलने पर code management style बदला भी जा सकता है। multi-repo में भी engineers को लगभग सारे code की access दी जा सकती है, और monorepo में भी strong isolation तथा अलग CI या deployment management rules लागू किए जा सकते हैं.

  • monorepo में projects के बीच आसानी से बदलाव हो जाने के कारण, वे काम जो polyrepo में इतने झंझट भरे होते कि लोग कोशिश ही न करें, यहाँ कहीं ज़्यादा बार किए जाते हैं.

• बड़े tech companies के अनुभव के अनुसार build system management के लिए dedicated team चाहिए। बड़े monorepo virtual file system पर आधारित होते हैं, जहाँ source files ज़रूरत पड़ने पर डाउनलोड होते हैं। लेख में यह बात नहीं कही गई कि लगभग सारा development datacenter में चलने वाले dev servers पर होता है, जहाँ 50~100-core environments या on-demand containers इस्तेमाल होते हैं, जो समय-समय पर latest commit से अपडेट होते रहते हैं। IDE dev server के साथ integrate होता है, और language या service के हिसाब से provisioning/auto-setup तक chef/ansible से automate होती है। laptop पर सीधे बड़े monorepo के साथ development करना बहुत दुर्लभ है (अपवाद: mobile/Mac apps आदि).

  • शायद यह उसी build team में काम कर चुके किसी व्यक्ति की बात है। monorepo development environment local हो या remote, reproducibility ज़्यादा महत्वपूर्ण है। अगर remote dev server imaged हो, तो यह और आसान व भरोसेमंद हो जाता है.

  • छोटी टीम में भी datacenter development environment इस्तेमाल करने का अनुभव है। आजकल hardware की कीमत और density को देखें, तो अपना rack लगाकर dev/staging/test जैसे on-demand tools चलाना कहीं अधिक व्यावहारिक है। जब आप production-जैसे development environment को साझा करते हैं, तो monorepo का तरीका बिल्कुल अलग नज़र आता है। लेकिन छोटे-मझोले व्यवसायों के पास build systems में निवेश करने की क्षमता नहीं होती, और वैसे बड़े build system की समस्या पैदा ही नहीं होती (कम-से-कम 10~20 लोगों का scale चाहिए; बहुत complex products में भी maintenance शायद सिर्फ part-time effort हो).

• Molnett (serverless cloud) में Bazel-आधारित monorepo से असाधारण efficiency हासिल करने वाली एक छोटी टीम (full-time 1.5 लोग) की कहानी। Tilt+Bazel+Kind से पूरा platform और Kubernetes operator तक laptop पर चलाया जाता है, और Mac/Linux दोनों support होते हैं। Bottlerocket-आधारित OS और Firecracker तक local में verify किए जा सकते हैं। tool layer बनाकर सभी developers एक ही version के go/kubectl इस्तेमाल करते हैं, local installation की ज़रूरत नहीं। management में मेहनत लगती है, लेकिन ex-Google SRE सदस्य होने के कारण यह संभव हुआ। आगे भी सिर्फ यही तरीका अपनाना चाहेंगे। (मुख्य भाषाएँ Golang, Bash, Rust हैं)

  • अगर टीम 1.5 लोगों की है, तो single repo स्वाभाविक है। Bazel का अनुभव बहुत खराब रहा, लेकिन बड़े projects में यह उपयोगी हो सकता है। 2 लोगों से कम के scale पर शायद Kind+Tilt ही काफी है। tool layer का कुछ हिस्सा Go पहले से go.mod के जरिए हल कर देता है। kubectl के साथ भी कुछ वैसा ही संभव है। ex-Googler के salary level पर भी सोचना चाहिए। आशा है कि Bazel की maintenance cost आगे भी इसकी value साबित करेगी.

  • हमारी कंपनी systemd-आधारित services और ansible playbooks से deploy करती है, और tmuxinator से backend/DB/search engine/frontend तक सारी services को dev mode में terminal से एक साथ auto-start किया जाता है। root में एक बार tmuxinator command चलाते ही पूरा dev environment तैयार हो जाता है। single monorepo पहले की तुलना में बहुत अधिक सुविधाजनक है.

  • मिलती-जुलती स्थिति में Bazel अपनाने के फायदे अधिकतम देखे हैं। tool layer की वजह से development environment consistently बना रहता है। सीधे bazel run इस्तेमाल करना पड़ता है, और इससे बेहतर automation तरीका क्या हो सकता है — यह जानना चाहते हैं। यह कैसे काम करता है, कृपया बताइए.

  • 2 लोगों की टीम में microservices/K8s pattern अपने-आप में overengineering है। इतने छोटे scale पर कोई भी तरीका चलेगा। पहले Dropbox/SVN/MS VCS जैसी किसी भी पद्धति से काम चल जाता था (कुछ असुविधाएँ थीं, लेकिन वे निर्णायक समस्या नहीं थीं)। इस scale पर हर कोई पूरे process की मानसिक तस्वीर रख सकता है। जटिल tools या infrastructure सफलता का निर्णायक कारण नहीं हैं — यही अनुभव है.

• पिछले 4 साल में कई कंपनियों में तीन बार monorepo setup कर चुके एक freelancer का अनुभव। frontend तक सीमित रहकर JavaScript/TypeScript ecosystem का उपयोग किया, इसलिए management अपेक्षाकृत आसान था। वास्तव में अच्छा monorepo अंदर से polyrepo की तरह काम करता है: हर project को independently develop/deploy/host किया जा सकता है, लेकिन वे एक codebase में साथ रहते हैं, common components (जैसे UI) खुलकर share कर सकते हैं, और consistent look-and-feel बनाए रखते हैं। practical guide के तौर पर यह संदर्भ सुझाया गया है.

  • यह वास्तव में polyrepo नहीं, बल्कि ठीक से बनाया गया monorepo का उदाहरण है.

• अंततः, सब कुछ context पर निर्भर करता है। हमारी कंपनी करीब 40 git repos को अलग-अलग CI से manage करती है, build/test/package के बाद अंत में एक integrated file system image बनाती है और integration tests चलाती है। components के बीच Flatbuffers messages से communication होता है, और flatbuffers भी submodule के रूप में manage होते हैं। downstream dependencies को संभालना कठिन है, लेकिन progressive enhancement के जरिए कुछ लचीलापन मिल जाता है। ऐसे मामले में इसे multi-repo कहें या बहुत सारे submodules वाला monorepo — यह तय करना भी कठिन है। monorepo में बदलने से फायदा होगा या नहीं, यह स्पष्ट नहीं। अंत में यह trade-offs और किस तरह की असुविधा स्वीकार करनी है, इसी का सवाल है.

• monorepo tools पर ब्लॉग लिखने वाले का अनुभव। लोग monorepo के फायदों पर ज़ोर देते हैं, लेकिन सफल monorepo operation की जटिलता का बड़ा हिस्सा पर्दे के पीछे devops/devtools teams संभालती हैं। इसलिए adoption सावधानी से होना चाहिए, लेकिन सही तरह से बनाया जाए तो यह पर्याप्त value देता है.

• अच्छी तरह managed monorepo का अनुभव इतना शानदार होता है कि फिर किसी दूसरे workflow पर लौटने का मन नहीं करता। लेकिन बिना तैयारी वाला "हम भी monorepo करेंगे" वाला तरीका एक दुःस्वप्न है। अगर कोई तैयार monorepo environment और tools को package के रूप में बेचे, तो उसमें बड़ा business opportunity हो सकता है.

  • NX पहले से यही business कर रहा है। पिछली startup में शुरुआत से NX के साथ development किया, और 15 लोगों की R&D team होने के बावजूद 100 लोगों के scale जैसी standardization हासिल की। नई कंपनी (जिसने startup को acquire किया) में बिना योजना के "हम भी monorepo" कोशिश एक disaster साबित हुई। अब NX पर migrate कर रहे हैं, और इसका असर बहुत अच्छा है.

• बड़े organizations में monorepo उल्टा teams के बीच dependencies को अत्यधिक सीमित कर सकता है, जिससे code reuse घट सकता है — ऐसा अनुभव रहा है। library team अगर कुछ बदलना चाहती है, तो सारे downstream users को update करना पड़ता है, और कुछ teams के अप्रत्याशित उपयोग के कारण बदलाव उलझ जाते हैं (Hyrum's Law)। अंततः बड़ी कंपनियाँ internal copy-paste, forks, सख्त access control, और धीमे change approvals पर पहुँच जाती हैं.

  • अगर ऐसी library बनानी हो जिसे सामान्य रूप से इस्तेमाल किया जाना है, तो API design बहुत सावधानी से करनी चाहिए। जहाँ तक संभव हो API न बदलें; अगर बदलना ही पड़े, तो बड़े बदलाव की पक्की योजना बनाएँ, या नई function से replace करें और पुरानी version को deprecated करें। छोटे code के मामले में copy-paste भी ठीक है.

  • फिर भी monorepo का फायदा यह है कि सभी usages आसानी से मिल जाते हैं, और ज़रूरत पड़ने पर atomic तरीके से बदलाव/सुधार किया जा सकता है.

  • हर software को dependencies का ध्यान रखना पड़ता है, और monorepo तो library या user — दोनों के दृष्टिकोण से एक-दूसरे को बदलने का अधिकार और बढ़ा देता है.

  • monorepo में अपनी स्थिति के हिसाब से बदलाव करना आसान होने के कारण, code reuse की संभावना polyrepo की तुलना में अधिक होती है.