मोनोरेपो बनाम मल्टीरेपो

विषय-सूची:

• सारांश
  • मुद्दा
  • निर्णय
  • अवस्था
• विवरण
  • मान्यताएँ
  • बाधाएँ
  • रुख
  • तर्क
  • निहितार्थ
• संबंधित
  • संबंधित निर्णय
  • संबंधित आवश्यकताएँ
  • संबंधित कलाकृतियाँ
  • संबंधित सिद्धांत
• टिप्पणियाँ

सारांश

मुद्दा

हमारी परियोजना में सॉफ़्टवेयर की तीन प्रमुख श्रेणियाँ विकसित करना शामिल है:

• फ्रंट-एंड GUI
• मिडलवेयर सेवाएँ
• बैक-एंड सर्वर

विकास करते समय, हमारी स्रोत कोड प्रबंधन (SCM) संस्करण नियंत्रण प्रणाली (VCS) git है।

हमें चुनना है कि अपना कोड व्यवस्थित करने के लिए git का उपयोग कैसे करें।

शीर्ष-स्तरीय विकल्प "मोनोरेपो" या "पॉलीरेपो" या "हाइब्रिड" के रूप में व्यवस्थित करना है:

• मोनोरेपो का अर्थ है कि हम सभी हिस्सों को एक बड़े रिपॉज़िटरी में रखते हैं
• पॉलीरेपो का अर्थ है कि हम प्रत्येक हिस्से को उसके अपने रिपॉज़िटरी में रखते हैं
• हाइब्रिड का अर्थ है मोनोरेपो और पॉलीरेपो का कोई मिश्रण

अधिक जानकारी के लिए कृपया देखें https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

निर्णय

मोनोरेपो तब जब कोई संगठन/टीम/परियोजना अपेक्षाकृत छोटी हो, और तेज़ पुनरावृत्ति स्थिरता बनाए रखने से अधिक प्राथमिकता हो।

पॉलीरेपो तब जब कोई संगठन/टीम/परियोजना अपेक्षाकृत बड़ी हो, और स्थिरता बनाए रखना तेज़ पुनरावृत्ति से अधिक प्राथमिकता हो।

अवस्था

तय। मोनोरेपो और/या पॉलीरेपो के प्रबंधन के लिए नए उपकरण उपलब्ध होने पर/होने पर पुनर्विचार के लिए खुले हैं।

विवरण

मान्यताएँ

हम जो भी कोड विकसित कर रहे हैं वह एक संगठन की पेशकशों के लिए है, आम जनता के लिए नहीं। यानी ब्रोकर-डीलर का लक्ष्य आम जनता के स्वयंसेवी डेवलपरों जैसा कुछ रखना नहीं है।

बाधाएँ

बाधाएँ https://github.com/joelparkerhenderson/monorepo-vs-polyrepo पर अच्छी तरह दर्ज हैं

रुख

हमने Google, Facebook आदि की शैली के मोनोरेपो पर विचार किया। हमारा मानना है कि मोनोरेपो के किसी भी स्केलिंग मुद्दे भविष्य में इतनी दूर हैं कि जब तक हमें उनकी आवश्यकता पड़ेगी, हम Google और Facebook जैसी ही प्रथाओं का लाभ उठा सकेंगे।

हमने सामान्य Git ओपन सोर्स परियोजनाओं की शैली के पॉलीरेपो पर विचार किया, जैसे Google Android, Facebook React आदि। हमारा मानना है कि आम जनता की भागीदारी (जैसे दुनिया में कोई भी कोड पर काम कर सकता है) और व्यक्तिगत उपलब्धता (जैसे परियोजना का उपयोग अकेले, किसी अन्य हिस्से के बिना होता है) के लिए ये सर्वोत्तम विकल्प हैं।

तर्क

जब कोई संगठन/टीम/परियोजना अपेक्षाकृत छोटी हो, तब हम मोनोरेपो चुनते हैं, क्योंकि तेज़ पुनरावृत्ति की प्राथमिकता स्थिरता बनाए रखने से काफ़ी अधिक है।

जब कोई संगठन/टीम/परियोजना अपेक्षाकृत बड़ी हो, तब हम पॉलीरेपो चुनते हैं, क्योंकि स्थिरता बनाए रखने की प्राथमिकता तेज़ पुनरावृत्ति से काफ़ी अधिक है।

निहितार्थ

यदि CI+CD के लिए कोई मौजूदा पाइपलाइन है, तो एक रिपॉज़िटरी के भीतर कई परियोजनाओं के परीक्षण के लिए हमें उसे समायोजित करना पड़ सकता है।

मोनोरेपो के लिए पूर्ण बिल्ड में CI+CD को अधिक समय लग सकता है, क्योंकि CI+CD मोनोरेपो की सभी परियोजनाओं को बिल्ड कर सकता है।

यदि कोई संगठन/टीम/परियोजना बढ़ती है, तो मोनोरेपो में स्केलिंग संबंधी समस्याएँ आएँगी।

मोनोरेपो की स्केलिंग समस्याएँ पॉलीरेपो पर जाना अधिकाधिक मूल्यवान बना सकती हैं।

मोनोरेपो से पॉलीरेपो पर जाना एक महत्वपूर्ण devops कार्य है, और इसकी योजना बनानी, प्रबंधन करना और प्रोग्राम करना होगा।

संबंधित

संबंधित निर्णय

हम मोनोरेपो (जैसे Google Bazel) और पॉलीरेपो (जैसे Lyft Refactorator) के प्रबंधन के संबंधित उपकरणों के लिए निर्णय बनाएँगे।

संबंधित आवश्यकताएँ

हमें CI+CD पाइपलाइन को इस तरह विकसित करना होगा कि वह git के साथ अच्छी तरह काम करे।

संबंधित कलाकृतियाँ

हम अपेक्षा करते हैं कि रिपॉज़िटरी संगठन के साथ प्रावधान, कॉन्फ़िगरेशन प्रबंधन, परीक्षण और ऐसे ही devops क्षेत्रों की संबंधित कलाकृतियाँ होंगी.

संबंधित सिद्धांत

आसानी से पलटा जा सकने वाला। यदि मोनोरेपो व्यवहार में काम नहीं करता, या नेतृत्व उसे नहीं चाहता, तो पॉलीरेपो में बदलना आसान है।

ग्राहक के प्रति समर्पण। हम परियोजना को ग्राहकों के हाथों में पहुँचाने को महत्व देते हैं, और हमारा मानना है कि मोनोरेपो हमें पॉलीरेपो की तुलना में वहाँ तेज़ी से पहुँचा सकता है, और तेज़ी से पुनरावृत्ति करने में भी मदद कर सकता है।

बड़ा सोचें। Google और Facebook पॉलीरेपो की तुलना में मोनोरेपो के बहुत मज़बूत समर्थक हैं, क्योंकि सभी मुख्य पेशकशों को एक साथ विकसित/परीक्षित/तैनात किया जा सकता है।

टिप्पणियाँ

यहाँ कोई भी टिप्पणी जोड़ें।