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

तपाईंले एक मोनोरेपोजिटरी छनौट गर्नुपर्छ किनभने यसले तपाईंको टोलीहरूमा प्रवर्द्धन गर्ने व्यवहार पारदर्शिता र साझा जिम्मेवारी हो, विशेष गरी टोलीहरू बढ्दै जाँदा। कुनै पनि तरिकाले, तपाईंले टूलिङमा लगानी गर्नुपर्नेछ, तर यो सधैं राम्रो हुन्छ यदि पूर्वनिर्धारित व्यवहार तपाईंले आफ्नो आदेशहरूमा चाहानु भएको व्यवहार हो।

हामी किन यस बारेमा कुरा गर्दैछौं?

म्याट क्लेनले लेख लेखे "मोनोरेपोस: कृपया नगर्नुहोस्!"  (अनुवादकको नोट: Habré मा अनुवाद "Monorepositories: कृपया नगर्नुहोस्")। मलाई म्याट मन पर्छ, मलाई लाग्छ उहाँ धेरै स्मार्ट हुनुहुन्छ र तपाईंले उहाँको दृष्टिकोण पढ्नु पर्छ। उनले सुरुमा ट्विटरमा सर्वेक्षण पोस्ट गरे:

अनुवाद:
यो नयाँ वर्षको दिन, म कसरी हास्यास्पद monorepositories छन् भन्ने बारे बहस गर्न जाँदैछु। 2019 चुपचाप सुरु भयो। यसैको भावनामा, म तपाईंलाई एक सर्वेक्षण प्रस्ताव गर्दछु। को हुन् ठूला कट्टरपन्थी ? समर्थकहरू:
- मोनोरेपो
- खियाले
- गलत सर्वेक्षण / दुबै

मेरो प्रतिक्रिया थियो, "म शाब्दिक रूपमा ती दुवै व्यक्ति हुँ।" रस्ट कसरी एक औषधि हो भन्ने बारे कुरा गर्नुको सट्टा, मलाई किन मोनोरेपोजिटरीहरूको बारेमा गलत छ जस्तो लाग्छ हेरौं। आफ्नो बारेमा अलिकति। म शेफ सफ्टवेयरको CTO हुँ। हामीसँग लगभग 100 ईन्जिनियरहरू छन्, कोड आधार लगभग 11-12 वर्ष पछि जाँदैछ, र 4 मुख्य उत्पादनहरू छन्। यस कोड मध्ये केहि एक polyrepository मा छ (मेरो सुरु स्थिति), केहि एक monorepository मा छ (मेरो हालको स्थिति)।

मैले सुरु गर्नु अघि: मैले यहाँ गरेको हरेक तर्क दुवै प्रकारका भण्डारहरूमा लागू हुनेछ। मेरो विचारमा, त्यहाँ कुनै प्राविधिक कारण छैन किन तपाईंले अर्कोमा एक प्रकारको भण्डार रोज्नुपर्छ। तपाईं कुनै पनि दृष्टिकोण काम गर्न सक्नुहुन्छ। म यसको बारेमा कुरा गर्न खुसी छु, तर मलाई कृत्रिम प्राविधिक कारणहरूमा रुचि छैन किन एउटा अर्को भन्दा उच्च छ।

म म्याटको बिन्दुको पहिलो भागसँग सहमत छु:

किनभने स्केलमा, एक मोनोरेपोजिटरीले पोलीरेपोजिटरीले समाधान गर्ने सबै समान समस्याहरू समाधान गर्दछ, तर एकै समयमा तपाइँलाई तपाइँको कोडलाई कडा रूपमा जोड्न र तपाइँको संस्करण नियन्त्रण प्रणालीको स्केलेबिलिटी बढाउनको लागि अविश्वसनीय प्रयासहरू आवश्यक पर्दछ।

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

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

• कोडबेस भारी छ - मलाई यी सबै जंकको आवश्यकता छैन।
• यो परीक्षण गर्न गाह्रो छ किनभने मैले यी सबै रद्दीहरूलाई परीक्षण गर्नुपर्छ जुन मलाई आवश्यक छैन।
• बाह्य निर्भरता संग काम गर्न गाह्रो छ।
• मलाई मेरो आफ्नै भर्चुअल संस्करण नियन्त्रण प्रणाली चाहिन्छ।

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

यसले सञ्चारलाई उक्साउँछ र समस्याहरू देखाउँछ

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

वास्तुकला थप जटिल बन्दै गएपछि, एउटा टोलीले यसलाई एक्लै व्यवस्थापन गर्न सक्दैन। धेरै कम इन्जिनियरहरूको टाउकोमा सम्पूर्ण प्रणाली हुन्छ। मानौं कि तपाईले साझा कम्पोनेन्ट A व्यवस्थापन गर्नुहुन्छ जुन टोली B, C, र D द्वारा प्रयोग गरिन्छ। टोली A ले रिफ्याक्टरिंग, API सुधार गर्दै र आन्तरिक कार्यान्वयनलाई पनि परिवर्तन गर्दैछ। नतिजाको रूपमा, परिवर्तनहरू पछाडि अनुकूल छैनन्। तपाईलाई के सल्लाह छ?

• पुरानो API प्रयोग भएको सबै ठाउँहरू फेला पार्नुहोस्।
• नयाँ API प्रयोग गर्न नसकिने ठाउँहरू छन्?
• के तपाइँ ठीक गर्न सक्नुहुन्छ र अन्य कम्पोनेन्टहरू भाँच्नुहुन्न भनेर सुनिश्चित गर्न परीक्षण गर्न सक्नुहुन्छ?
• के यी टोलीहरूले अहिले तपाईंको परिवर्तनहरू परीक्षण गर्न सक्छन्?

कृपया ध्यान दिनुहोस् कि यी प्रश्नहरू भण्डार प्रकारबाट स्वतन्त्र छन्। तपाईंले B, C र D टोलीहरू फेला पार्न आवश्यक छ। तपाईंले तिनीहरूसँग कुरा गर्न, समय पत्ता लगाउन, तिनीहरूको प्राथमिकताहरू बुझ्न आवश्यक हुनेछ। कम्तिमा हामी आशा गर्छौं कि तपाईले गर्नुहुनेछ।

कोही पनि वास्तवमै यो गर्न चाहँदैनन्। यो धिक्कार API फिक्सिंग भन्दा धेरै कम रमाईलो छ। यो सबै मानव र अव्यवस्थित छ। एक polyrepository मा, तपाईं केवल परिवर्तनहरू गर्न सक्नुहुन्छ, त्यो कम्पोनेन्टमा काम गर्ने व्यक्तिहरूलाई दिनुहोस् (सम्भवतः B, C वा D) समीक्षाको लागि, र अगाडि बढ्नुहोस्। टोलीहरू B, C र D अहिलेको लागि तिनीहरूको हालको संस्करणमा रहन सक्छन्। तिनीहरू नवीकरण हुनेछन् जब तिनीहरूले तपाईंको प्रतिभा महसुस गर्छन्!

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

त्यसोभए हामीले यस अवस्थाबाट कसरी बाहिर निस्कने भनेर कुरा गर्नुपर्छ:

1. धेरै आन्तरिक API हरूका लागि समर्थन, र D ले यसलाई प्रयोग गर्न बन्द नगरेसम्म पुरानो एल्गोरिदमलाई बहिष्कृत भनी चिन्ह लगाउनेछ।
2. धेरै रिलीज संस्करणहरूको लागि समर्थन, पुरानो इन्टरफेसको साथ एक, नयाँ एक संग।
3. A को परिवर्तनहरू रिलीज गर्न ढिलाइ गर्नुहोस् जबसम्म B, C, र D ले यसलाई एकैसाथ स्वीकार गर्न सक्दैन।

मानौं हामीले 1, धेरै API हरू चयन गरेका छौं। यस अवस्थामा हामीसँग कोडको दुई टुक्राहरू छन्। पुरानो र नयाँ। केहि परिस्थितिहरूमा धेरै सुविधाजनक। हामी पुरानो कोडलाई फेरि जाँच गर्छौं, यसलाई बहिष्कृत भनी चिन्ह लगाउँछौं, र D टोलीसँग हटाउने समयतालिकामा सहमत हुन्छौं। पोली र मोनो रिपोजिटरीहरूको लागि अनिवार्य रूपमा समान।

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

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

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

मेरो अनुभवमा, जब टोलीहरू ठूला हुन्छन्, सम्पूर्ण प्रणालीलाई दिमागमा राख्न सम्भव छैन, र त्यो सबैभन्दा महत्त्वपूर्ण भाग हो। तपाईंले प्रणालीमा विवादको दृश्यता सुधार गर्नुपर्छ। टोलीहरूलाई तिनीहरूका कम्पोनेन्टहरूबाट टाढा हेर्न र अन्य टोलीहरू र उपभोक्ताहरूको काम हेर्नको लागि तपाईंले सक्रिय रूपमा काम गर्नुपर्छ।

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

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया

सबैभन्दा ठूलो कट्टरपन्थी को हो? समर्थकहरू:

• मोनोरेपो

• खियाले

• गलत सर्वेक्षण / दुबै

33 प्रयोगकर्ताहरूले मतदान गरे। 13 प्रयोगकर्ताहरू रोकिए।

स्रोत: www.habr.com