OTUS शैक्षिक परियोजना में DevOps प्रथाओं और उपकरण पाठ्यक्रम के छात्रों के लिए लेख का अनुवाद तैयार किया गया था।

आपको एक मोनो-रिपॉजिटरी का चयन करना चाहिए, क्योंकि यह आपकी टीमों में जो व्यवहार को बढ़ावा देता है, वह पारदर्शिता और सामूहिक जिम्मेदारी है, खासकर टीमों के विकास के साथ। किसी भी मामले में, आपको टूल में निवेश करना होगा, लेकिन यह हमेशा बेहतर होता है जब डिफ़ॉल्ट व्यवहार वह व्यवहार होता है जिसे आप अपनी आज्ञाओं में देखना चाहते हैं।

हम इस बारे में क्यों बात कर रहे हैं?

मैट क्लेन ने एक लेख लिखा, "मोनोरेपोस: प्लीज़ डोन्ट!" (अनुवादक की टिप्पणी: एक हब पर अनुवाद "मोनोरेपोज़िटरीज़: कृपया नहीं करें" )। मुझे मैट पसंद है, मुझे लगता है कि वह बहुत चालाक है, और आपको उसकी बात पढ़नी चाहिए। उन्होंने मूल रूप से पोल ट्वीट किया:

अनुवाद:
इस नए साल के दिन, मैं इस बारे में बहस करूंगा कि मोनोरेपोज़िटरी कितने हास्यास्पद हैं। 2019 पर किसी का ध्यान नहीं गया। इस की भावना में, मैं आपको एक सर्वेक्षण प्रदान करता हूं। बड़े कट्टरपंथी कौन हैं? समर्थकों:
- मोनोरेपोजिटरी
- जंग
- गलत सर्वेक्षण / वे और वे दोनों

मेरा जवाब था: "मैं सचमुच इन दोनों लोगों में से हूं।" इस बारे में बात करने के बजाय कि किस प्रकार की जंग की दवा है, आइए यह पता करें कि मुझे क्यों लगता है कि वह मोनो-रिपॉजिटरी के बारे में गलत है। थोड़ा अपने बारे में। मैं शेफ सॉफ्टवेयर का सीटीओ हूं। हमारे पास लगभग 100 इंजीनियर हैं, लगभग 11-12 साल का कोड आधार और 4 मुख्य उत्पाद हैं। इस कोड का एक हिस्सा पॉलीप्रॉपेटरी (मेरी शुरुआती स्थिति) में है, मोनोरेपोजिटरी (मेरी वर्तमान स्थिति) में हिस्सा है।

इससे पहले कि मैं आरंभ करूं: मेरे द्वारा यहां लाए गए प्रत्येक तर्क को दोनों प्रकार के रिपॉजिटरी पर लागू किया जाएगा। मेरी राय में, कोई तकनीकी कारण नहीं है कि आपको एक या दूसरे प्रकार के भंडार का चयन क्यों करना चाहिए। आप कोई भी कार्य कर सकते हैं। मुझे इस बारे में बात करने में खुशी हो रही है, लेकिन मुझे कृत्रिम तकनीकी कारणों में कोई दिलचस्पी नहीं है कि एक दूसरे से बेहतर क्यों है।

मैं मैट के दृष्टिकोण के पहले भाग से सहमत हूँ:

क्योंकि बड़े पैमाने पर, मोनोरेपोज़िटरी सभी समान समस्याओं को हल करेगा जो पॉलीप्रॉपेटरी भी हल करती है, लेकिन साथ ही साथ आपको अपने कोड के मजबूत सुसंगतता के लिए उकसाती है और आपके संस्करण प्रणाली के स्केलेबिलिटी को बढ़ाने के लिए अविश्वसनीय प्रयासों की आवश्यकता होती है।

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

मुझे लगता है कि मैट का तर्क कई इंजीनियरों (और प्रबंधकों) द्वारा साझा किए गए विचारों के समान है जिसका मैं सम्मान करता हूं। यह घटक पर काम करने वाले इंजीनियर, या घटक पर काम करने वाली टीम के दृष्टिकोण से होता है। आप इस तरह की बातें सुनते हैं:

• कोड आधार बोझिल है - मुझे यह सब कचरा नहीं चाहिए।
• यह परीक्षण करना कठिन है क्योंकि मुझे इस सभी कबाड़ की जांच करनी है जिनकी मुझे आवश्यकता नहीं है।
• बाहरी निर्भरता के साथ काम करना अधिक कठिन है।
• मुझे अपने स्वयं के वर्चुअल संस्करण नियंत्रण प्रणालियों की आवश्यकता है।

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

यह संचार को उत्तेजित करता है और समस्याओं को दिखाता है।

जब हम रिपॉजिटरी साझा करते हैं, तो हम वास्तव में एक समन्वय और पारदर्शिता समस्या पैदा करते हैं। यह टीमों के बारे में हमारे सोचने के तरीके से मेल खाता है (विशेषकर जिस तरह से व्यक्तिगत प्रतिभागी उनके बारे में सोचते हैं): हम एक विशेष घटक के लिए जिम्मेदार हैं। हम सापेक्ष अलगाव में काम करते हैं। सीमाएं मेरी टीम और उस घटक (एस) पर तय की जाती हैं, जिस पर हम काम कर रहे हैं।

वास्तुकला की जटिलता के साथ, एक टीम अब इसे अकेले प्रबंधित नहीं कर सकती है। बहुत कम इंजीनियर पूरी व्यवस्था को अपने सिर में रखते हैं। मान लीजिए कि आप एक सामान्य घटक ए को नियंत्रित करते हैं, जिसका उपयोग कमांड बी, सी और डी। टीम ए रिफैक्टोर्स द्वारा किया जाता है, एपीआई में सुधार करता है, और आंतरिक कार्यान्वयन को भी बदलता है। परिणामस्वरूप, परिवर्तन पीछे की ओर असंगत हैं। आप क्या सलाह देंगे?

• उन सभी स्थानों का पता लगाएं जहां पुराने एपीआई का उपयोग किया जाता है।
• क्या ऐसे स्थान हैं जहाँ नए API का उपयोग नहीं किया जा सकता है?
• क्या आप यह सुनिश्चित करने के लिए अन्य घटकों को ठीक कर सकते हैं और परीक्षण कर सकते हैं कि वे नहीं टूटे?
• क्या ये टीमें अभी आपके परिवर्तनों की जांच कर सकती हैं?

कृपया ध्यान दें कि ये प्रश्न रिपॉजिटरी के प्रकार से स्वतंत्र हैं। आपको टीम बी, सी और डी खोजने की आवश्यकता होगी। आपको उनसे बात करने, समय का पता लगाने, उनकी प्राथमिकताओं को समझने की आवश्यकता होगी। कम से कम हमें उम्मीद है कि आप इसे करेंगे।

कोई भी वास्तव में ऐसा नहीं करना चाहता है। यह लानत एपीआई को ठीक करने की तुलना में बहुत कम मजेदार है। यह सब मानव और भ्रमित है। रिपॉजिटरी में, आप केवल परिवर्तन कर सकते हैं, उन लोगों को एक समीक्षा दे सकते हैं जो इस घटक पर काम कर रहे हैं (शायद बी, सी या डी नहीं), और आगे बढ़ें। टीम बी, सी, और डी बस अपने वर्तमान संस्करण पर रह सकते हैं। जब वे आपकी प्रतिभा का एहसास करेंगे तो उन्हें अपडेट किया जाएगा!

एकल रिपॉजिटरी में, जिम्मेदारी डिफ़ॉल्ट रूप से स्थानांतरित हो जाती है। टीम ए अपने घटक को बदल देती है और, यदि सावधान नहीं है, तो तुरंत बी, सी और डी को तोड़ता है। इससे बी, सी और डी दरवाजे ए पर दिखाई देते हैं, यह सोचकर कि टीम ए ने विधानसभा क्यों तोड़ी। यह A को सिखाता है कि वे मेरी सूची को ऊपर छोड़ नहीं सकते। उन्हें इस बारे में बात करनी चाहिए कि वे क्या करने जा रहे हैं। क्या B, C और D चल सकते हैं? क्या होगा यदि बी और सी, लेकिन डी पुराने एल्गोरिथ्म के साइड इफेक्ट से निकटता से संबंधित था?

फिर हमें इस बारे में बात करने की आवश्यकता है कि हम इस स्थिति से कैसे बाहर निकलते हैं:

1. कई आंतरिक एपीआई के लिए समर्थन, जबकि पुराने एल्गोरिथ्म को अप्रचलित चिह्नित किया जाएगा जब तक कि डी इसका उपयोग करना बंद नहीं कर सकता।
2. रिलीज के कई संस्करणों के लिए समर्थन, एक पुराने इंटरफ़ेस के साथ, एक नए के साथ।
3. बी, सी और डी दोनों तक ए को परिवर्तन जारी करने में देरी इसे स्वीकार कर सकती है।

मान लीजिए कि हम 1, कई एपीआई का चयन करते हैं। इस मामले में, हमारे पास कोड के दो टुकड़े हैं। पुराना और नया। कुछ स्थितियों में बहुत आसान है। हम पुराने कोड को वापस लौटाते हैं, इसे चिह्नित करते हैं और डी कमांड के साथ इसे हटाने के लिए एक अनुसूची पर सहमत होते हैं। यह अनिवार्य रूप से पाली के लिए और मोनोरेपोजिटरी के लिए समान है।

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

अंत में, हम तीसरे बिंदु पर पहुंच गए। देरी जारी करें। यह संभव है कि ए द्वारा किए गए परिवर्तनों से टीम ए के जीवन में सुधार होगा। यह महत्वपूर्ण है, लेकिन तत्काल नहीं। क्या हम बस पकड़ सकते हैं? रिपॉजिटरी में, हम कलाकृतियों को मजबूत करने के लिए इसे आगे बढ़ा रहे हैं। बेशक, हम इस टीम डी के बारे में बात कर रहे हैं। बस पुराने संस्करण पर बने रहें जब तक आप पकड़ नहीं लेते! यह एक कायर खेल सेट करता है। टीम ए अपने घटक पर काम करना जारी रखती है, इस तथ्य की अनदेखी करते हुए कि टीम डी एक तेजी से पुराने संस्करण का उपयोग कर रही है (यह टीम डी के लिए एक समस्या है, वे बेवकूफ हैं)। इस बीच, टीम डी कोड स्थिरता के प्रति टीम ए के लापरवाह रवैये के बारे में बुरी तरह से बात कर रहा है, अगर वे इसके बारे में बात करते हैं। महीनों बीत जाते हैं। अंत में, डी टीम अपग्रेड विकल्प पर एक नज़र डालने का फैसला करती है, लेकिन ए में केवल अधिक परिवर्तन होते हैं। टीम A को मुश्किल से याद है कि उन्होंने कब और कैसे डी को तोड़ा। अपडेट करना अधिक दर्दनाक है और इसमें अधिक समय लगेगा। जो इसे प्राथमिकता स्टैक के नीचे भेजता है। उस दिन तक, जब तक कि हमें ए में सुरक्षा समस्या नहीं है, जो हमें एक शाखा बनाने के लिए मजबूर करती है। टीम ए को समय पर वापस जाना चाहिए, उस क्षण को ढूंढें जब डी स्थिर था, वहां समस्या को ठीक करें और इसे रिलीज के लिए तैयार करें। यह एक वास्तविक विकल्प है जिसे लोग बनाते हैं, और यह अब तक का सबसे बुरा है। यह टीम ए और डी दोनों के लिए अच्छा लगता है, जब तक हम एक दूसरे को नजरअंदाज कर सकते हैं।

मोनोरेपोज़िटरी में, तीसरा वास्तव में एक विकल्प नहीं है। आपको दो में से एक तरीके से स्थिति से निपटने के लिए मजबूर किया जाता है। आपको दो रिलीज़ शाखाएँ होने की लागतों को देखना होगा। जानें कि कैसे अपने आप को उन अपडेट से बचाएं जो पिछड़ी अनुकूलता को तोड़ते हैं। लेकिन मुख्य बात: आप एक कठिन बातचीत से बच नहीं सकते।

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

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