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

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

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

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

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

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

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

मैं मैट की बात के पहले भाग से सहमत हूँ:

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

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

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

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

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

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

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

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

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

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

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

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

फिर हमें इस बारे में बात करनी होगी कि हम इस स्थिति से कैसे बाहर निकलेंगे:

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

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

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

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

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

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

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

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

सबसे बड़े कट्टरपंथी कौन हैं? समर्थक:

• मोनोरेपो

• जंग

• ग़लत मतदान/दोनों

33 उपयोगकर्ताओं ने मतदान किया। 13 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com