🕚 🚭 👩‍🌾 जावा में मावेन का उपयोग करके रिलीज़ करना 🚮 🈯️ 💴

यह लेख किस बारे में है?

यह लेख इस बारे में है:

एक रिलीज क्या है?
अंक कैसे जारी किए जाते हैं?
रिलीज होने पर आपको ब्रंच की आवश्यकता क्यों है?
रिलीज सिर्फ जार (युद्ध, कान, ज़िप, आदि) से अधिक क्यों है?
मावेन-रिलीज़-प्लगइन क्या है?
रिलीज का उपयोग करके ब्रंच बनाएं: शाखा।
रिलीज के साथ रिलीज की तैयारी: तैयारी
रिलीज़ का उपयोग करके रिलीज़ रिलीज़ करना: प्रदर्शन करना।

इस लेख को पढ़ने और समझने के लिए, मैं मावेन पर ब्रश करने की सलाह देता हूं। इस तकनीक को समझे बिना कई शब्दों को नहीं समझा जा सकता है।

पहले कुछ खंड रिलीज की सामान्य अवधारणा और उनकी संख्या के लिए समर्पित हैं। यदि आप पर्याप्त अनुभव कर रहे हैं, तो इसे छोड़ दें!

एक रिलीज क्या है और इसके साथ क्या खाती है

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

zoo
|---zoo-web
|---zoo-sensor-server

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

नंबर जारी करना

विकिपीडिया हमें बताता है , “सॉफ्टवेयर परिवर्तनों पर नज़र रखने के लिए बड़ी संख्या में सॉफ़्टवेयर संस्करण नंबरिंग योजनाएँ बनाई गई हैं ।
और यह वास्तव में ऐसा है। अधिकांश परियोजनाएं, कंपनियां, उत्पाद और व्यक्तिगत डेवलपर्स अपनी स्वयं की संस्करण विधि का उपयोग करते हैं।
मावेन सुझाव देते हैं कि हम आम तौर पर स्वीकृत xyz नंबरिंग योजना का अधिक या कम उपयोग करते हैं, जहां:

x - मुख्य रिलीज़ कार्यक्षमता की संख्या
y - अतिरिक्त रिलीज़ कार्यक्षमता की संख्या
z - बग फिक्स नंबर

उदाहरण के लिए, 1.3.23, 0.7.7 और 1.4.112। हम इसका इस्तेमाल अपने चिड़ियाघर के लिए करेंगे।

इस बीच चिड़ियाघर में

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

0.y.0

मध्यवर्ती संस्करणों में से प्रत्येक को क्रमशः 0.1.0, 0.2.0, 0.3.0 नाम दें।
पहला अंक 0 है, क्योंकि हमारी मुख्य रिलीज अभी तक जारी नहीं हुई है, यह केवल एक मध्यवर्ती परिणाम है।
दूसरा अंक वितरण संख्या के बराबर है। तीसरा 0 है, क्योंकि हम मानते हैं कि असेंबली के समय कोई बग नहीं हैं।
जब तीसरा अंक 0 होता है, तो यह अक्सर नहीं लिखा जाता है: 0.1, 0.2, 0.3 ।

अल्फा, बीटा और अन्य आर.सी.

क्लाइंट को रिलीज़ देने से पहले, यहां तक कि मध्यवर्ती, उसे क्यूए प्रक्रिया से गुजरना होगा। टेस्ट रिलीज़ रिलीज़ दृष्टिकोण भी भिन्न हो सकते हैं, लेकिन मेरी परियोजनाओं में मैं रिलीज़ कैंडिडेट की अवधारणा का उपयोग करने की कोशिश करता हूं।
Xy रिलीज़ को रिलीज़ करने से पहले, आप xy-RC1, xy-RC2 का निर्माण करते हैं, और इसी तरह, जब तक QA आपको यह नहीं बताता कि रिलीज़ स्थिर है और UAT या प्रोडक्शन में तैयार है।
फिर अंतिम आरसी बहुत लंबे समय से प्रतीक्षित रिलीज़ हो जाता है।

0.1.x

किसी भी कोड में त्रुटियां हैं। और उपयोगकर्ता खुशी से उन्हें ढूंढ लेगा। समर्थन की प्रक्रिया में, नए बग शुरू होते हैं, आप उन्हें संपादित करते हैं और सुधार के साथ एक संस्करण प्रदान करना चाहिए। इसके लिए, बग फिक्स रिलीज़ एकत्र की जाती हैं।
उदाहरण के लिए, आपने संस्करण 0.1.0 जारी किया, और वास्तविक कार्य के दौरान यह पता चला कि तापमान सेंसर डेटा को सही ढंग से संसाधित नहीं किया गया है। रिलीज़ 0.1.1 जारी किया गया है, जो एक कष्टप्रद गलतफहमी को सही करता है।

अंतिम रिलीज और परे

मध्यवर्ती प्रसव की एक श्रृंखला के बाद, आप 1.0-RC का निर्माण करते हैं, QA प्रक्रिया को पूरा करते हैं, और 1.0 का निर्माण करते हैं। यदि बाद में ग्राहक रात में कोशिकाओं को स्वचालित रूप से खोलने की कार्यक्षमता चाहता है, ताकि जानवरों को भ्रमित कर सकें, और आप 1.1 लिख और इकट्ठा कर सकते हैं। यह एक ~~दर्जन~~ सौ कीड़े मिल जाएगा और आप 1.1.47 जारी करेंगे।
अगर वह अचानक इसे फिर से, प्रेटियर और कूलर में लिखना चाहता है, तो आपको सबसे अधिक 2.0 की आवश्यकता होगी, फिर 2.1.45 और इतने पर, और इसी तरह।

ब्रंच जारी करें

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

नया अनुकूल इंटरफ़ेस कोड कहां लिखा जाना चाहिए?
चिड़ियाघर में अचानक पाए जाने पर हम सेंसर से जानकारी संसाधित करने में त्रुटि को सही कैसे करेंगे?

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

क्यों युद्ध विधानसभा से ज्यादा रिलीज होती है

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

एकत्रित उत्पाद की उपलब्धता को सुनिश्चित करना और सुनिश्चित करना।
पुन: असेंबली या इस रिलीज से एक नई शाखा की शुरुआत के मामले में रिलीज के स्रोत कोड का समेकन।

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

कोड की स्थिति याद रखें

इसके लिए टैग का उपयोग किया जाता है। संस्करण नियंत्रण प्रणाली में टैग, यह संशोधन को सौंपा गया नाम है। कस्टम लुक के लिए, एक टैग समान स्रोत फ़ोल्डर है, लेकिन टैग बनाए जाने के समय इसकी स्थिति तय हो जाती है। और टैग का उपयोग ब्रंच के रूप में न करें।

इकट्ठे उत्पाद को फैलाएं

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

सभी एक साथ

हमें करने की आवश्यकता है:

यदि यह बुनियादी या अतिरिक्त कार्यक्षमता का विमोचन है, तो बग को ठीक करने के लिए एक शाखा बनाएं।
रिलीज के समय कोड की स्थिति को याद रखने के लिए एक टैग बनाएं।
उत्पाद का निर्माण करें और इसे सार्वजनिक उपयोग के लिए साझा करें।

Maven रिलीज-प्लगइन

maven-release-plugin संस्करण नियंत्रण प्रणाली और रिपॉजिटरी के बीच एक इंटरैक्शन टूल है, जो आपको कुछ कमांड के साथ रिलीज़ करने की अनुमति देता है। प्लगइन आपके लिए पूरी रिलीज प्रक्रिया शुरू से अंत तक करता है।

प्लगइन विन्यास

काम करने के लिए प्लगइन के लिए, यह आपकी परियोजना के मुख्य मॉड्यूल pom.xml में निम्नलिखित जानकारी की आवश्यकता है:

संस्करण नियंत्रण जानकारी

सबसे पहले, हमें यह इंगित करने की आवश्यकता है कि परियोजना का स्रोत कोड कहाँ संग्रहीत है। ऐसा करने के लिए, मानक मेवेन टैग का उपयोग करें:

 <scm> <connection>scm:svn:http://svn.zoo.com/zoo/trunk</connection> </scm>

scm: svn: http का अर्थ है: http: पथ के साथ svn रिपॉजिटरी के साथ बातचीत करने के लिए scm प्रोटोकॉल का उपयोग करें। SCM संस्करण नियंत्रण प्रणालियों के साथ काम करने के लिए एक मैवेन प्रोटोकॉल है।
यदि हम मरक्यूरियल का उपयोग करके चिड़ियाघर लिखने जा रहे हैं, तो हमें निम्नलिखित लिखने की आवश्यकता है:

 <scm> <connection>scm:hg:http://svn.zoo.com/zoo/trunk</connection> </scm>

सेटिंग्स बनाएँ

रिलीज के मापदंडों को निर्धारित करने के लिए, अनुभाग में प्लग-इन कनेक्शन का उपयोग किया जाता है।

  <build> <plugins>।

  <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <configuration> <tagBase>svn://svn.zoo.com/zoo/tags</tagBase> <branchBase>svn://svn.zoo.com/zoo/branches</branchBase> <preparationGoals>clean install</preparationGoals> <goals>deploy</goals> <autoVersionSubmodules>true</autoVersionSubmodules> </configuration> </plugin>

विन्यास में:

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

प्लगइन भी परियोजना संस्करण का उपयोग करता है:

 <version>0.1-SNAPSHOT</version>

सामान्य आवश्यकताओं

एक रिलीज बनाने के लिए, आपको सिस्टम में स्थापित वीसीएस के लिए एक क्लाइंट होना चाहिए। यह कंसोल से पहुंच योग्य होना चाहिए और PATH (svn, hg, git) में होना चाहिए।
इसके अलावा, यदि आप कोड में स्थानीय संशोधन करते हैं, तो प्लगइन आपको एक रिलीज़ बनाने की अनुमति नहीं देगा। और ठीक ही तो है!
एक रिलीज बनाने के लिए, प्लगइन को संस्करण नियंत्रण प्रणाली तक पहुंच की आवश्यकता होती है। सुनिश्चित करें कि आपकी मशीन पर प्राधिकरण कैश में आवश्यक जानकारी या उपयोग है -Duser = <vcs-user> -Dpassword = <vcs-password>।

चिड़ियाघर -१.१ रिलीज़ करें

हम अपने चिड़ियाघर के लिए पहली डिलीवरी की रिहाई एकत्र करेंगे। हमारे पास संस्करण 0.1-RC3-SNAPSHOT के साथ एक ट्रंक है। क्यूए टीम ने हमें सूचित किया कि आरसी 2 हमें रिलीज करने के लिए काफी अच्छा था।

रिहाई के लिए एक ब्रंच बनाना - रिलीज: शाखा

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

 mvn release:branch -DbranchName=zoo-0.1.x

रन समय में, मावेन हमसे पूछेंगे कि ट्रंक के लिए अगला संस्करण क्या है, डिफ़ॉल्ट रूप से 0.2-SNAPSHOT की पेशकश करके।

What is the new working copy version for "Zoo"? (com.zoo:zoo) 0.2-SNAPSHOT:

रिहाई की तैयारी - रिहाई: तैयारी

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

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

 mvn release:prepare

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

रिलीज़ रिलीज़ - रिलीज़: प्रदर्शन

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

 mvn release:perform

इस बार वे आपसे कुछ भी नहीं पूछेंगे, वे बस वही करेंगे जो वह लेता है। परिणाम सामान्य विरूपण साक्ष्य भंडार पर पोस्ट किया जाएगा।

अगर कुछ गलत हुआ।

यदि प्लगइन का उपयोग करने की प्रक्रिया में कुछ टूट जाता है, तो आपके पास तीन विकल्प हैं:

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

जावा में मावेन का उपयोग करके रिलीज़ करना