लेजर लाइव मोनोरेपो प्रोजेक्ट: भाग 1 - समस्याएँ (इसे कष्टकारी बनाएँ) | खाता बही

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

थोड़ा इतिहास 

2020 और 2021 में लेजर की वृद्धि महत्वपूर्ण रही। हमने आक्रामक रूप से नई प्रतिभाओं की भर्ती की, अपनी टीम को मुट्ठी भर से बढ़ाकर 20 से अधिक डेवलपर्स तक पहुंचाया। इसका मतलब है कि मौजूदा परियोजनाओं में बहुत सारे नए इंजीनियरों को शामिल किया गया है। जैसे-जैसे हमारी टीम तेजी से बढ़ी, हमें नई चुनौतियों का सामना करना पड़ा जिनका हमें शीघ्रता से समाधान करना था। इन नई कठिनाइयों के बावजूद, हम अपने लक्ष्य पर केंद्रित रहे और असाधारण कार्य करना जारी रखा।

हमने एक कदम पीछे लिया और उन नई समस्याओं पर गौर किया जो तब उत्पन्न होती थीं जब अधिक से अधिक लोग परियोजना में शामिल हो जाते थे। उन नई चुनौतियों के बीच, हम निम्नलिखित आवश्यकताओं को सूचीबद्ध कर सकते हैं:

• सरल प्रवाह.
• आने वाले और बाहरी योगदानकर्ताओं के लिए बेहतर दिशानिर्देश।
• उपकरणों का एक एकीकृत सेट.
• बेहतर निर्भरता प्रबंधन.
• केंद्रीकृत खुला स्रोत योगदान।

अत्याधुनिक: प्रवास से पहले

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

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

देव अनुभव बाधाएँ

निर्भरता

हमारी परियोजनाओं की प्रकृति के कारण, हम एक ही समय में कई रिपॉजिटरी पर उनके बीच निर्भरता के साथ काम करते हैं। यहाँ एक त्वरित अवलोकन है:

लेजर ओपन सोर्स लाइब्रेरी का उपयोग बिजनेस लॉजिक द्वारा किया जाता है, जिसका उपयोग डेस्कटॉप और मोबाइल ऐप दोनों द्वारा किया जाता है। लेकिन वे ऐप्स ओपन सोर्स लाइब्रेरीज़ का भी उपयोग करते हैं, और एक ही लाइब्रेरी के दो अलग-अलग संस्करणों का उपयोग करते हैं (जैसे @ledgerhq/errors उदाहरण के लिए) ऐप को तोड़ देगा।

हमें संस्करण को एक तरफ से टक्कर देने की जरूरत है, फिर पुस्तकालयों को प्रकाशित करें (हां, एनपीएम पर !!!), फिर अगर यह काम नहीं करता है तो पुनः प्रयास करें। हमने भरोसा करना शुरू कर दिया yalc परियोजनाओं को सिम्लिंक करने के लिए, जो तब तक ठीक था जब तक हमारे पास निर्भरता की कई परतें नहीं थीं (उदाहरण के लिए, ओपन सोर्स लाइब्रेरी से बिजनेस लॉजिक तक, और फिर बिजनेस लॉजिक से ऐप्स तक)। हमने अस्थायी रूप से साथ काम करने की कोशिश की yarn link साथ ही, लेकिन ऐसा लगता है कि यह रिएक्ट नेटिव के साथ बर्बाद हो गया था।

परीक्षण

विभिन्न परियोजनाओं के सभी नवीनतम कोड के साथ एकीकरण परीक्षण करना लगभग असंभव था। चूँकि हमें पुस्तकालयों को रजिस्ट्री में प्रकाशित करने की आवश्यकता थी, नवीनतम अद्यतन कोड के साथ सभी घटकों का परीक्षण करना एक बुरा सपना था

हमें डुप्लिकेट तर्क के साथ कई सीआई भी बनाए रखना पड़ा।

प्रसंग स्विचिंग

हमेशा कई कोड संपादकों/परियोजनाओं/निर्देशिकाओं के आसपास घूमने से विकास अनुभव वास्तव में कमजोर दिखता है।

रिलीज़ प्रक्रिया की बाधाएँ

संस्करण

विभिन्न परियोजनाओं के संस्करण को संभालना कठिन है, खासकर जब निर्भरता की कई परतें हों।

जारी

रिलीज़ ट्रैकिंग इस तथ्य के कारण जटिल थी कि परियोजनाएँ विभाजित थीं, और हमें विभिन्न परियोजनाओं की रिलीज़ का प्रबंधन करना पड़ा

इस तथ्य के कारण कि परियोजनाओं को अलग-अलग रिपॉजिटरी में विभाजित किया गया था, रिलीज़ प्रक्रिया को स्वचालित करना असंभव था।

और निश्चित रूप से, इस बिंदु पर सतत वितरण अकल्पनीय था।

संभावित स्थिति ?

प्रेरणा के लिए चारों ओर देखने पर, ऐसा लगता है कि मोनो रिपॉजिटरी आर्किटेक्चर वह केंद्रीय टुकड़ा है जिसे हम गायब कर रहे थे। यह एक बेहतर विकास प्रक्रिया को सक्षम बनाएगा। इस आर्किटेक्चर के आसपास ऐसे उपकरण बनाए गए हैं जो हमें लापता हिस्सों (रिलीज़, ऑटोमेशन, वर्जनिंग…) को प्राप्त करने में मदद करेंगे।

लेकिन, मोनो रिपॉजिटरी क्या है?

इसके मूल में, एक मोनो रिपॉजिटरी एक प्रोजेक्ट है जो एक फ़ोल्डर / गिट प्रोजेक्ट के तहत अन्य सभी संबंधित प्रोजेक्ट्स (एप्लिकेशन, लाइब्रेरी, टूल्स) को समाहित करता है। यह बेहतर निर्भरता प्रबंधन, उपकरणों का एकरूपीकरण (जैसे कोड शैलियाँ और टाइपस्क्रिप्ट कॉन्फ़िगरेशन), केंद्रीकृत सतत एकीकरण, एकीकरण परीक्षण, प्रयुक्त पैकेज्ड का एक समान संस्करण (उदाहरण के लिए प्रतिक्रिया) की अनुमति देता है...

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

नुकसान

मोनो रिपॉजिटरी उस संदर्भ में समझ में आती है जहां कई डेवलपर्स, या डेवलपर्स की एक टीम एक ही समय में कई परियोजनाओं पर काम करती है, उनके बीच निर्भरता के साथ। हालाँकि, यह सेटअप चरण के दौरान जटिलता की कुछ परत जोड़ता है (विशेषकर पहले से चल रही परियोजनाओं के साथ जिनका 4 साल का इतिहास और सक्रिय विकास है)। उल्लेख करने योग्य बात यह है कि डिस्क स्थान के मामले में प्रोजेक्ट बहुत बड़ा हो जाता है (बहुत बड़ा)। सभी प्रोजेक्ट अब एक ही फ़ोल्डर और सभी निर्भरताओं के अंतर्गत हैं। कौन से परीक्षण अनिवार्य हैं? उन्हें कब ट्रिगर करना है?

फ़ायदे

समय, लागत और हमारी महत्वाकांक्षाओं की व्यवहार्यता का मूल्यांकन करने के बाद, इस परिवर्तन के कुछ अपेक्षित लाभ यहां दिए गए हैं:

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

निष्कर्ष

कुल मिलाकर, मोनोरेपो संरचना का कार्यान्वयन विकास प्रक्रिया को बेहतर बनाने, रिलीज प्रक्रिया को सुव्यवस्थित करने और डेवलपर अनुभव को बढ़ाने में मदद कर सकता है।

इस श्रृंखला के अगले ब्लॉग पोस्ट में, हम आपको बताएंगे कि यह प्रमुख प्रवासन परियोजना कैसे संचालित की गई, हमने किन उपकरणों का उपयोग किया, हमने क्या विकल्प चुने, परिणाम और भी बहुत कुछ। भाग 2 के लिए बने रहें: उपकरण!

---

वैलेन्टिन डी अल्मेडा
डेवलपर अनुभव और कोर टेक - लेजर लाइव

• एसईओ संचालित सामग्री और पीआर वितरण। आज ही प्रवर्धित हो जाओ।
• प्लेटोडेटा.नेटवर्क वर्टिकल जेनरेटिव एआई। स्वयं को शक्तिवान बनाएं। यहां पहुंचें।
• प्लेटोआईस्ट्रीम। Web3 इंटेलिजेंस। ज्ञान प्रवर्धित। यहां पहुंचें।
• प्लेटोईएसजी. कार्बन, क्लीनटेक, ऊर्जा, पर्यावरण, सौर, कचरा प्रबंधन। यहां पहुंचें।
• प्लेटोहेल्थ। बायोटेक और क्लिनिकल परीक्षण इंटेलिजेंस। यहां पहुंचें।
• स्रोत: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain