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

क्यों जरूरी है?

तो, आपको पुस्तकालयों को बनाने की आवश्यकता क्यों है, या किसी विशेष मामले में एनपीएम पैकेज?

परियोजनाओं के बीच पुन: उपयोग कोड।

यह सब इस तथ्य से शुरू हुआ कि मैंने परियोजनाओं में एक फ़ोल्डर / उपकरण बनाने की आदत पर ध्यान दिया। इसके अलावा, जब मैं किसी नए प्रोजेक्ट पर स्विच करता हूं, तो मैं इस फोल्डर को भी अपने साथ ले जाता हूं। और फिर मैंने खुद से एक सवाल पूछा, क्यों न कॉपी पेस्ट के बजाय एनपीएम पैकेज बनाया जाए और फिर इसे किसी प्रोजेक्ट से जोड़ा जाए?
विभिन्न जीवन चक्र। अनुप्रयोगों में से एक में, निर्भरता के रूप में घटकों का एक बड़ा कॉर्पोरेट संयोजन था। इसे केवल इसकी संपूर्णता में अपडेट करना संभव था, भले ही केवल एक घटक अपडेट किया गया हो। अन्य घटकों में परिवर्तन कुछ तोड़ सकता है और हमेशा नहीं कि हमारे पास इसे पुन: भेजने के लिए पर्याप्त अनुमानित समय था। यह मॉडल बहुत असुविधाजनक है। जब प्रत्येक पैकेज अपने उद्देश्य या संबंधित लक्ष्यों का एक छोटा सेट प्रदान करता है, तो उन्हें पहले से ही अद्यतन किया जा सकता है जब वास्तव में इसकी आवश्यकता होती है। इसके अलावा, पैकेज के निम्नलिखित संस्करण केवल तभी जारी किए जाते हैं जब उनके पास कुछ बदलाव होते हैं, और "कंपनी के लिए" नहीं।
कोर बिजनेस लॉजिक से अलग मामूली कोड। DDD में डोमेन डिस्टिलेशन का सिद्धांत है; इसमें कोड के टुकड़ों की पहचान करना शामिल है जो मुख्य डोमेन से संबंधित नहीं हैं और खुद को उनसे अलग करते हैं। और इस कोड को एक अलग प्रोजेक्ट में लेने के बजाय अलग करना बेहतर कैसे है।
वैसे, डोमेन डिस्टिलेशन केवल एक अलग स्तर पर एसआरपी सिद्धांत के समान है।
खुद का कोड कवरेज। जिन परियोजनाओं में मैंने भाग लिया, उनमें से एक में कोड कवरेज लगभग 30% था। और जिस लाइब्रेरी से मैंने इसे निकाला, उसमें लगभग 100% कवरेज है। हालांकि, इस परियोजना ने कवरेज का प्रतिशत खो दिया, क्योंकि यह हटाने से पहले लाल क्षेत्र में था, यह बना रहा। और पुस्तकालय में इस तरह के उल्लेखनीय संकेतक हैं, लगभग एक वर्ष और 4 प्रमुख संस्करणों के बाद।
खुला स्रोत कोड जिसमें व्यावसायिक तर्क शामिल नहीं है, परियोजना से अलग होने के लिए पहला उम्मीदवार है, इसलिए इसे खुला बनाया जा सकता है।

नई लाइब्रेरी लॉन्च करें "महंगी"

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

तो, इन सभी उबाऊ, निर्बाध कार्यों के साथ क्या किया जा सकता है?

पहला कदम: बीज

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

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

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

दूसरा चरण: ऑटो प्रकाशित

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

मेरे एक सहकर्मी ने मुझे गिटलैब और उसके सीआई पर ध्यान देने की सलाह दी, और जो कुछ भी मैं चाहता था, वहाँ काम किया।

मैंने प्रोजेक्ट के साथ काम करने की निम्नलिखित प्रक्रिया बनाई, जिसका उपयोग तब किया जाता है जब आपको बग को ठीक करने, नई कार्यक्षमता जोड़ने या नया संस्करण बनाने की आवश्यकता होती है:

मैं मास्टर से एक शाखा बनाता हूं। मैं इसमें कोड और परीक्षण लिखता हूं।
मैं एक मर्ज अनुरोध बनाता हूं।
GitLab CI स्वतः एक नोड में परीक्षण चलाता है: नवीनतम कंटेनर
अनुरोध कोड समीक्षा पास करता है।
अनुरोध के जम जाने के बाद, GitLab स्क्रिप्ट का दूसरा सेट चलाता है। यह सेट संस्करण संख्या के साथ कमिट पर एक टैग बनाता है। संस्करण संख्या package.json से ली गई है, अगर इसे मैन्युअल रूप से वहां बढ़ाया जाता है, यदि नहीं, तो नवीनतम प्रकाशित संस्करण लिया जाता है और ऑटो-इंक्रीमेंट किया जाता है।
स्क्रिप्ट प्रोजेक्ट बनाता है और परीक्षण फिर से चलाता है।
अंतिम चरणों में, संस्करण टैग भंडार में भेजा जाता है और पैकेज एनपीएम को प्रकाशित किया जाता है।

इस प्रकार, टैग में दर्शाया गया संस्करण हमेशा इस प्रतिबद्ध से प्रकाशित पैकेज के संस्करण से मेल खाता है। इन परिचालनों को काम करने के लिए, आपको GitLit Project में रिपॉजिटरी और NPM तक पहुँच कुंजियों के साथ पर्यावरण चर निर्दिष्ट करने की आवश्यकता है।

अंतिम चरण: सब कुछ स्वचालित करें

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

काम करने के लिए इस पूर्ण स्वचालन के लिए, लेकिन कंप्यूटर के पास .ssh फ़ोल्डर में 3 फाइलें होनी चाहिए। मुझे लगा कि यह फ़ोल्डर काफी संरक्षित है, क्योंकि id_rsa निजी कुंजी पहले से ही वहां संग्रहीत है। इस फ़ाइल का उपयोग GitLab CI को रिपॉजिटरी को टैग पास करने में सक्षम करने के लिए भी किया जाएगा।

दूसरी फ़ाइल जो मैंने वहां रखी है, "गिटलैब" है, इसमें GitLab API की एक्सेस कुंजी है। और तीसरी फ़ाइल "npm" है, जो पैकेज को प्रकाशित करने के लिए उपयोग की कुंजी है।

और फिर जादू शुरू होता है। बीज फ़ोल्डर में एक कमांड चलाने के लिए आपको एक नया पैकेज बनाना होगा: "gulp startNewLib -n [npmName] / [libName]"। हो गया, पैकेज बन गया, विकास और ऑटो-प्रकाशन के लिए तैयार।

उदाहरण के लिए, पैकेज "vlr / वैधता" इस तरह से बनाया गया था।

यह आदेश निम्न कार्य करता है:

GitLab पर एक प्रोजेक्ट बनाता है
उस फ़ोल्डर के बगल में एक स्थानीय फ़ोल्डर में क्लोन बीज, जिसमें से कमांड चल रहा है।
चरण 1 में बनाई गई परियोजना के लिए मूल परिवर्तन
मास्टर शाखा को पुश करें
एक .ssh फ़ोल्डर में फ़ाइलों से एक परियोजना में पर्यावरण चर बनाता है
एक प्रथम कार्यान्वयन शाखा बनाता है
पैकेज में लाइब्रेरी का नाम बदलता है। Json, शाखा को आगे बढ़ाता है और धक्का देता है

इसके बाद आपको केवल कोड डालना होगा और मर्ज अनुरोध बनाना होगा।

नतीजतन, जिस पर गर्व किया जा सकता है, उस क्षण से जब किसी अलग परियोजना में किसी तरह का कोड डालने का निर्णय लिया जाता है, जब तक कि पहला संस्करण प्रकाशित नहीं होता है, लगभग पांच मिनट बीत जाते हैं। उनमें से चार ने दो GitLabCI पाइपलाइनों पर कब्जा कर लिया है, और एक मिनट उपरोक्त कमांड लॉन्च करने के लिए, कोड को खींचें और छोड़ें, और फिर अनुरोध बनाने के लिए GitLab इंटरफ़ेस में बटन पर क्लिक करें।

कुछ सीमाएँ हैं: GitLab नाम को npm में नाम से मेल खाना चाहिए। और फिर भी, यह कमांड बीज परियोजना में बाकी कार्यक्षमता के विपरीत, केवल विंडोज पर काम करता है।

यदि आप इस बीज परियोजना में रुचि रखते हैं, तो आप इसे निम्न लिंक पर अध्ययन कर सकते हैं।

टाइपस्क्रिप्ट लाइब्रेरी ऑटोमेशन

क्यों जरूरी है?

नई लाइब्रेरी लॉन्च करें "महंगी"

पहला कदम: बीज

दूसरा चरण: ऑटो प्रकाशित

अंतिम चरण: सब कुछ स्वचालित करें

More articles: