अभ्यासक्रमाच्या विद्यार्थ्यांसाठी तयार केलेल्या लेखाचे भाषांतर "DevOps सराव आणि साधने" OTUS शैक्षणिक प्रकल्पात.

तुम्ही एक मोनोरेपॉझिटरी निवडली पाहिजे कारण ती तुमच्या कार्यसंघांमध्ये ज्या वर्तनाला प्रोत्साहन देते ती पारदर्शकता आणि सामायिक जबाबदारी आहे, विशेषत: संघ वाढत असताना. कोणत्याही प्रकारे, तुम्हाला टूलींगमध्ये गुंतवणूक करावी लागेल, परंतु डीफॉल्ट वर्तन हे तुमच्या आज्ञांमध्ये तुम्हाला हवे असलेले वर्तन असेल तर ते केव्हाही चांगले.

आम्ही याबद्दल का बोलत आहोत?

मॅट क्लेन यांनी लेख लिहिला "मोनोरेपोस: कृपया करू नका!"  (अनुवादकाची टीप: Habré वर भाषांतर "मोनोरेपॉजिटरीज: कृपया करू नका"). मला मॅट आवडतो, मला वाटते की तो खूप हुशार आहे आणि तुम्ही त्याचा दृष्टिकोन वाचला पाहिजे. त्यांनी मूलतः ट्विटरवर मतदान पोस्ट केले:

भाषांतरः
या नवीन वर्षाच्या दिवशी, मी किती हास्यास्पद monorepositories आहेत याबद्दल वाद घालणार आहे. 2019 शांतपणे सुरू झाला. या भावनेने, मी तुम्हाला एक सर्वेक्षण ऑफर करतो. मोठे धर्मांध कोण आहेत? समर्थक:
- मोनोरेपो
- गंज
- चुकीचे मतदान / दोन्ही

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

मी सुरू करण्यापूर्वी: मी येथे केलेला प्रत्येक युक्तिवाद दोन्ही प्रकारच्या भांडारांना लागू होईल. माझ्या मते, तुम्ही एक प्रकारचा भांडार दुसऱ्या प्रकारावर का निवडला पाहिजे याचे कोणतेही तांत्रिक कारण नाही. तुम्ही कोणत्याही दृष्टिकोनातून काम करू शकता. मला याबद्दल बोलण्यात आनंद वाटतो, परंतु एक दुसऱ्यापेक्षा श्रेष्ठ का आहे या कृत्रिम तांत्रिक कारणांमध्ये मला स्वारस्य नाही.

मी मॅटच्या मुद्द्याच्या पहिल्या भागाशी सहमत आहे:

कारण स्केलवर, पॉलीरेपॉजिटरी सोडवणाऱ्या सर्व समस्यांचे निराकरण मोनोरेपॉझिटरी करते, परंतु त्याच वेळी तुम्हाला तुमचा कोड घट्ट जोडण्यासाठी भाग पाडते आणि तुमच्या आवृत्ती नियंत्रण प्रणालीची स्केलेबिलिटी वाढवण्यासाठी अविश्वसनीय प्रयत्नांची आवश्यकता असते.

तुम्ही मोनोरेपॉजिटरी किंवा पॉलीरेपॉजिटरी निवडले तरीही तुम्हाला समान समस्या सोडवाव्या लागतील. तुम्ही रिलीझ कसे सोडता? अद्यतनांसाठी तुमचा दृष्टीकोन काय आहे? मागास सहत्वता? क्रॉस प्रकल्प अवलंबित्व? कोणत्या स्थापत्य शैली स्वीकार्य आहेत? तुम्ही तुमची बिल्ड आणि टेस्ट इन्फ्रास्ट्रक्चर कशी व्यवस्थापित करता? यादी न संपणारी आहे. आणि जसजसे तुम्ही वाढता तसतसे तुम्ही ते सर्व सोडवाल. फ्री चीज नाही.

मला वाटते की मॅटचा युक्तिवाद अनेक अभियंत्यांनी (आणि व्यवस्थापकांनी) शेअर केलेल्या मतांसारखाच आहे ज्यांचा मी आदर करतो. हे घटकावर काम करणाऱ्या अभियंता किंवा घटकावर काम करणाऱ्या संघाच्या दृष्टीकोनातून उद्भवते. तुम्ही अशा गोष्टी ऐकता:

• कोडबेस भारी आहे - मला या सर्व जंकची गरज नाही.
• चाचणी करणे कठीण आहे कारण मला या सर्व जंकची चाचणी घ्यावी लागेल ज्याची मला गरज नाही.
• बाह्य अवलंबनांसह कार्य करणे अधिक कठीण आहे.
• मला माझी स्वतःची आभासी आवृत्ती नियंत्रण प्रणाली हवी आहे.

अर्थात हे सर्व मुद्दे न्याय्य आहेत. हे दोन्ही प्रकरणांमध्ये घडते - पॉलीरेपॉजिटरीमध्ये माझ्याकडे माझ्या स्वत:चे जंक आहे, बिल्डसाठी आवश्यक असलेल्या व्यतिरिक्त... मला इतर जंकची देखील आवश्यकता असू शकते. म्हणून मी "फक्त" साधने तयार करतो जी संपूर्ण प्रकल्प तपासते. किंवा मी सबमॉड्यूल्ससह बनावट मोनोरेपॉझिटरी तयार करतो. आम्ही दिवसभर याभोवती फिरू शकतो. परंतु मला वाटते की मॅटच्या युक्तिवादाचे मुख्य कारण चुकले आहे, जे मी मोनोरेपॉझिटरीच्या बाजूने जोरदारपणे फ्लिप केले:

हे संप्रेषण भडकवते आणि समस्या दर्शवते

जेव्हा आम्ही भांडार वेगळे करतो, तेव्हा आम्ही समन्वय आणि पारदर्शकतेची वास्तविक समस्या निर्माण करतो. हे आम्ही संघांबद्दल विचार करण्याच्या पद्धतीशी संबंधित आहे (विशेषतः वैयक्तिक सदस्य त्यांच्याबद्दल ज्या प्रकारे विचार करतात): आम्ही एका विशिष्ट घटकासाठी जबाबदार आहोत. आम्ही सापेक्ष अलगावमध्ये काम करतो. माझ्या कार्यसंघावर आणि आम्ही ज्या घटकांवर काम करत आहोत त्यावर सीमा निश्चित केल्या आहेत.

आर्किटेक्चर अधिक क्लिष्ट होत असल्याने, एक संघ यापुढे ते एकट्याने व्यवस्थापित करू शकत नाही. फार कमी अभियंत्यांच्या डोक्यात संपूर्ण यंत्रणा असते. समजा तुम्ही सामायिक केलेला घटक A व्यवस्थापित करा जो टीम B, C आणि D द्वारे वापरला जातो. टीम A रिफॅक्टरिंग करत आहे, API सुधारत आहे आणि अंतर्गत अंमलबजावणी देखील बदलत आहे. परिणामी, बदल मागे सुसंगत नाहीत. तुम्हाला काय सल्ला आहे?

• जुने API वापरलेले सर्व ठिकाणे शोधा.
• नवीन API वापरता येणार नाही अशी काही ठिकाणे आहेत का?
• इतर घटक तुटणार नाहीत याची खात्री करण्यासाठी तुम्ही त्यांचे निराकरण आणि चाचणी करू शकता का?
• हे संघ आत्ता तुमच्या बदलांची चाचणी घेऊ शकतात का?

कृपया लक्षात घ्या की हे प्रश्न रेपॉजिटरी प्रकारापासून स्वतंत्र आहेत. तुम्हाला 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 निवडले आहेत. या प्रकरणात आमच्याकडे कोडचे दोन तुकडे आहेत. जुने आणि नवीन. काही परिस्थितींमध्ये अगदी सोयीस्कर. आम्ही जुना कोड पुन्हा तपासतो, तो नापसंत म्हणून चिन्हांकित करतो आणि डी टीमसोबत पॉली आणि मोनो रिपॉझिटरीजसाठी एकसारखेच काढण्याच्या वेळापत्रकावर सहमती दर्शवतो.

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

शेवटी, आम्ही तिसऱ्या मुद्द्यावर पोहोचलो. प्रकाशन विलंब. हे शक्य आहे की A ने केलेले बदल टीम A चे जीवन सुधारतील. महत्वाचे, परंतु तातडीचे नाही. आपण उशीर करू शकतो का? पॉलीरेपॉजिटरीमध्ये, आम्ही आर्टिफॅक्ट पिन करण्यासाठी हे पुश करतो. अर्थात आम्ही हे टीम डी ला सांगत आहोत. तुम्ही समजेपर्यंत जुन्या आवृत्तीवर रहा! हे तुम्हाला भ्याड खेळण्यासाठी सेट करते. टीम डी अधिक कालबाह्य आवृत्ती वापरत आहे याकडे दुर्लक्ष करून, टीम ए त्यांच्या घटकावर कार्य करणे सुरू ठेवते (ती टीम डीची समस्या आहे, ते मूर्ख आहेत). दरम्यान, टीम डी, कोड स्थिरतेबद्दल टीम अ च्या निष्काळजी वृत्तीबद्दल वाईट बोलतो, जर ते याबद्दल अजिबात बोलत असतील. महिने जातात. शेवटी, टीम डी अपडेटची शक्यता पाहण्याचा निर्णय घेते, परंतु A मध्ये फक्त अधिक बदल आहेत. टीम A त्यांनी D कधी किंवा कसा तोडला हे फारसे आठवत नाही. अपग्रेड अधिक वेदनादायक आहे आणि जास्त वेळ लागेल. जे त्यास प्राधान्य स्टॅकच्या खाली पाठवते. ज्या दिवसापर्यंत आम्हाला A मध्ये सुरक्षा समस्या आहे जी आम्हाला शाखा बनवण्यास भाग पाडते. टीम A ने वेळेत परत जाणे आवश्यक आहे, D स्थिर असताना एक बिंदू शोधणे आवश्यक आहे, तेथे समस्येचे निराकरण करणे आणि रिलीजसाठी तयार करणे आवश्यक आहे. ही लोकांची वास्तविक निवड आहे आणि ती सर्वात वाईट आहे. जोपर्यंत आपण एकमेकांकडे दुर्लक्ष करू शकतो तोपर्यंत टीम ए आणि टीम डी दोघांसाठी हे चांगले आहे असे दिसते.

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

माझ्या अनुभवानुसार, जेव्हा संघ मोठे होतात, तेव्हा संपूर्ण प्रणाली लक्षात ठेवणे यापुढे शक्य नाही आणि हा सर्वात महत्त्वाचा भाग आहे. तुम्ही सिस्टीममधील मतभेदाची दृश्यमानता सुधारली पाहिजे. संघांना त्यांच्या घटकांपासून दूर जाण्यासाठी आणि इतर संघ आणि ग्राहकांचे कार्य पाहण्यासाठी तुम्ही सक्रियपणे कार्य केले पाहिजे.

होय, तुम्ही अशी साधने तयार करू शकता जी पॉलीरेपॉझिटरी समस्येचे निराकरण करण्याचा प्रयत्न करतात. परंतु मोठ्या उद्योगांमध्ये सतत वितरण आणि ऑटोमेशन शिकवण्याचा माझा अनुभव मला हे सांगतो: अतिरिक्त साधनांचा वापर न करता डीफॉल्ट वर्तन हे तुम्हाला अपेक्षित असलेले वर्तन आहे. पॉलीरेपॉजिटरी चे डीफॉल्ट वर्तन अलगाव आहे, हा संपूर्ण मुद्दा आहे. मोनोरेपॉझिटरी चे डीफॉल्ट वर्तन म्हणजे सामायिक जबाबदारी आणि पारदर्शकता, हाच संपूर्ण मुद्दा आहे. दोन्ही प्रकरणांमध्ये, मी एक साधन तयार करणार आहे जे खडबडीत कडा गुळगुळीत करेल. एक नेता म्हणून, मी प्रत्येक वेळी एक मोनोरेपॉझिटरी निवडेन कारण मला हवी असलेली संस्कृती मजबूत करण्यासाठी साधनांची आवश्यकता असते आणि संस्कृती लहान निर्णय आणि संघाच्या दैनंदिन कामातून येते.

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

सर्वात मोठे धर्मांध कोण आहेत? समर्थक:

• मोनोरेपो

• गंज

• चुकीचे मतदान / दोन्ही

33 वापरकर्त्यांनी मतदान केले. 13 वापरकर्ते दूर राहिले.

स्त्रोत: www.habr.com