मोनो-रिपॉजिटरी: कृपया नहीं (भाग 2)

सभी को नमस्कार!

तो, मोनोरेपोज़िटरीज़ के बारे में वादा किए गए होलीवर का एक नया हिस्सा। पहले भाग में, हमने Lyft (और पहले ट्विटर) के एक सम्मानित इंजीनियर द्वारा एक लेख के अनुवाद पर चर्चा की कि मोनो-रिपॉजिटरी के नुकसान क्या हैं और वे इस दृष्टिकोण के लगभग सभी फायदे क्यों हैं। व्यक्तिगत रूप से, मैं मूल लेख में प्रस्तुत तर्कों से काफी हद तक सहमत हूँ। लेकिन, जैसा कि वादा किया गया था, इस चर्चा को समाप्त करने के लिए, मैं कुछ और बिंदुओं पर आवाज देना चाहूंगा, मेरी राय में यह और भी महत्वपूर्ण और अधिक व्यावहारिक है।

मैं आपको अपने बारे में थोड़ा बताऊंगा - मैंने दोनों छोटी परियोजनाओं और अपेक्षाकृत बड़े लोगों में काम किया, मैंने एक परियोजना में 100 से अधिक माइक्रोसर्विस (और एसएलए 99.999%) के साथ पॉलीप्रॉपिटरीज़ का उपयोग किया। फिलहाल मैं मावेन से बाज़ल तक एक छोटे मोनो-रिपॉजिटरी (वास्तव में नहीं, बस सामने के जेएस + जावा बैकेंड) के अनुवाद में संलग्न हूं। Google, Facebook, Twitter, यानी पर काम नहीं किया मुझे ठीक से कॉन्फ़िगर और ट्यून किए गए मोनो-रिपॉजिटरी का उपयोग करने की खुशी नहीं है।

तो, शुरुआत के लिए, एक मोनोरेपोजिटरी क्या है? मूल लेख के अनुवाद पर टिप्पणियों से पता चलता है कि कई लोग मानते हैं कि एक मोनो-रिपॉजिटरी तब है जब सभी 5 कंपनी डेवलपर्स एक रिपॉजिटरी पर काम करते हैं और इसमें फ्रंटएंड और बैकेंड को एक साथ स्टोर करते हैं। बेशक, ऐसा नहीं है। एक मोनो-रिपॉजिटरी सभी कंपनी परियोजनाओं, पुस्तकालयों, बिल्ड टूल्स, आईडीई प्लग-इन, परिनियोजन स्क्रिप्ट और बाकी सभी चीजों को एक बड़े भंडार में संग्रहीत करने का एक तरीका है। यहाँ विवरण trunkbaseddevelopment.com हैं ।

जब कंपनी छोटी होती है, तब इसे क्या कहा जाता है, और इसके पास इतने सारे प्रोजेक्ट, मॉड्यूल, घटक नहीं होते हैं? यह भी एक monorepository है, केवल एक छोटा है।
स्वाभाविक रूप से, मूल लेख कहता है कि वर्णित सभी समस्याएं एक निश्चित पैमाने पर दिखाई देने लगती हैं। इसलिए, जो लोग लिखते हैं कि उनके 1.5 खुदाई कार्य के मोनो-रिपॉजिटरी निश्चित रूप से बिल्कुल सही हैं।

इसलिए, पहला तथ्य जिसे मैं ठीक करना चाहूंगा: एक मोनोरेपोजिटरी आपके नए प्रोजेक्ट के लिए एक शानदार शुरुआत है । सभी कोड को एक हीप में रखना, सबसे पहले आपको केवल एक फायदा मिलेगा, क्योंकि एकाधिक रिपॉजिटरी का समर्थन निश्चित रूप से ओवरहेड का एक सा जोड़ देगा।

फिर समस्या क्या है? और समस्या, जैसा कि मूल लेख में बताया गया है, एक निश्चित पैमाने पर शुरू होती है। और सबसे महत्वपूर्ण बात, उस पल को याद न करें जब ऐसा पैमाना पहले ही आ चुका हो।

इसलिए, मैं यह कहना चाहता हूं कि संक्षेप में जो समस्याएं पैदा होती हैं, वे "एक ढेर में अपने सभी कोड डाल" की समस्याएं नहीं हैं, लेकिन ये केवल बड़े स्रोत कोड रिपोजिटरी की समस्याएं हैं। यानी यह मानते हुए कि आपने विभिन्न सेवाओं / घटकों के लिए पॉलीप्रॉपेटरीज़ का उपयोग किया है, और इनमें से एक सेवा इतनी बड़ी हो गई है (कितनी बड़ी है, हम थोड़ी देर बाद चर्चा करेंगे), तो आप सबसे अधिक संभावना बिल्कुल समान समस्याएं प्राप्त करेंगे, लेकिन मोनो-रिपॉजिटरी के फायदे के बिना भी (यदि वे) जरूर ह) है।

तो, समस्याग्रस्त माने जाने वाले भंडार को कितना बड़ा होना चाहिए?
निश्चित रूप से 2 संकेतक हैं जो इस पर निर्भर करता है - कोड की मात्रा और इस कोड के साथ काम करने वाले डेवलपर्स की संख्या। यदि आपके प्रोजेक्ट में टेराबाइट्स कोड है, लेकिन 1-2 लोग इसके साथ काम करते हैं, तो सबसे अधिक संभावना है कि वे लगभग समस्याओं को नहीं देखेंगे (अच्छी तरह से, या कम से कम यह कुछ भी करना आसान होगा, भले ही वे नोटिस करें :)

यह कैसे निर्धारित किया जाए कि यह सोचने का समय है कि अपनी रिपॉजिटरी में सुधार कैसे करें? बेशक, यह एक व्यक्तिपरक संकेतक है, सबसे अधिक संभावना है कि आपके डेवलपर्स शिकायत करना शुरू कर देंगे कि कुछ उन्हें सूट नहीं करता है। लेकिन समस्या यह है कि कुछ बदलने में बहुत देर हो सकती है। मुझे आपको कुछ व्यक्तिगत आंकड़े देने चाहिए: यदि आपकी रिपॉजिटरी की क्लोनिंग में 10 मिनट से अधिक समय लगता है, यदि किसी प्रोजेक्ट का निर्माण करने में 20-30 मिनट से अधिक समय लगता है, यदि डेवलपर्स की संख्या 50 से अधिक है, और इसी तरह।


अब आइए उन समस्याओं की सूची से गुजरते हैं जो बड़े भंडार में उत्पन्न होती हैं (उनमें से कुछ मूल लेख में बताई गई थीं, कुछ नहीं हैं)।

1) रिपोजिटरी डाउनलोड समय

एक ओर, हम कह सकते हैं कि यह एक बार का ऑपरेशन है जिसे डेवलपर अपने कार्य केंद्र के शुरुआती सेटअप के दौरान करता है। व्यक्तिगत रूप से, मेरे पास अक्सर ऐसी परिस्थितियां होती हैं, जहां मैं किसी प्रोजेक्ट को पड़ोसी फ़ोल्डर में क्लोन करना चाहता हूं, इसमें गहरी खुदाई करता हूं, और फिर इसे हटा देता हूं। हालांकि, यदि क्लोनिंग में 10-20 मिनट से अधिक समय लगता है, तो यह इतना सुविधाजनक नहीं होगा।

लेकिन इसके अलावा, यह मत भूलो कि परियोजना को सीआई सर्वर पर इकट्ठा करने से पहले, आपको प्रत्येक बिल्ड एजेंट के लिए रिपॉजिटरी को क्लोन करने की आवश्यकता है। और यहां आप यह पता लगाना शुरू करते हैं कि इस समय को कैसे बचाया जाए, क्योंकि यदि प्रत्येक विधानसभा में 10-20 मिनट अधिक समय लगता है, और विधानसभा का परिणाम 10-20 मिनट बाद दिखाई देता है, तो यह किसी के अनुरूप नहीं होगा। तो रिपॉजिटरी वर्चुअल मशीनों की छवियों में दिखाई देने लगती है जिसमें से एजेंट तैनात किए जाते हैं, इस समाधान का समर्थन करने के लिए अतिरिक्त जटिलता और अतिरिक्त लागत दिखाई देती है।

2) समय का निर्माण

यह एक काफी स्पष्ट बिंदु है जिस पर कई बार चर्चा हुई है। वास्तव में, यदि आपके पास बहुत सारे स्रोत कोड हैं, तो किसी भी मामले में विधानसभा में काफी समय लगेगा। एक परिचित स्थिति तब होती है जब कोड की एक पंक्ति को बदलने के बाद आपको आधे घंटे इंतजार करना पड़ता है जब तक कि परिवर्तनों को फिर से जांचा और परखा नहीं जाता है। वास्तव में, केवल एक ही रास्ता है - कैशिंग परिणाम और वृद्धिशील बिल्ड के आसपास निर्मित बिल्ड सिस्टम का उपयोग करना।

यहां बहुत सारे विकल्प नहीं हैं - इस तथ्य के बावजूद कि कैशिंग सुविधाओं को एक ही ग्रेडल में जोड़ा गया था (दुर्भाग्य से, मैंने उन्हें अभ्यास में उपयोग नहीं किया था), वे इस तथ्य के कारण व्यावहारिक लाभ नहीं लाते हैं कि पारंपरिक निर्माण प्रणालियों में दोहराव परिणाम नहीं होते हैं (प्रतिलिपि प्रस्तुत करने योग्य बनाता है)। यानी पिछले बिल्ड के साइड इफेक्ट्स के कारण, वैसे भी, कुछ बिंदु पर कैश क्लीनअप (मानक maven clean build अप्रोच) को कॉल करना आवश्यक होगा। इसलिए, केवल बज़ेल / बक / पैंट और उनके जैसे अन्य लोगों का उपयोग करने का विकल्प है। यह बहुत अच्छा क्यों नहीं है, हम थोड़ी देर बाद चर्चा करेंगे।

3) अनुक्रमण आईडीई

Intellij IDEA में मेरा वर्तमान प्रोजेक्ट 30 से 40 मिनट के लिए अनुक्रमित है। आपका क्या? बेशक, आप परियोजना का केवल एक हिस्सा खोल सकते हैं या सभी अनावश्यक मॉड्यूल को अनुक्रमण से बाहर कर सकते हैं, लेकिन ... समस्या यह है कि जब आप एक शाखा से दूसरी शाखा में स्विच करते हैं, तो समस्या होती है। यही कारण है कि मैं एक परियोजना को पड़ोसी निर्देशिका में क्लोन करना पसंद करता हूं। कुछ लोग आईडीई कैश कैश करना शुरू करते हैं :)
<संकुचित आंखों के साथ डिकैप्रियो तस्वीर>

4) लॉग बनाएँ

आप किस CI सर्वर का उपयोग कर रहे हैं? क्या यह निर्माण लॉग के कई गीगाबाइट को देखने और नेविगेट करने के लिए एक सुविधाजनक इंटरफ़ेस प्रदान करता है? दुर्भाग्य से मेरा नहीं है :(

5) आवागमन का इतिहास

क्या आप प्रतिबद्ध इतिहास देखना पसंद करते हैं? मुझे प्यार है, विशेष रूप से एक ग्राफिकल इंटरफ़ेस वाले टूल में (मुझे जानकारी नेत्रहीन रूप से बेहतर लगती है, डांटती नहीं है :)।

क्या आपको यह पसंद है? क्या यह सुविधाजनक है? व्यक्तिगत रूप से, मैं नहीं!

6) टूटे हुए परीक्षण

यदि कोई मास्टर में टूटे हुए परीक्षण / गैर-संकलन कोड चलाने में सक्षम था तो क्या होगा? आप निश्चित रूप से कहेंगे कि आपका सीआई आपको ऐसा करने की अनुमति नहीं देता है। अस्थिर परीक्षणों के बारे में क्या लेखक गुजरता है, और कोई नहीं? अब कल्पना करें कि यह कोड 300 डेवलपर्स की मशीनों तक फैला है, और उनमें से कोई भी एक परियोजना को इकट्ठा नहीं कर सकता है? ऐसी स्थिति में क्या करें? नोटिस और सही करने के लिए लेखक की प्रतीक्षा करें? उसके लिए सही है? रोल बैक में बदलाव? बेशक, आदर्श रूप से, यह केवल अच्छे कोड के लायक है, और बग के बिना तुरंत लिखो। तब ऐसी समस्या पैदा नहीं होगी।
(उन लोगों के लिए जो टैंक में संकेतों को नहीं समझते हैं, नकारात्मक प्रभाव के बारे में बात अगर यह 10 डेवलपर्स के साथ रिपॉजिटरी में होता है और 300 के साथ रिपॉजिटरी में थोड़ा अलग होगा)

7) मर्ज बॉट

कभी ऐसी बात सुनी है? क्या आप जानते हैं कि आपको इसकी आवश्यकता क्यों है? आप हँसेंगे, लेकिन यह एक और उपकरण है जिसका अस्तित्व नहीं होना चाहिए :) बस कल्पना करें कि आपकी परियोजना का निर्माण समय 30 मिनट है। और 100 डेवलपर आपके प्रोजेक्ट पर काम कर रहे हैं। मान लीजिए कि उनमें से प्रत्येक प्रति दिन 1 प्रतिबद्ध करता है। अब ईमानदार सीआई की कल्पना करें, जो आपको मास्टर (रिबेस) से नवीनतम प्रतिबद्ध के लिए लागू होने के बाद ही मास्टर में परिवर्तन को मर्ज करने की अनुमति देता है।

ध्यान दें, सवाल यह है कि ऐसे ईमानदार CI सर्वर के लिए एक दिन में कितने घंटे होना चाहिए ताकि सभी डेवलपर्स से बदलावों का गला घोंट सकें? सही उत्तर 50 है। जिन लोगों ने सही उत्तर दिया है, वे एक शेल्फ से गाजर ले सकते हैं। ठीक है, या कल्पना करें कि आपने मास्टर के लिए अपनी अंतिम प्रतिबद्ध के लिए अपनी प्रतिबद्धता कैसे काट दी, विधानसभा शुरू की, और जब यह पूरा हो गया, तो मास्टर पहले से ही 20 बार आगे चला गया। सब फिर से?

तो मर्ज बॉट या मर्ज कतार एक ऐसी सेवा है जो एक ताजा मास्टर के लिए सभी मर्ज अनुरोधों को पुन: पेश करने की प्रक्रिया को स्वचालित करती है, परीक्षण चलाती है और खुद को मर्ज करती है, और बैचों में कम्बाइन भी जोड़ सकती है और उन्हें एक साथ परीक्षण कर सकती है। बहुत काम की चीज। Mergify.io , Google से k8s-infra Prow , bors-ng , आदि देखें (मैं भविष्य में इसके बारे में अधिक लिखने का वादा करता हूं)

अब कम तकनीकी मुद्दों के लिए:

8) एकल निर्माण उपकरण का उपयोग करना

ईमानदारी से, यह अभी भी मेरे लिए एक रहस्य है कि एक सामान्य बिल्ड सिस्टम का उपयोग करके पूरे मोनो-रिपॉजिटरी को क्यों इकट्ठा किया जाए। क्यों नहीं यार्न के साथ जावास्क्रिप्ट का निर्माण, ढाल के साथ जावा, एसबीटी के साथ स्काला, आदि? यदि कोई इस प्रश्न का उत्तर जानता है (अनुमान या सुझाव नहीं है, अर्थात् जानता है), टिप्पणियों में लिखें।

बेशक, यह स्पष्ट लगता है कि एक बिल्ड सिस्टम का उपयोग करना कई अलग-अलग लोगों की तुलना में बेहतर है। लेकिन वे अभी भी समझते हैं कि कोई भी सार्वभौमिक चीज स्पष्ट रूप से एक विशेष से भी बदतर है, क्योंकि यह सबसे अधिक संभावना है कि सभी विशेष के कार्यों का एक सबसेट है। लेकिन इससे भी बदतर, अलग-अलग प्रोग्रामिंग भाषाओं में असेंबली, निर्भरता प्रबंधन, आदि के संदर्भ में अलग-अलग प्रतिमान हो सकते हैं, जो एक सामान्य आवरण में लपेटना बहुत मुश्किल होगा। मैं विवरण में नहीं जाना चाहता हूं, मैं एक उदाहरण bazel के बारे में दूंगा (एक अलग लेख में विवरण देखें) - हमने Google से आधिकारिक एक के साथ, GitHub पर 5 अलग-अलग कंपनियों से bazel के लिए जावास्क्रिप्ट विधानसभा नियमों के 5 स्वतंत्र कार्यान्वयन पाए। यह विचार करने लायक है।

9) सामान्य दृष्टिकोण

मूल लेख के जवाब में शेफ से सीटीओ ने अपना जवाब मोनोरेपो लिखा : कृपया! । अपनी प्रतिक्रिया में, उनका तर्क है कि "मोनोरपो में मुख्य बात यह है कि यह आपको बात करता है और दोषों को दिखाई देता है।" उसका मतलब है कि जब आप अपना एपीआई बदलना चाहते हैं, तो आपको इसके सभी उपयोगों को खोजना होगा और कोड के इन टुकड़ों के अनुरक्षकों के साथ अपने परिवर्तनों पर चर्चा करनी होगी।

इसलिए मेरा अनुभव इसके बिल्कुल विपरीत है। यह स्पष्ट है कि यह बहुत कुछ टीम में इंजीनियरिंग संस्कृति पर निर्भर करता है, लेकिन मुझे इस दृष्टिकोण में ठोस minuses दिखाई देते हैं। कल्पना करें कि आप एक निश्चित दृष्टिकोण का उपयोग कर रहे हैं जिसने आपको कुछ समय के लिए ईमानदारी से सेवा दी है। और इसलिए आपने किसी कारण से निर्णय लिया, इसी तरह की समस्या को हल करते हुए, थोड़ा अलग तरीके का उपयोग करने के लिए, संभवतः अधिक आधुनिक। क्या संभावना है कि एक नया दृष्टिकोण जोड़ने से समीक्षा की जाएगी?

मेरे हाल के अतीत में, मुझे कई बार टिप्पणियां मिलीं जैसे "हमारे पास पहले से ही एक सिद्ध मार्ग है, इसका उपयोग करें" और "यदि आप एक नया दृष्टिकोण लागू करना चाहते हैं, तो उन सभी 120 स्थानों पर कोड को अपडेट करें जहां पुराने दृष्टिकोण का उपयोग किया गया है और उन सभी टीमों से अपडेट प्राप्त करें जो इसके लिए जिम्मेदार हैं। कोड के ये टुकड़े। " आमतौर पर "इनोवेटर" का उत्साह यहाँ समाप्त होता है।

और कितना, आपकी राय में, क्या एक नई प्रोग्रामिंग भाषा में एक नई सेवा लिखने के लिए लागत आएगी? रिपॉजिटरी में - बिल्कुल नहीं। आप एक नया भंडार बनाते हैं और लिखते हैं, और यहां तक ​​कि सबसे उपयुक्त निर्माण प्रणाली भी लेते हैं। और अब मोनोरेपोजिटरी में भी यही बात है?

मैं पूरी तरह से अच्छी तरह से समझता हूं कि "मानकीकरण, पुन: उपयोग, कोड साझाकरण", लेकिन परियोजना विकसित की जानी चाहिए। मेरी व्यक्तिपरक राय में, एक मोनोरेपोज़िटरी इसे रोकता है।

10) खुला स्रोत

हाल ही में मुझसे पूछा गया था: " क्या मोनो-रिपॉजिटरी के लिए खुले स्रोत उपकरण हैं? " मैंने उत्तर दिया: "समस्या यह है कि मोनो-रिपॉजिटरी के लिए उपकरण, विचित्र रूप से पर्याप्त हैं, मोनो-रिपॉजिटरी के अंदर ही विकसित होते हैं। इसलिए, उन्हें खुले स्रोत में रखना काफी मुश्किल है! ”

एक उदाहरण के लिए, Intellij IDEA के लिए bazel प्लगइन के साथ Github पर एक परियोजना देखें। Google ने अपने आंतरिक भंडार में इसे विकसित किया है, और फिर इसे जीथब पर "इतिहास से बाहर" अलग कर दिया है, जिसमें एक पुर्न अनुरोध भेजने की क्षमता के बिना प्रतिबद्ध इतिहास का नुकसान है, और इसी तरह। मुझे नहीं लगता कि यह खुला स्रोत है (यहां मेरे छोटे पीआर का एक उदाहरण है, जो विलय के बजाय बंद हो गया था, और फिर अगले संस्करण में बदलाव दिखाई दिए)। वैसे, इस तथ्य का उल्लेख मूल लेख में किया गया था कि मोनो-रिपॉजिटरी उन्हें ओपन-सोर्स में पोस्ट करने और प्रोजेक्ट के आसपास एक समुदाय बनाने से रोकते हैं। मुझे लगता है कि कई लोगों ने इस तर्क को ज्यादा महत्व नहीं दिया।

विकल्प

खैर, अगर हम बात करें कि इन सभी समस्याओं से बचने के लिए क्या किया जाए? एक सलाह है - जितना संभव हो उतना छोटा भंडार का प्रयास करें।
लेकिन मोनोरेपोजिटरी का इससे क्या लेना-देना है? और भले ही यह दृष्टिकोण आपको छोटे, हल्के और स्वतंत्र भंडार रखने के अवसर से वंचित करता है।

पॉलीप्रॉपेटरी दृष्टिकोण के नुकसान क्या हैं? मुझे ठीक 1 दिखाई देता है: आपके API का उपभोक्ता कौन है, इस पर नज़र रखने में असमर्थता। यह विशेष रूप से माइक्रोसोर्सेज "शेयर नथिंग" में दृष्टिकोण के बारे में सच है, जिसमें कोड माइक्रोसेर्विस के बीच फंबल नहीं है। (वैसे, क्या आपको लगता है कि कोई भी मोनो-रिपॉजिटरी में इस दृष्टिकोण का उपयोग करता है?) दुर्भाग्य से, इस समस्या को या तो संगठनात्मक साधनों से हल करने की आवश्यकता है, या कोड ब्राउज़िंग टूल का उपयोग करने की कोशिश करें जो स्वतंत्र रिपॉजिटरी का समर्थन करते हैं (उदाहरण के लिए, https://sourcegod.com) / ) है।

"हमने पॉलीप्रॉपिटरीज़ की कोशिश की जैसे टिप्पणियों के बारे में क्या है , लेकिन फिर हमें लगातार कई रिपॉजिटरी में सुविधाओं को लागू करना पड़ा, जो थकाऊ था, और हमने सब कुछ एक बॉयलर में मिला दिया" ? इसका उत्तर बहुत सरल है: "अनुचित अपघटन के साथ दृष्टिकोण की समस्याओं को भ्रमित न करें । " कोई भी दावा नहीं करता है कि रिपॉजिटरी में बिल्कुल एक माइक्रोसेवा होनी चाहिए और वह यह है। जब मैं पॉलीप्रॉपिटरीज़ का उपयोग कर रहा था, तो हमने पूरी तरह से निकट संबंधी माइक्रोसर्विस के एक परिवार को एक रिपॉजिटरी में डाल दिया। फिर भी, यह ध्यान में रखते हुए कि 100 से अधिक सेवाएं थीं, 20 से अधिक ऐसे भंडार थे। अपघटन के संदर्भ में सोचने के लिए सबसे महत्वपूर्ण बात यह है कि इन सेवाओं को कैसे तैनात किया जाएगा।

लेकिन संस्करण के बारे में क्या तर्क है? सब के बाद, मोनो-रिपॉजिटरी आपको कोई संस्करण नहीं देने और एक प्रतिबद्ध से सब कुछ तैनात करने की अनुमति देती है! सबसे पहले, यहाँ सभी समस्याओं में से सबसे सरल संस्करण है। मावेन जैसी पुरानी चीज़ में भी एक मावेन-संस्करण-प्लगइन है जो आपको केवल एक क्लिक के साथ संस्करण को डाउनग्रेड करने की अनुमति देता है। और दूसरी बात, और सबसे महत्वपूर्ण बात, क्या आपकी कंपनी के पास मोबाइल एप्लिकेशन हैं? यदि ऐसा है, तो आपके पास पहले से ही संस्करण हैं, और आपको इससे कहीं भी नहीं मिलेगा!

खैर, अभी भी मोनो-रिपॉजिटरी के समर्थन में मुख्य तर्क है - यह आपको एक प्रतिबद्ध में कोड बेस भर में रिफैक्टिंग करने की अनुमति देता है! वास्तव में, नहीं। जैसा कि मूल लेख में उल्लेख किया गया है, उन सीमाओं के कारण जो तैनाती को लगाती है। आपको हमेशा ध्यान रखना चाहिए कि लंबे समय तक (अवधि इस बात पर निर्भर करती है कि आपकी प्रक्रिया कैसे बनाई गई है) आपके पास समानांतर में एक ही सेवा के 2 संस्करण होंगे। उदाहरण के लिए, मेरी अंतिम परियोजना पर, हमारी प्रणाली प्रत्येक तैनाती पर कई घंटों के लिए इस स्थिति में थी। यह इस तथ्य की ओर जाता है कि एक मोनो-रिपॉजिटरी में भी, एक ही प्रतिबद्ध में बातचीत के इंटरफेस को प्रभावित करने वाले वैश्विक रिफ्लेक्टरिंग का संचालन करना असंभव है।

निष्कर्ष के बजाय:

तो, उन सम्मानित और कुछ सहयोगियों को जो Google, फेसबुक आदि में काम करते हैं। और उनके मोनो-रिपॉजिटरी का बचाव करने के लिए यहां आया हूं, मैं कहना चाहता हूं: "आप चिंता न करें, आप सब कुछ ठीक कर रहे हैं, अपनी ट्यूनिंग का आनंद लें, जो सैकड़ों या लाखों मानव घंटे बिताए थे। वे पहले ही खर्च किए जा चुके हैं, इसलिए यदि आप उपयोग नहीं करते हैं, तो कोई भी नहीं करेगा। "

और बाकी सभी के लिए: "आप Google नहीं हैं, मोनो-रिपॉजिटरी का उपयोग न करें!"

पुनश्च जैसा कि मूल लेख पर चर्चा करते समय रेडियो-टी पॉडकास्ट में सम्मानित बॉबुक ने कहा था: “दुनिया में ~ 20 कंपनियां हैं जो एक एकल भंडार का उपयोग कर सकती हैं। बाकी को भी कोशिश नहीं करनी चाहिए । ”