अनुवादक से: नमस्कार, हेब्रा! हां, यह मोनोरेपोज़िटरी के फायदे और नुकसान के बारे में एक और लेख है। मैं अपना लेख लिखने जा रहा हूं कि हम मोनो-रिपॉजिटरी का उपयोग कैसे करते हैं, हमने मावेन से बाज़ल में कैसे स्विच किया और इसके बारे में क्या आया। लेकिन जब मैं इसके बारे में सोच रहा था, तो Lyft के डेवलपर का एक उत्कृष्ट लेख सामने आया, जिसे मैंने आपके लिए अनुवाद करने का फैसला किया। मैं लेख के साथ अपने परिवर्धन को प्रकाशित करने का वादा करता हूं, साथ ही अगली कड़ी के रूप में बाजेल के साथ अनुभव भी।
हम नए 2019 वर्ष में हैं, और मैं "मोनोरेपोज़िटरी" में सभी संगठन के स्रोत कोड को संग्रहीत करने में फायदे (या इसके अभाव) के बारे में एक और चर्चा के लिए तैयार हूं। आप में से जो इस दृष्टिकोण से परिचित नहीं हैं, उनके लिए विचार यह है कि संस्करण नियंत्रण प्रणाली के एकल भंडार में सभी स्रोत कोड को संग्रहीत किया जाए। एक विकल्प, ज़ाहिर है, कई स्वतंत्र रिपॉजिटरी में स्रोत कोड को स्टोर करना है, आमतौर पर उन्हें सेवाओं / अनुप्रयोगों या पुस्तकालयों की सीमा के साथ विभाजित करना है।
इस पोस्ट में, मैं इस दृष्टिकोण को "पॉलीप्रॉपेटरी" कहूंगा।
कुछ आईटी दिग्गज Google, फेसबुक, ट्विटर और अन्य सहित मोनो-रिपॉजिटरी का उपयोग करते हैं। बेशक, अगर ऐसी प्रतिष्ठित कंपनियां मोनो-रिपॉजिटरी का उपयोग करती हैं, तो इस दृष्टिकोण का लाभ बहुत बड़ा होना चाहिए, और हम सभी को भी ऐसा ही करना चाहिए, है ना? नहीं! जैसा कि लेख का शीर्षक कहता है: "कृपया मोनो-रिपॉजिटरी का उपयोग न करें!" क्यों? क्योंकि
बड़े पैमाने पर, मोनोरेपोज़िटरी सभी समान समस्याओं को हल करेगी जो पॉलीप्रॉपेटरी हल करती है, लेकिन साथ ही साथ आपको अपने कोड के मजबूत सुसंगतता के लिए उकसाती है और आपके संस्करण सिस्टम सिस्टम की स्केलेबिलिटी को बढ़ाने के लिए अविश्वसनीय प्रयासों की आवश्यकता होती है ।
इस प्रकार, मध्यम और दीर्घकालिक में, मोनो-रिपॉजिटरी कोई संगठनात्मक लाभ प्रदान नहीं करता है, जबकि यह पोस्ट-ट्रूमैटिक सिंड्रोम के साथ कंपनी के सर्वश्रेष्ठ इंजीनियरों को छोड़ देता है (ड्रॉपिंग और असंगत म्यूटिंग के रूप में प्रकट होता है)।
लघु विषयांतर: मुझे "बड़े पैमाने पर" से क्या मतलब है? इस सवाल का एक भी जवाब नहीं है, लेकिन क्योंकि मुझे यकीन है कि आप मुझसे इस बारे में पूछेंगे, मान लीजिए कि लगभग 100 डेवलपर्स हैं जो पूर्णकालिक कोड लिखते हैं।
एक मोनोरेपोज़िटरी के सैद्धांतिक लाभ और वे पॉलीरेज़िटरीज (या परफेक्ट) के लिए उपयोग किए जाने वाले उपकरणों के बिना क्यों हासिल नहीं किए जा सकते हैं
सैद्धांतिक लाभ 1: आसान सहयोग और कोड साझा करना
मोनो-रिपॉजिटरी के समर्थकों का दावा है कि जब सभी कोड एक ही रिपॉजिटरी में होते हैं, तो कोड के डुप्लिकेट होने की संभावना कम होती है, और यह अधिक संभावना है कि विभिन्न टीमें एक समान बुनियादी ढाँचे पर एक साथ काम करेंगी।
यहां मध्यम-आकार के मोनो-रिपॉजिटरी के बारे में कड़वा सच है (और यह इस खंड में लगातार ध्वनि करेगा): यह जल्दी से एक डेवलपर के लिए अव्यवहारिक हो जाता है कि वह अपने वर्कस्टेशन पर सभी रिपॉजिटरी कोड को रखे या जीआरपी जैसी क्षमताओं का उपयोग करके पूरे कोड बेस को खोजे। इसलिए, कोई भी मोनो-रिपॉजिटरी जो स्केल करना चाहता है उसे 2 चीजें प्रदान करनी चाहिए:
1) एक वर्चुअल फाइल सिस्टम की तरह कुछ है जो आपको स्थानीय रूप से कोड का केवल एक हिस्सा स्टोर करने की अनुमति देता है। यह Google के आंतरिक
G3 टूल या Microsoft के
GVFS का उपयोग करके, इस मोड को मूल रूप से समर्थन करने वाली
Perforce जैसी एक स्वामित्व फ़ाइल प्रणाली का उपयोग करके प्राप्त किया जा सकता है।
2) स्रोत कोड के अनुक्रमण / खोज / देखने के लिए सेवा के रूप में परिष्कृत उपकरण (सेवा के रूप में)। क्योंकि कोई भी डेवलपर्स अपने वर्कस्टेशन पर सभी स्रोत कोड को खोज योग्य स्थिति में संग्रहीत नहीं करने जा रहा है, यह कोड आधार पर इस तरह की खोज को संचालित करने में सक्षम होने के लिए महत्वपूर्ण हो जाता है।
इस तथ्य के आधार पर कि डेवलपर को किसी भी समय स्रोत कोड के केवल एक छोटे हिस्से तक पहुंच प्राप्त होगी, क्या मोनो-रिपॉजिटरी के एक हिस्से को डाउनलोड करने या कई स्वतंत्र रिपॉजिटरी डाउनलोड करने के बीच कम से कम कुछ अंतर है?
कोई फर्क नहीं है ।
अनुक्रमण / खोज / ब्राउज़िंग और समान कोड के संदर्भ में, इस तरह के काल्पनिक उपकरण आसानी से कई रिपॉजिटरी खोज सकते हैं और परिणाम को जोड़ सकते हैं। वास्तव में, यह ठीक उसी तरह है जैसे
गिटहब पर खोज काम करती है, साथ ही साथ
सोर्सग्राफ जैसे अधिक परिष्कृत खोज और अनुक्रमण उपकरण
भी ।
इस प्रकार, बड़े पैमाने पर कोड पर सहयोगी कार्य के दृष्टिकोण से, डेवलपर्स किसी भी मामले में केवल कोड आधार के भाग के साथ काम करने और उच्च-स्तरीय टूल का उपयोग करने के लिए मजबूर होते हैं। इससे कोई फर्क नहीं पड़ता कि कोड मोनो-रिपॉजिटरी में संग्रहीत है या कई स्वतंत्र रिपॉजिटरी में, समस्या उसी तरह से हल की गई है, और
कोड पर एक साथ काम करने की
प्रभावशीलता केवल इंजीनियरिंग संस्कृति पर निर्भर करती है, और स्रोत कोड संग्रहीत करने के तरीके पर नहीं ।
सैद्धांतिक लाभ 2: एक विधानसभा / कोई निर्भरता प्रबंधन
अगला तर्क, आमतौर पर मोनो-रिपॉजिटरी के समर्थकों द्वारा उद्धृत किया जाता है, यह है कि एक एकल मोनो-रिपॉजिटरी में सभी कोड को संग्रहीत करना आपको निर्भरता को प्रबंधित करने की आवश्यकता से वंचित करता है, जैसा कि सभी कोड एक ही समय में एकत्र किए जाते हैं। यह झूठ है! बड़े पैमाने पर, सभी स्रोत कोड को फिर से बनाने और सभी स्वचालित परीक्षणों को चलाने का कोई तरीका नहीं है, जब भी कोई व्यक्ति संस्करण नियंत्रण प्रणाली में परिवर्तन करता है (या, अधिक महत्वपूर्ण बात, सीआई सर्वर पर जब एक नई शाखा या पुल अनुरोध बनाया जाता है)। इस समस्या को हल करने के लिए, सभी बड़े मोनो-रिपॉजिटरी अपने परिष्कृत बिल्ड सिस्टम (जैसे Google से
बज़ेल / ब्लेज़ या फ़ेसबुक से
बक ) का उपयोग करते हैं, जो परिवर्तनों और उनके आश्रित ब्लॉकों की निगरानी करने और स्रोत कोड की निर्भरता ग्राफ बनाने के लिए डिज़ाइन किया गया है। यह ग्राफ़ आपको असेंबली परिणाम और परीक्षणों के कुशल कैशिंग को व्यवस्थित करने की अनुमति देता है, इसलिए केवल परिवर्तन और उनकी निर्भरता को पुन: परीक्षण और परीक्षण की आवश्यकता होती है।
इसके अलावा, के बाद से एकत्र किए गए कोड को अंततः तैनात किया जाना चाहिए, और, जैसा कि आप जानते हैं, सभी सॉफ़्टवेयर को एक बार में तैनात नहीं किया जा सकता है, यह महत्वपूर्ण है कि सभी विधानसभा कलाकृतियों को नियंत्रित किया जाए, ताकि कलाकृतियों को फिर से आवश्यक रूप से फिर से बनाया जाए। संक्षेप में, इसका मतलब है कि मोनो-रिपॉजिटरी की दुनिया में भी, कोड के कई संस्करण प्रकृति में एक ही समय में मौजूद हो सकते हैं, और सावधानीपूर्वक निगरानी और समन्वयित होना चाहिए।
मोनो-रिपॉजिटरी के समर्थकों का तर्क भी होगा कि असेंबली / निर्भरता को ट्रैक करने की आवश्यकता को ध्यान में रखते हुए, यह अभी भी एक निर्विवाद लाभ प्रदान करता है, जैसा कि एक एकल वचन में पूरी दुनिया की पूर्ण स्थिति का वर्णन किया गया है। मैं कहूंगा कि यह लाभ बल्कि विवादास्पद है, यह देखते हुए कि निर्भरता ग्राफ पहले से मौजूद है, और यह इस ग्राफ के हिस्से के रूप में प्रत्येक स्वतंत्र भंडार के लिए प्रतिबद्ध पहचानकर्ता को शामिल करने के लिए बल्कि एक तुच्छ कार्य की तरह लगता है, और वास्तव में बाजेल कई स्वतंत्र रिपोजिटरी के साथ-साथ आसानी से काम कर सकता है। मोनो-रिपॉजिटरी, डेवलपर से अंतर्निहित स्तर का सार। इसके अलावा, ऐसे स्वचालित रीफैक्टरिंग टूल्स को लागू करना आसान है जो एक ही समय में कई स्वतंत्र रिपॉजिटरी में आश्रित पुस्तकालयों के संस्करणों को अपडेट करते हैं, इस भाग में मोनो-रिपॉजिटरी और पॉलीप्रॉपेटरी के बीच के अंतर को कम करते हैं (अधिक बाद में)।
अंतिम परिणाम यह है कि बड़े पैमाने पर विधानसभा / तैनाती की वास्तविकता मोनो-रिपॉजिटरी और पॉली-रिपॉजिटरी के लिए अधिकांश भाग के लिए समान हैं।
टूल्स के लिए कोई अंतर नहीं है, यह डेवलपर्स के लिए नहीं होना चाहिए कोड लिखना ।
सैद्धांतिक लाभ 3: कोड रीफैक्टरिंग एक सरल परमाणु प्रतिबद्धता है
अंत में, मोनो-रिपॉजिटरी के समर्थकों का अंतिम पुण्य तथ्य यह है कि एक रिपॉजिटरी खोज की आसानी के कारण कोड रीफैक्टरिंग को सरल बनाता है, और यह विचार कि एक एकल प्रतिबद्ध पूरे रिपॉजिटरी को पूरा कर सकता है। यह कई कारणों से सही नहीं है:
1) जैसा कि ऊपर वर्णित है, बड़े पैमाने पर, डेवलपर अपने स्थानीय मशीन पर पूरे कोड आधार को संपादित या खोज नहीं कर पाएगा। इस प्रकार, यह विचार कि कोई भी आसानी से अपने पूरे भंडार को खुद पर क्लोन कर सकता है और बस grep / प्रतिस्थापित करना इतना आसान नहीं है कि इसे अभ्यास में लाया जा सके।
2) यहां तक कि अगर हम मानते हैं कि एक जटिल वर्चुअल फाइल सिस्टम की मदद से एक डेवलपर पूरे कोड आधार को क्लोन और संपादित कर सकता है, तो यह कितनी बार होगा? मैं साझा लाइब्रेरी के कार्यान्वयन में बग को ठीक करने के बारे में बात नहीं कर रहा हूं, क्योंकि यह स्थिति एकल रिपॉजिटरी के मामले में और बहु-रिपॉजिटरी के मामले में समान रूप से नियंत्रित की जाती है (जैसा कि ऊपर वर्णित है एक समान बिल्ड / तैनाती प्रणाली,)। मैं लाइब्रेरी एपीआई को बदलने के बारे में बात कर रहा हूं, जिसके बाद उन जगहों पर कई संकलन त्रुटियों का पालन किया जाएगा जहां यह पुस्तकालय कहा जाता है। एक बहुत बड़े कोड बेस में,
मूल API में परिवर्तन करना लगभग असंभव है, जो मर्ज संघर्षों से पहले सभी शामिल टीमों द्वारा आपको फिर से प्रक्रिया शुरू करने के लिए मजबूर करेगा । डेवलपर के पास 2 वास्तविक संभावनाएं हैं: वह एपीआई के साथ समस्या के लिए वर्कअराउंड दे सकता है और आ सकता है (व्यवहार में, यह अधिक बार होता है कि हम सभी को पसंद करेंगे), या वह मौजूदा एपीआई को विक्षेपित कर सकता है, एक नया एपीआई लिख सकता है और फिर लंबे समय तक चल सकता है और पूरी तरह से कोड आधार पर पुराने एपीआई के लिए सभी कॉल को अद्यतन करता है। किसी भी मामले में,
पॉलीप्रॉपेटरी के साथ यह बिल्कुल वैसी ही प्रक्रिया है ।
3) एक सेवा-उन्मुख दुनिया में, अनुप्रयोगों में कई शिथिल युग्मित घटक होते हैं जो कुछ प्रकार के वर्णित एपीआई का उपयोग करते हुए एक दूसरे के साथ बातचीत करते हैं। बड़े संगठन जल्द या बाद में IDL (इंटरफ़ेस विवरण भाषा) का उपयोग करने के लिए स्विच करेंगे, जैसे कि थ्रिफ्ट या प्रोटोबॉफ़, जो आपको टाइप-सेफ एपीआई बनाने और पिछड़े संगत परिवर्तन करने की अनुमति देते हैं। जैसा कि विधानसभा / तैनाती पर पिछले अनुभाग में वर्णित है,
कोड एक साथ तैनात नहीं किया जा सकता है । यह समय की अवधि में तैनात किया जा सकता है: घंटे, दिन या महीने। इसलिए, डेवलपर्स को अपने परिवर्तनों की पिछड़ी संगतता के बारे में सोचना चाहिए। यह आधुनिक सॉफ्टवेयर विकास की वास्तविकता है, जिसे कई लोग नजरअंदाज करना चाहते हैं, लेकिन ऐसा नहीं कर सकते। इसलिए, जब यह सेवाओं (एपीआई पुस्तकालयों के विपरीत) की बात आती है, तो डेवलपर्स को ऊपर वर्णित दो दृष्टिकोणों में से एक का उपयोग करना चाहिए (एपीआई में बदलाव नहीं करना चाहिए या डेप्रिसिएशन चक्र के माध्यम से जाना चाहिए) और
यह मोनोरेपोजिटरी और पॉलीप्रॉपेटरी दोनों के लिए बिल्कुल समान है ।
बड़े कोडबेस रिफैक्टरिंग की बात करें तो कई बड़े संगठन हाल ही में फेसबुक द्वारा जारी किए गए
फास्टमॉड जैसे अपने स्वचालित रीफैक्टरिंग उपकरण विकसित कर रहे हैं। हमेशा की तरह, यह उपकरण आसानी से एक रिपॉजिटरी या कई स्वतंत्र लोगों के साथ काम कर सकता है। Lyft में एक "रिफ्लेक्टर" नामक एक उपकरण होता है जो बस यही करता है। यह फास्टमॉड की तरह काम करता है, लेकिन यह हमारे कई रिपॉजिटरी में परिवर्तन को स्वचालित करता है, जिसमें पुल अनुरोध बनाना, समीक्षाओं की स्थिति पर नज़र रखना आदि शामिल हैं।
Monorepositories के अनूठे नुकसान
पिछले खंड में, मैंने उन सभी सैद्धांतिक लाभों को सूचीबद्ध किया है जो एक मोनोरेपोजिटरी प्रदान करता है, और नोट किया कि उनका लाभ उठाने के लिए, अविश्वसनीय रूप से जटिल उपकरण बनाना आवश्यक है जो पॉलीप्रॉपेटरी के लिए अलग नहीं होंगे। इस खंड में, मैं मोनो-रिपॉजिटरी के 2 अद्वितीय नुकसानों का उल्लेख करूंगा।
ड्राबैक 1: मजबूत कनेक्टिविटी और ओपन सोर्स सॉफ्टवेयर
संगठनात्मक रूप से, एक monorepository कसकर युग्मित और नाजुक सॉफ़्टवेयर के निर्माण के लिए उकसाता है। यह डेवलपर्स को यह एहसास दिलाता है कि वे आसानी से अमूर्तता में त्रुटियों को ठीक कर सकते हैं, हालांकि वास्तव में वे अस्थिर असेंबली / परिनियोजन प्रक्रिया और मानव / संगठनात्मक / सांस्कृतिक कारकों के कारण नहीं कर सकते हैं जो कोड आधार पर तुरंत परिवर्तन करने की कोशिश करते समय उत्पन्न होते हैं।
Polyrepositories में कोड संरचना टीमों / परियोजनाओं / अमूर्त / कोड मालिकों के बीच स्पष्ट और पारदर्शी सीमाओं का प्रतिनिधित्व करती है और डेवलपर को इंटरैक्शन इंटरफ़ेस पर ध्यानपूर्वक विचार करने के लिए मजबूर करती है। यह एक सूक्ष्म, लेकिन बहुत महत्वपूर्ण लाभ है: यह डेवलपर्स को अधिक मोटे तौर पर और लंबी अवधि में सोचता है। इसके अलावा, बहु-रिपॉजिटरी के उपयोग का मतलब यह नहीं है कि डेवलपर्स रिपॉजिटरी की सीमाओं से परे नहीं जा सकते हैं। ऐसा होता है या नहीं, यह केवल विकास संस्कृति पर निर्भर करता है, और इस पर नहीं कि एक मोनोरेपोज़िटरी या पॉलीप्रॉपेटरी का उपयोग किया जाता है या नहीं।
मजबूत बाइंडिंग के अपने स्रोत कोड के खुलने के गंभीर परिणाम भी हैं। यदि कोई कंपनी ओपन सोर्स सॉफ़्टवेयर बनाना या उपभोग करना चाहती है, तो मल्टी-रिपॉजिटरी का उपयोग आवश्यक है। जब कोई कंपनी अपने मोनो-रिपॉजिटरी (स्रोत कोड का आयात / निर्यात, सार्वजनिक / निजी बग ट्रैकर, मानक पुस्तकालयों में अंतर को रद्द करने के लिए अतिरिक्त परतें, आदि) से खुले स्रोत में अपनी परियोजना को बाहर करने की कोशिश करती है, तो उत्पादक सहयोग नहीं होता है और महत्वपूर्ण ओवरहेड बनाने के साथ ही एक समुदाय का निर्माण।
दोष 2: संस्करण नियंत्रण प्रणाली की मापनीयता
सैकड़ों डेवलपर्स, कोड के लाखों लाइनों के लिए एक संस्करण नियंत्रण प्रणाली को स्केल करना, और आवागमन की एक बड़ी धारा एक स्मारकीय कार्य है। 5 साल पहले (git के आधार पर) बनाया गया ट्विटर मोनो-रिपॉजिटरी, मेरे करियर में देखी गई सबसे बेकार परियोजनाओं में से एक थी।
git status जैसे सरल कमांड को चलाने में
मिनट लगते हैं । यदि रिपॉजिटरी की स्थानीय प्रतिलिपि बहुत पुरानी थी, तो अपडेट में
घंटों लग सकते हैं (उस समय यह कोड के नवीनतम संस्करण के साथ दूरस्थ कर्मचारियों को रिपॉजिटरी की कॉपी के साथ हार्ड ड्राइव भेजने के लिए भी एक अभ्यास था)। मुझे याद है कि यह ट्विटर डेवलपर्स का मजाक उड़ाने के लिए नहीं है, बल्कि यह बताने के लिए है कि यह समस्या कितनी जटिल है। मैं कह सकता हूं कि 5 साल बाद, ट्विटर मोनो-रिपॉजिटरी का प्रदर्शन अभी भी उस से बहुत दूर है, जिसे टिलिंग टीम के डेवलपर्स देखना चाहेंगे, और यह इसलिए नहीं है क्योंकि उन्होंने कड़ी मेहनत की।
बेशक, पिछले 5 वर्षों में, इस क्षेत्र में कुछ विकास हुआ है। Microsoft के
Git VFS , जिसका उपयोग विंडोज़ को विकसित करने के लिए किया गया है, ने git के लिए एक वास्तविक वर्चुअल फ़ाइल सिस्टम के उद्भव का नेतृत्व किया है, जिसे मैंने ऊपर एक संस्करण नियंत्रण प्रणाली को स्केल करने के लिए एक पूर्वापेक्षा के रूप में वर्णित किया है (और Microsoft Github की खरीद के साथ ऐसा लगता है कि स्केलिंग का यह स्तर इसकी खोज करेगा। GiHub अपने कॉर्पोरेट ग्राहकों को प्रदान करता है कि सुविधाओं में आवेदन)। और निश्चित रूप से, Google और फेसबुक अपने आंतरिक सिस्टम में भारी संसाधनों का निवेश जारी रखते हैं ताकि वे कार्य करना जारी रखें, हालांकि यह लगभग कोई भी सार्वजनिक रूप से उपलब्ध नहीं है।
तो आपको आम तौर पर संस्करण नियंत्रण प्रणाली को स्केल करने के साथ इन समस्याओं को हल करने की आवश्यकता क्यों है, यदि, जैसा कि पिछले अनुभाग में वर्णित है, तो टूलकिट को मल्टीपोज़िटरी के लिए बिल्कुल वैसा ही होना आवश्यक है? इसका कोई वाजिब कारण नहीं है।
निष्कर्ष
जैसा कि अक्सर सॉफ़्टवेयर विकास में होता है, हम एक उदाहरण के रूप में सबसे सफल सॉफ़्टवेयर कंपनियों को देखते हैं और यह समझने के बिना कि क्या इन कंपनियों ने सफलता के लिए अपनी सर्वोत्तम प्रथाओं को उधार लेने का प्रयास किया है। मेरी राय में, मोनोरेपोज़िटरीज़ ऐसे मामले का एक विशिष्ट उदाहरण हैं। Google, फेसबुक और ट्विटर ने अपने कोड स्टोरेज सिस्टम में संसाधनों की एक बड़ी राशि का निवेश केवल एक समाधान के साथ किया है जो अनिवार्य
रूप से एक बहु-रिपॉजिटरी के लिए आवश्यक है, लेकिन मजबूत संबंध को उत्तेजित करता है और संस्करण नियंत्रण में स्केलिंग के लिए भारी निवेश की आवश्यकता होती है ।
वास्तव में, बड़े पैमाने पर, एक कंपनी कोड, सहयोग, मजबूत बंधन, आदि के साथ मिलकर कैसे काम करती है।
सीधे इंजीनियरिंग कल्चर और लीडरशिप पर निर्भर करता है और इसका इस बात से कोई लेना-देना नहीं है कि मोनोरेपोजिटरी या पॉलिपोसिटरी का इस्तेमाल किया जाता है या नहीं । दोनों समाधान डेवलपर के लिए समान दिखते हैं। तो क्यों एक monorepository का उपयोग करें?
कृपया नहीं!