स्वभाव अलग हैं, लेकिन आपस में जुड़े कई projects को आप कैसे integrate करना पसंद करते हैं (या अलग ही रखना पसंद करते हैं)?
उदाहरण के लिए, अगर एक ही service के लिए front-end, back-end(api), serverless, batch, pipeline, ... वगैरह हों
-
Mono-repo
अगर service एक ही है, तो repository भी एक ही! हर project को package/folder structure में
-> लेकिन commit management कैसे..? CI/CD या pre-commit जैसे hooks काफ़ी complex हो जाएंगे.. -
Git Submodules
अगर nature अलग है, तो कम-से-कम git history तो अलग manage करनी चाहिए! फिर भी जितना हो सके एक साथ बांधकर..
-> submodule sync जैसी learning curve.. merge भी complex हो जाएगा.. क्या दूसरे developers इसे follow कर पाएंगे? -
अलग-अलग repo
सीधा-सादा! project अलग है तो repo भी अलग!
-> A service देखने के लिए कौन-सा repo देखना है? अरे ये वाला, वो वाला,.. और क्या-क्या था...
लगता है इसका कोई एक सही जवाब नहीं है, लेकिन आप क्या/क्यों पसंद करते हैं, यह जानने की जिज्ञासा है!
16 टिप्पणियां
मैं तो अलग-अलग repo ही पसंद करता हूँ...
जब मेरे मन में यह सवाल आता है कि अगर मुझे इस फीचर से जुड़ी API की history देखनी हो, तो आखिर मुझे क्या देखना चाहिए? ऐसे में एक repo को एक फीचर से मैप करके रखना मुझे सुविधाजनक लगता है।
मैं ज़्यादातर स्थितियों में mono-repo इस्तेमाल करता हूँ, लेकिन दो ऐसे केस हैं जहाँ मैं submodule का उपयोग करता हूँ.
जब किसी बाहरी publisher को हायर किया हो।
जब publishing के लिए ज़रूरी जानकारी के अलावा बाकी चीज़ें बाहरी publisher को दिखाना नहीं चाहते, तब मैं submodule इस्तेमाल करता हूँ.
जब किसी बाहरी solution को customize करना हो।
खासकर जब वह plugin फीचर देने वाला solution हो, तब मैं submodule इस्तेमाल करता हूँ.
उस बाहरी solution को submodule के रूप में register करके, अपने plugins को symlink वगैरह से plugin path के अंदर डालकर काम करता हूँ. मेरे plugins का version management मैं अलग से रख सकता हूँ, और बाहरी solution अपना version control जैसा है वैसा ही बनाए रख सकता है — यही इसका फ़ायदा है.
लगता है submodule इस्तेमाल करने का अनुभव लगभग सभी का खराब रहा है.. अगर इसे बेहतर बनाने वाला कोई टूल हो तो अच्छा रहेगा
अगर आपको सिर्फ merge commits करने का भरोसा है तो monorepo,
अगर बार-बार rebase करने वाले हैं तो multi-repo,
submodule? बस OS में मिलने वाले directory links इस्तेमाल करें…
पहले मैं बस अलग-अलग स्वतंत्र repo इस्तेमाल करता था, लेकिन हाल में मैंने पूरी तरह submodule इस्तेमाल करने वाले तरीके पर स्विच कर लिया है.
पहले git की समझ कम होने की वजह से मैं submodule का सही तरह से उपयोग नहीं कर पाता था, लेकिन अब मुझे लगता है कि submodule इस्तेमाल करना बेहतर है.
हालांकि submodule इस्तेमाल करने पर उस submodule में commit करना पड़ता है और parent repo में भी फिर से commit करना पड़ता है, जिसके कारण दोनों के समय में अंतर आ जाता है, और इससे repo की consistency कम होने की समस्या भी साथ आती लगती है.
https://monorepo.tools/
अगर आपने यह साइट नहीं देखी है, तो एक बार देखना अच्छा रहेगा।
मेरे व्यक्तिगत अनुभव में submodule की सिफारिश नहीं करूँगा।
अगर आप submodule से किसी दूसरे repository का code share करना चाहते हैं, तो उसकी बजाय उसे package के रूप में publish करना बेहतर लगेगा।
हमारी कंपनी में हर प्रोजेक्ट पर टीम के सदस्य कम थे, और frontend व backend की language और tech stack अलग-अलग थे, इसलिए भूमिकाओं के बीच cross-contribution लगभग नहीं के बराबर था। बाकी सभी IT systems की तरह, अंत में लगता है कि यह भी संगठन की संरचना के अनुसार ही चलता है।
ओह.. तो यह ऐसा अप्रोच है जिसमें इस बात के अनुसार दूसरे के कोड की विज़िबिलिटी को नियंत्रित किया जाता है कि इंटरफ़ेस इंसान मिलाता है या टूल उसे संभालता है।
मेरे पास Mono-repo का अनुभव नहीं है, इसलिए एक बात को लेकर जिज्ञासा है। जब Mono Repo का उपयोग किया जाता है, तो क्या कई projects या services में common modules (जैसे design system) भी उसी Mono Repo में शामिल किए जाते हैं? या फिर इसे मजबूरी में अलग Repo में रखकर reference किया जाता है?
लगता है कि common module तक पहुंचने के लिए हमने
yarn workspaceजैसी मदद लेकर symlink के रूप में access किया था!मैं कंपनी में और व्यक्तिगत प्रोजेक्ट्स में, front-end, back-end, batch आदि को अलग किए बिना एक ही git से मैनेज करता हूँ.
कभी-कभी backward compatibility बनाए रखने से ज़्यादा, दोनों को साथ में बदलना आसान होता है. और दोनों ही मामलों में टीम का आकार छोटा है, इसलिए बेवजह अलग करके कोई खास फ़ायदा नहीं लगा... GitHub Actions में सिर्फ बदले हुए हिस्से ही चलें, ऐसा सेटअप करने की मेहनत भी उठाने लायक थी. सबसे बढ़कर, back-end और front-end को अलग करने से ज़्यादा यह अच्छा लगता है कि दोनों तरफ़ के लोग एक-दूसरे को contribute कर सकें. (जैसे front-end पर काम करते हुए अगर back-end में कुछ ज़रूरी हो तो खुद जोड़ देना, या errors भी सीधे ठीक कर देना...)
हम्म, लगता है कि अगर स्केल छोटा हो या roles इतने सख्ती से बँटे न हों, तो आप लोग monorepo को ज़्यादा पसंद करते हैं! Git history के मिल जाने जैसी बात? उससे भी क्या आपको बहुत फ़र्क नहीं पड़ता? (वैसे भी सारा code तो सब देखते ही हैं?)
दिलचस्प बात यह है कि मेरे side project में भी ऐसा ही है। अभी मैंने लगभग 12 लोगों के साथ काम किया है। हर व्यक्ति frontend से backend तक एक ही flow में काम करता है। यह vertical slice से मिलता-जुलता भी लगता है।
मैं इसे मिला-जुला मामला नहीं मानता। अक्सर एक ही PR में frontend और backend दोनों में बदलाव करने पड़ते हैं। हमारी टीम का मूल दृष्टिकोण यह है कि हम चारों full-stack हैं, इसलिए backend/frontend का भेद किए बिना हम एक-दूसरे का review भी करते हैं और बदलावों को भी समझना ज़रूरी है।
अगर मॉड्यूल बहुत बड़ा नहीं है, तो monorepo
अगर मॉड्यूल बड़ा है, तो submodule
या फिर अगर open source रिलीज़ करते समय आप चाहें कि सिर्फ submodule में ही contribution हो और main repo को अलग से मैनेज किया जाए,
तो लगता है कि submodule में अलग करना सही है।
लेकिन submodule शामिल होने पर open source करते समय दूसरे यूज़र्स के लिए contribution हेतु test या build से जुड़ा documentation लिखना थोड़ा जटिल हो जाता है।
इसलिए व्यक्तिगत तौर पर, अगर दोनों की contribution का स्वरूप अलग नहीं है, तो monorepo रखना,
या उन्हें अलग-अलग GitHub पर रखकर हर एक को package या Docker image के रूप में डिप्लॉय करके मैनेज करना बेहतर लगता है।
मैंने open source के संदर्भ में इस बारे में सोचा नहीं था, सुझाव के लिए धन्यवाद!