🐯 💅 🤰🏾 सॉफ्टवेयर विकास के लिए एक सीआई दृष्टिकोण के साथ मावेन परियोजनाओं के रिलीज प्रबंधन के मुद्दे 👌🏻 💧 😑

लेख पढ़ने के बाद
"सरल रिलीज प्रबंधन गिट उपकरण के साथ"
मैं मावेन परियोजनाओं की रिहाई के प्रबंधन के बारे में अपने विचारों को साझा करना चाहता था।

इस लेख में, मैं केवल समस्याओं के समाधान का प्रस्ताव नहीं दूंगा, बल्कि उन्हें और सही ढंग से तैयार करना चाहता हूं।

संक्षेप में: मावेन परियोजनाओं की रिहाई के प्रबंधन की मुख्य समस्या मावेन ही है, जिसे सॉफ्टवेयर के विकास के लिए CI (निरंतर एकीकरण) की आवश्यकताओं को ध्यान में रखते हुए विकसित नहीं किया गया था।
सॉफ्टवेयर विकास के लिए मानक दृष्टिकोण बनने के बाद से SNAPSHOT संस्करण प्रतिमान को हटा दिया गया है।

अधिक विवरण नीचे।

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

विशेष रूप से हानिकारक तथाकथित " फीचर शाखाएं " हैं, शाखाएं जिनका एकमात्र उद्देश्य अंतिम समय तक नई सुविधाओं को एकीकृत करने की कठिनाइयों को स्थगित करना है, जो निरंतर एकीकरण ("निरंतर एकीकरण") के सिद्धांत का पूरी तरह से विरोधाभास करता है।

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

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

सतत वितरण पद्धति के ढांचे में एक और सिद्धांत यह है कि सीआई सिस्टम द्वारा उत्पन्न प्रत्येक बिल्ड कलाकृतियों को एक अद्वितीय संस्करण संख्या प्राप्त करना होगा। प्रोजेक्ट को एक नए तरीके से नहीं बनाने, समय बर्बाद करने और अनजाने में बदलाव करने के लिए जोखिम में डालने के लिए यह आवश्यक है, हर बार आपको विकास पाइपलाइन के अगले चरण में कोड के एक निश्चित संस्करण को स्थानांतरित करने की आवश्यकता होती है। उदाहरण के लिए, स्टेज परिवेश में एक विशिष्ट संस्करण के उपयोगकर्ता स्वीकृति परीक्षण (UAT) परीक्षणों को पास करने के बाद स्टेजिंग पर। इसके बजाय, अद्वितीय संस्करण के साथ कलाकृतियों को विरूपण साक्ष्य भंडार (उदाहरण के लिए, नेक्सस, और VCS (संस्करण नियंत्रण प्रणाली) में कोड के साथ नहीं) में संग्रहीत किया जाना चाहिए।

यदि आपकी परियोजना निर्भरता को प्रबंधित करने के लिए मावेन का उपयोग करती है, तो रिलीज प्रबंधन के साथ वास्तविक समस्या यह है कि मावेन को यह सुनिश्चित करने के लिए डिज़ाइन नहीं किया गया है कि हर नए बिल्ड को एक नया अनूठा संस्करण मिले।
मावेन का उपयोग करके एक नया संस्करण जारी करने के लिए चरणों का क्लासिक अनुक्रम मैन्युअल रूप से एक नई रिलीज शाखा बनाना है, pom.xml को अपडेट करना, एक परियोजना का निर्माण करना, और, यदि सफल हो, तो VCS में परिवर्तन करें।
संस्करणों के साथ भ्रम पहले से ही इस स्तर पर होता है, क्योंकि वीसीएस में दो संशोधन अब एक ही कलाकृति के अनुरूप हैं। इन परिवर्तनों के लेन-देन का विषय यहां नहीं उठाया जाएगा।
इन क्रियाओं को स्वचालित करने के लिए, आप मावेन रिलीज प्लगइन का उपयोग कर सकते हैं, जो फिर भी सार में समस्या को हल नहीं करता है और मावेन परियोजना को सीआई और निरंतर वितरण / तैनाती के लिए अधिक उपयुक्त नहीं बनाता है।
SNAPSHOT संस्करणों का उपयोग करना, पहली नज़र में, सीआई को संभव बनाता है। वास्तव में, SNAPSHOT संस्करण भ्रम को और बढ़ा देते हैं और pom-files को अपडेट करने के लिए अतिरिक्त श्रम की आवश्यकता होती है, क्योंकि अब आपको मैन्युअल रूप से न केवल परियोजना संस्करण को अपडेट करने की आवश्यकता है, बल्कि इस परियोजना के सभी SNAPSHOT निर्भरता, साथ ही साथ सभी परियोजनाओं को भी अपडेट करना होगा। लिंक। और अगर आप अभी भी यहां मावेन 3 से संस्करण की सीमाएं जोड़ते हैं, तो पहेली के सभी भागों के मिलान की जटिलता व्यावहारिक रूप से अधिक हो जाती है।

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

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

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

<project xmlns="..." xmlns:xsi="..." xsi:schemaLocation="..."> <modelVersion>4.0.0</modelVersion> <groupId>org.xxx</groupId> <artifactId>xxx</artifactId> <version>${ciVersion}</version> <packaging>jar</packaging> <properties> <ciVersion>0.0.0</ciVersion> </properties> mvn -DciVersion=1.1.1 deploy

लेकिन इस मामले में, pom.xml में, मावेन में संग्रहीत रिपॉजिटरी को तैनाती के बाद संग्रहीत किया जाएगा

${ciVersion}

बदलाव के बिना, जो इस परियोजना पर निर्भर करते समय एक समस्या बन जाएगी।

तो, एक प्रभावी CI मावेन परियोजना के मार्ग पर समस्याएं लगभग दो हैं:

सीआई सिस्टम के माध्यम से कनेक्टेड नौकरियों की एक श्रृंखला के माध्यम से उत्पन्न करने और संचार करने की जटिलता।
मावेन बिल्ड के लिए उत्पन्न संस्करण को स्थानांतरित करने में असमर्थता।

पहली समस्या सीआई सिस्टम की सही पसंद या मौजूदा श्रम को अनुकूलित करने के लिए अतिरिक्त श्रम लागत द्वारा हल की जाती है।

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

एक समझौते के रूप में, अब हम निम्नलिखित दृष्टिकोण का उपयोग कर रहे हैं।

सभी विकास ट्रंक में किए जाते हैं, जो स्नैपशॉट संस्करण के लिए कॉन्फ़िगर किया गया है
VCS में नया चेक देखते ही CI ट्रंक का निर्माण करता है।
जब ट्रंक यूएटी के लिए तैयार होता है, तो एक और कॉन्फ़िगरेशन / जॉब CI सिस्टम को मैन्युअल रूप से शुरू किया जाता है, जो:
1. एक विशिष्ट बिल्ड संस्करण बनाता है (उदाहरण के लिए, VCS संशोधन पर आधारित)
2. VCS से निर्माणाधीन एक शाखा लेता है
3. चरण 1 में उत्पन्न रिले संस्करण में प्रोजेक्ट संस्करण और सभी उप-परियोजनाओं को अद्यतन करने के लिए मावेन संस्करण प्लगइन का उपयोग करता है (आप इस चरण में संस्करण रिलीज़ के आधार पर SNAPSHOT को वैकल्पिक रूप से अपडेट कर सकते हैं)
4. एक परियोजना का निर्माण
5. नेक्सस में रिलीज़ संस्करण के साथ निर्मित कलाकृतियों को दर्शाती है
  (मैं ध्यान देता हूं कि इसके बाद पोम फाइलों में बदलाव वीसीएस में प्रतिबद्ध नहीं हैं)
6. वीसीएस संशोधन याद या टैग बनाया गया
यदि पिछला चरण सफलतापूर्वक पूरा हो गया है, तो अगला / जॉब कॉन्फ़िगरेशन स्वचालित रूप से लॉन्च हो जाता है, जो लक्ष्य वातावरण में एप्लिकेशन को तैनात करने के लिए जिम्मेदार है (उदाहरण के लिए, एक परीक्षण वातावरण), जो अन्य मापदंडों के बीच ईएल अभिव्यक्तियों का उपयोग करके पिछले चरण में निर्मित विरूपण साक्ष्य के संस्करण को स्थानांतरित करता है। यह कार्य सीधे सीआई सिस्टम के दूरस्थ एजेंट के माध्यम से लक्ष्य मशीन पर शुरू होता है, या पूरी तैनाती ssh कनेक्शन के माध्यम से की जा सकती है। तैनाती स्क्रिप्ट भी VCS में संग्रहीत है।
यदि आपको कोई हॉटफ़िक्स जारी करने या सर्विस पैक तैयार करने की आवश्यकता है, तो हम वांछित संशोधन (या टैग) को शाखा देते हैं और CI सिस्टम के कार्य के रिलीज़ मापदंडों को बदलते हैं ताकि यह एक नई शाखा का उपयोग करे और निर्मित कलाकृतियों के उपयुक्त प्रमुख / लघु संस्करण उत्पन्न करे। क्विकबिल्ट का उपयोग करने के मामले में, यह प्रक्रिया टेम्पलेट से नई नौकरी बनाने की आवश्यकता के बिना मौजूदा कॉन्फ़िगरेशन के मापदंडों के दो तीन मूल्यों को सही रूप से सही करने के लिए कम हो जाती है।

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

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

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

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

सॉफ्टवेयर विकास के लिए एक सीआई दृष्टिकोण के साथ मावेन परियोजनाओं के रिलीज प्रबंधन के मुद्दे

More articles: