सतत वितरण ट्यूटोरियल - जेनकींस का उपयोग करके एक सतत वितरण पाइपलाइन का निर्माण

सतत वितरण:

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

अजगर के लिए अच्छा परमाणु है

• निरंतर वितरण क्या है?
• सॉफ्टवेयर परीक्षण के प्रकार
• निरंतर एकीकरण, वितरण और तैनाती के बीच अंतर
• कंटीन्यूअस डिलीवरी की क्या जरूरत है?
• जेनकिंस और टॉमकैट का उपयोग करना

हमें जल्दी से समझते हैं कि कंटीन्यूअस डिलीवरी कैसे काम करती है।

सतत डिलीवरी क्या है?

यह एक ऐसी प्रक्रिया है जहां आप सॉफ्टवेयर का निर्माण इस तरह से करते हैं कि इसे किसी भी समय उत्पादन के लिए जारी किया जा सकता है।नीचे दिए गए आरेख पर विचार करें:

मुझे उपरोक्त आरेख की व्याख्या करें:

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

इससे पहले कि मैं आगे बढ़ूं, यह उचित होगा कि मैं आपको विभिन्न प्रकार के परीक्षण समझाऊं।

सॉफ्टवेयर परीक्षण के प्रकार:

मोटे तौर पर दो प्रकार के परीक्षण हैं:

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

व्हाइटबॉक्स परीक्षण:

परीक्षण दो प्रकार के होते हैं, जो इस श्रेणी में आते हैं।

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

ब्लैकबॉक्स परीक्षण:

ऐसे कई परीक्षण हैं जो इस श्रेणी में आते हैं। मैं ध्यान लगाऊंगाकुछ, जो इस ब्लॉग को समझने के लिए आपके लिए जानना महत्वपूर्ण है:

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

अब मेरे लिए निरंतर एकीकरण, वितरण और परिनियोजन के बीच के अंतर को समझाने का सही समय है।

निरंतर एकीकरण, वितरण और तैनाती के बीच अंतर:

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

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

कंटीन्यूअस डिलीवरी में, एप्लिकेशन को UAT के टेस्ट सर्वर पर लगातार तैनात किया जाता है। या, आप कह सकते हैं कि आवेदन किसी भी समय उत्पादन के लिए जारी करने के लिए तैयार है। तो, जाहिर है कंटीन्यूअस इंटीग्रेशन कंटीन्यूअस डिलीवरी के लिए आवश्यक है।

कंटिन्यूअस डिप्लॉयमेंट कंटीन्यूअस डिलिवरी का अगला चरण है, जहाँ आप न केवल एक तैनाती योग्य पैकेज बना रहे हैं, बल्कि आप इसे एक स्वचालित फैशन में तैनात कर रहे हैं।

मुझे एक तालिका का उपयोग करके मतभेदों को संक्षेप में प्रस्तुत करने दें:

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

क्लाउड पर जेनकींस का उपयोग करके सीआई / सीडी पाइपलाइन बनाने का तरीका जानें

लेकिन सवाल यह है कि क्या कंटीन्यूअस इंटीग्रेशन ही काफी है।

हमें निरंतर डिलीवरी की आवश्यकता क्यों है?

इसे एक उदाहरण से समझते हैं।

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

यह तैनाती के लिए एक लंबा लेकिन नियंत्रित दृष्टिकोण होना चाहिए जो उनके पर्यावरण विशेषज्ञों ने किया हो। हालाँकि, सिस्टम काम नहीं कर रहा है।

विफलता के स्पष्ट कारण क्या हो सकते हैं?

खैर, पहला कारण यह है कि ज्यादातर लोग सोचेंगे कि कॉन्फ़िगरेशन के साथ कुछ समस्या है। अधिकांश लोगों की तरह वे भी ऐसा सोचते थे।उन्होंने पर्यावरण के विन्यास के साथ क्या गलत है, यह खोजने में बहुत समय बिताया, लेकिन वे समस्या का पता नहीं लगा सके।

एक अवधारणात्मक डेवलपर ने एक स्मार्ट दृष्टिकोण लिया:

तब वरिष्ठ डेवलपर में से एक ने अपनी विकास मशीन पर आवेदन करने की कोशिश की। इसने वहां भी काम नहीं किया।

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

समस्या का विवरण:

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

उपरोक्त समस्याओं को देखते हुए सीखे गए पाठों को संक्षेप में प्रस्तुत करता हूँ:

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

समाधान - सतत वितरण पाइपलाइन (स्वचालित स्वीकृति परीक्षण):

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

असल में, उन्होंने एक सतत वितरण पाइपलाइन का निर्माण किया, ताकि यह सुनिश्चित किया जा सके कि एप्लिकेशन को उत्पादन वातावरण पर मूल रूप से तैनात किया गया है, यह सुनिश्चित करके कि परीक्षण सर्वर पर तैनात होने पर एप्लिकेशन ठीक काम करता है जो उत्पादन सर्वर की प्रतिकृति है।

सिद्धांत के अनुसार, अब मैं आपको दिखाऊंगा कि जेनकिंस का उपयोग करके एक सतत वितरण पाइपलाइन कैसे बनाई जाए।

जेनकींस का उपयोग करते हुए सतत वितरण पाइपलाइन:

यहां मैं जेनकींस का उपयोग एक सतत वितरण पाइपलाइन बनाने के लिए करूंगा, जिसमें निम्नलिखित कार्य शामिल होंगे:

डेमो में शामिल कदम:

• GitHub से कोड ला रहा है
• स्रोत कोड का संकलन
• यूनिट परीक्षण और जेनिट टेस्ट रिपोर्ट तैयार करना
• एप्लिकेशन को WAR फ़ाइल में पैकेजिंग करें और इसे Tomcat सर्वर पर तैनात करें

पूर्व-आवश्यकताएं:

• CentOS 7 मशीन
• जेनकिन्स 2.121.1
• डॉकटर
• टामकट at

चरण - 1 स्रोत कोड का संकलन:

आइए सबसे पहले जेनकिंस में एक फ्रीस्टाइल प्रोजेक्ट बनाकर शुरुआत करें। नीचे स्क्रीनशॉट पर विचार करें:

अपनी परियोजना को एक नाम दें और फ्रीस्टाइल प्रोजेक्ट चुनें:

जब आप नीचे स्क्रॉल करते हैं, तो आपको स्रोत कोड रिपॉजिटरी जोड़ने का विकल्प मिलेगा, git चुनें और रिपॉजिटरी URL जोड़ें, उस रिपॉजिटरी में एक pom.xml जुर्माना है जिसे हम अपनी परियोजना बनाने के लिए उपयोग करेंगे। नीचे स्क्रीनशॉट पर विचार करें:

अब हम एक बिल्ड ट्रिगर जोड़ेंगे। पोल SCM विकल्प चुनें, मूल रूप से, हम कोड में बदलाव के लिए हर 5 मिनट के बाद GitHub रिपॉजिटरी को चुनने के लिए जेनकिंस को कॉन्फ़िगर करेंगे। नीचे स्क्रीनशॉट पर विचार करें:

आगे बढ़ने से पहले, मैं आपको मावेन बिल्ड साइकिल का एक छोटा सा परिचय देता हूँ।

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

निर्माण चरणों की सूची निम्नलिखित है:

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

मैं स्रोत कोड संकलित करने, इकाई परीक्षण और यहां तक ​​कि एप्लिकेशन को युद्ध फ़ाइल में पैक करने के लिए नीचे कमांड चला सकता हूं:

mvan साफ पैकेज

आप कई बिल्ड चरणों में अपनी बिल्ड जॉब को तोड़ भी सकते हैं। इससे साफ, अलग चरणों में बिल्ड को व्यवस्थित करना आसान हो जाता है।

तो हम सोर्स कोड को कंपाइल करके शुरू करेंगे। बिल्ड टैब में, इनवोक टॉप लेवल मैवेन टार्गेट पर क्लिक करें और नीचे कमांड टाइप करें:

संकलन करें

नीचे स्क्रीनशॉट पर विचार करें:

यह GitHub रिपॉजिटरी से सोर्स कोड खींचेगा और इसे (Maven Compile Phase) भी संकलित करेगा।

Save पर क्लिक करें और प्रोजेक्ट रन करें।

अब, परिणाम देखने के लिए कंसोल आउटपुट पर क्लिक करें।

चरण - 2 इकाई परीक्षण:

अब हम इकाई परीक्षण के लिए एक और फ्रीस्टाइल प्रोजेक्ट बनाएंगे।

स्रोत कोड प्रबंधन टैब में वही रिपॉजिटरी URL जोड़ें, जैसे हमने पिछली नौकरी में किया था।

अब, 'Buid ट्रिगर' टैब में 'बिल्ड के बाद अन्य प्रोजेक्ट्स का निर्माण' पर क्लिक करें। पिछली परियोजना का नाम टाइप करें जहां हम स्रोत कोड संकलित कर रहे हैं, और आप नीचे दिए गए विकल्पों में से किसी का चयन कर सकते हैं:

• ट्रिगर स्थिर है तभी बिल्ड स्थिर है
• ट्रिगर अस्थिर है, भले ही निर्माण अस्थिर हो
• बिल्ड फेल होने पर भी ट्रिगर

मुझे लगता है कि उपरोक्त विकल्प बहुत आत्म-व्याख्यात्मक हैं, इसलिए किसी भी एक का चयन करें। नीचे स्क्रीनशॉट पर विचार करें:

बिल्ड टैब में, इनवोक टॉप लेवल मावेन टार्गेट पर क्लिक करें और नीचे कमांड का उपयोग करें:

परीक्षा

जेनकिंस भी आपके परीक्षा परिणाम और परीक्षा परिणाम के रुझान को प्रदर्शित करने में आपकी मदद करने का एक बड़ा काम करता है।

जावा दुनिया में परीक्षण रिपोर्टिंग के लिए वास्तविक मानक एक XML प्रारूप है जिसका उपयोग JUnit द्वारा किया जाता है। इस प्रारूप का उपयोग कई अन्य जावा परीक्षण उपकरण, जैसे TestNG, Spock, और Easyb द्वारा भी किया जाता है। जेनकिन्स इस प्रारूप को समझता है, इसलिए यदि आपका निर्माण JUnit XML परीक्षा परिणाम का उत्पादन करता है, तो Jenkins समय के साथ परीक्षा परिणामों पर अच्छी चित्रमय परीक्षण रिपोर्ट और आँकड़े उत्पन्न कर सकता है, और आपको किसी भी परीक्षण विफलताओं का विवरण भी देखने देता है। जेनकिन्स भी ट्रैक रखता है कि आपके परीक्षणों को चलाने में कितना समय लगता है, दोनों विश्व स्तर पर, और प्रति परीक्षण - यह काम में आ सकता है यदि आपको प्रदर्शन के मुद्दों को ट्रैक करने की आवश्यकता है।

तो अगली चीज़ जो हमें करने की ज़रूरत है वह है जेन्किन्स को हमारे यूनिट परीक्षणों पर नज़र रखने के लिए।

पोस्ट-बिल्ड एक्शन सेक्शन में जाएँ और “JUnit परीक्षा परिणाम रिपोर्ट प्रकाशित करें” चेकबॉक्स पर टिक करें। जब मावेन एक परियोजना में इकाई परीक्षण चलाता है, तो यह स्वचालित रूप से एशेज़-रिपोर्ट नामक एक निर्देशिका में एक्सएमएल परीक्षण रिपोर्ट उत्पन्न करता है। तो 'टेस्ट रिपोर्ट XMLs' फ़ील्ड में '** / लक्ष्य / अचूक-रिपोर्ट / *। Xml' दर्ज करें। पथ की शुरुआत में दो तारांकन ('**') कॉन्फ़िगरेशन को थोड़ा और अधिक मजबूत बनाने के लिए एक सर्वोत्तम अभ्यास है: वे जेनकिन्स को लक्ष्य निर्देशिका को खोजने की अनुमति देते हैं कोई फर्क नहीं पड़ता कि हमने स्रोत कोड की जांच करने के लिए जेनकिन्स को कैसे कॉन्फ़िगर किया है।

** / लक्ष्य / अचूक-रिपोर्ट / *। xml

फिर से इसे सेव करें और बिल्ड नाउ पर क्लिक करें।

अब, JUnit रिपोर्ट को / var / lib / jenkins / कार्यक्षेत्र / परीक्षण / gameoflife-core / लक्ष्य / अचूक-रिपोर्ट / TEST- व्यवहार को लिखा जाता है।

जेनकिंस डैशबोर्ड मेंआप परीक्षा परिणाम भी देख सकते हैं:

चरण - 3 टॉम फाइल सर्वर पर एक WAR फ़ाइल और तैनाती बनाना:

अब, अगला कदम एक WAR फ़ाइल में हमारे एप्लिकेशन को पैकेज करना और उपयोगकर्ता स्वीकृति परीक्षण के लिए टॉमकैट सर्वर पर तैनात करना है।

एक और फ्रीस्टाइल प्रोजेक्ट बनाएं और स्रोत कोड रिपॉजिटरी URL जोड़ें।

फिर बिल्ड ट्रिगर टैब में, अन्य प्रोजेक्ट्स निर्मित होने पर बिल्ड का चयन करें, नीचे स्क्रीनशॉट पर विचार करें:

मूल रूप से, परीक्षण नौकरी के बाद, तैनाती चरण स्वचालित रूप से शुरू हो जाएगा।

बिल्ड टैब में, शेल स्क्रिप्ट का चयन करें। WAR फ़ाइल में एप्लिकेशन को पैकेज करने के लिए नीचे दी गई कमांड टाइप करें:

mvan पैकेज

अगला कदम इस WAR फ़ाइल को Tomcat पर तैनात करना हैसर्वर। 'पोस्ट-बिल्ड एक्शन' टैब में एक कंटेनर में तैनाती युद्ध / कान का चयन करें। यहां, युद्ध फ़ाइल को पथ दें और संदर्भ पथ दें। नीचे स्क्रीनशॉट पर विचार करें:

टॉमकैट क्रेडेंशियल्स का चयन करें और, उपरोक्त स्क्रीनशॉट को नोटिस करें। साथ ही, आपको अपने Tomcat सर्वर का URL देने की आवश्यकता है।

जेनकिंस में क्रेडेंशियल्स जोड़ने के लिए, जेनकिंस डैशबोर्ड पर क्रेडेंशियल्स विकल्प पर क्लिक करें।

सिस्टम पर क्लिक करें और वैश्विक क्रेडेंशियल्स का चयन करें।

फिर आपको क्रेडेंशियल्स जोड़ने का विकल्प मिलेगा। उस पर क्लिक करें और क्रेडेंशियल्स जोड़ें।

टॉमकैट क्रेडेंशियल्स जोड़ें, नीचे स्क्रीनशॉट पर विचार करें।

ओके पर क्लिक करें।

अब अपने प्रोजेक्ट कॉन्फ़िगरेशन में, पिछले चरण में सम्मिलित किए गए टोमैट क्रेडेंशियल्स को जोड़ें।

Save पर क्लिक करें और फिर Build Now चुनें।

प्रसंग पथ के साथ अपने टॉमक URL पर जाएं, मेरे मामले में यह http: // localhost: 8081 है। अब अंत में संदर्भ पथ जोड़ें, नीचे स्क्रीनशॉट पर विचार करें:

लिंक - http: // localhost: 8081 / gof

मुझे उम्मीद है कि आप संदर्भ पथ का अर्थ समझ गए होंगे।

अब एक पाइपलाइन दृश्य बनाएं, नीचे स्क्रीनशॉट पर विचार करें:

नया दृश्य बनाने के लिए, प्लस आइकन पर क्लिक करें।

पाइपलाइन को अपने इच्छित तरीके से कॉन्फ़िगर करें, नीचे स्क्रीनशॉट पर विचार करें:

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

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

इसलिए हम उपयोगकर्ता स्वीकृति परीक्षण (यूएटी) के लिए परीक्षण सर्वर पर अपने आवेदन को लगातार तैनात करने में सक्षम हैं।

मुझे उम्मीद है कि आपको यह पोस्ट Continuous Delivery पर पढ़ने में मज़ा आया होगा। यदि आपको कोई संदेह है, तो बेझिझक उन्हें नीचे टिप्पणी अनुभाग में डाल दें और मैं जल्द से जल्द एक उत्तर के साथ वापस आऊंगा।

CI / CD पाइपलाइन बनाने के लिए आपको कौशल की व्यापक विविधता की आवश्यकता है मास्टर आवश्यक DevOps कौशल अब