निरंतर एकीकरण, गिटहब क्रियाएँ, और सोनार क्लाउड के बारे में आप सभी को पता होना चाहिए

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

हम शायद ही कभी एक स्वच्छ निर्माण के माध्यम से गए, जिसने जटिल समस्याएं पैदा कीं क्योंकि परियोजना के लिए खराब कोड प्रतिबद्ध था।

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

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

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

सीआई अक्सर कंटीन्यूअस डिलीवरी (सीडी) के साथ हाथ से जाता है, जिसका उद्देश्य कोड एकीकरण से लेकर उत्पादन में तैनाती तक संपूर्ण सॉफ्टवेयर वितरण प्रक्रिया को स्वचालित करना है।

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

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

मैं अवधारणा का बहुत बड़ा प्रशंसक हूं, लेकिन कुछ चीजें हैं जिन पर हमें नजर रखने की जरूरत है।

सतत एकीकरण उपकरण

कई शक्तिशाली सतत एकीकरण उपकरण हैं। यहाँ कुछ सामान्य रूप से उपयोग किए जाने वाले उपकरण हैं:

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

  
  

  यह जावा में लिखा गया है और अक्सर मेरा "गो-टू टूल" था। हालाँकि, इसे प्रबंधित करना और स्थापित करना एक दर्द है। कुछ "जेनकींस एक सेवा के रूप में" समाधान हैं जो इसके उपयोगकर्ता अनुभव को भी साफ करते हैं जिसमें कुछ कमी है।

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

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

• GitLab CI/CD : GitLab एक लोकप्रिय स्रोत कोड प्रबंधन उपकरण है जिसमें अंतर्निहित CI/CD क्षमताएं शामिल हैं। GitLab समाधान लचीला लेकिन सरल है; इसने GitLab क्षेत्र के बाहर भी कुछ उद्योग कर्षण प्राप्त किया है।

• बिटबकेट पाइपलाइन : बिटबकेट पाइपलाइन एटलसियन का क्लाउड-आधारित सीआई उपकरण है जो बिटबकेट, उनके स्रोत कोड प्रबंधन उपकरण के साथ मूल रूप से एकीकृत होता है। चूंकि यह एक एटलसियन उत्पाद है, यह निर्बाध जेआईआरए एकीकरण और बहुत तरल, उद्यम-उन्मुख कार्यक्षमता प्रदान करता है।

ध्यान दें कि मैंने गिटहब क्रियाओं का जिक्र नहीं किया है जिसे हम जल्द ही प्राप्त करेंगे। सीआई उपकरणों की तुलना करते समय विचार करने के लिए कई कारक हैं:

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

• GitHub, GitLab और Bitbucket जैसे स्रोत कोड प्रबंधन (SCM) टूल के साथ एकीकरण। इससे टीमों के लिए अपने निर्माण, परीक्षण और परिनियोजन प्रक्रियाओं को स्वचालित करना आसान हो जाता है।

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

• मापनीयता: कुछ CI उपकरण जटिल निर्माण पाइपलाइनों वाले बड़े संगठनों के लिए बेहतर अनुकूल हैं, जबकि अन्य सरल आवश्यकताओं वाली छोटी टीमों के लिए बेहतर अनुकूल हैं।

• लागत: सीआई उपकरण मुक्त और मुक्त-स्रोत से लेकर व्यावसायिक उपकरणों तक की लागत में हैं, जो महंगे हो सकते हैं, इसलिए ऐसा उपकरण चुनना महत्वपूर्ण है जो आपके बजट के अनुकूल हो।

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

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

GitLab CI/CD अपने स्रोत कोड प्रबंधन के लिए GitLab का उपयोग करने वाली टीमों के लिए एक लोकप्रिय विकल्प है क्योंकि यह एकीकृत CI/CD क्षमताएं प्रदान करता है। Bitbucket पाइपलाइन अपने स्रोत कोड प्रबंधन के लिए Bitbucket का उपयोग करने वाली टीमों के लिए एक अच्छा विकल्प है, क्योंकि यह प्लेटफ़ॉर्म के साथ समेकित रूप से एकीकृत है।

क्लाउड बनाम ऑन-प्रिमाइसेस

सीआई समाधान चुनते समय विचार करने के लिए एजेंटों की मेजबानी एक महत्वपूर्ण कारक है। एजेंट होस्टिंग के दो मुख्य विकल्प हैं: क्लाउड-आधारित और ऑन-प्रिमाइसेस।

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

• ऑन-प्रिमाइसेस : ऑन-प्रिमाइसेस CI समाधान, जैसे जेनकींस, आपको एजेंटों को अपने स्वयं के सर्वर पर होस्ट करने की अनुमति देते हैं। यह आपको अंतर्निहित बुनियादी ढांचे पर अधिक नियंत्रण देता है, लेकिन सर्वरों के प्रबंधन और रखरखाव के लिए अधिक प्रयास की भी आवश्यकता होती है।

CI समाधान चुनते समय, अपनी टीम की विशिष्ट आवश्यकताओं और आवश्यकताओं पर विचार करना महत्वपूर्ण है।

उदाहरण के लिए, यदि आपके पास एक बड़ी और जटिल बिल्ड पाइपलाइन है, तो जेनकींस जैसा ऑन-प्रिमाइसेस समाधान एक बेहतर विकल्प हो सकता है, क्योंकि यह आपको अंतर्निहित बुनियादी ढांचे पर अधिक नियंत्रण प्रदान करता है।

दूसरी ओर, यदि आपके पास साधारण जरूरतों वाली एक छोटी टीम है, तो ट्रैविस सीआई जैसा क्लाउड-आधारित समाधान एक बेहतर विकल्प हो सकता है, क्योंकि इसे स्थापित करना और प्रबंधित करना आसान है।

एजेंट स्टेटफुलनेस

स्टेटफुलनेस यह निर्धारित करती है कि एजेंट अपने डेटा और कॉन्फ़िगरेशन को बिल्ड के बीच बनाए रखते हैं या नहीं।

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

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

सर्वोत्तम दृष्टिकोण के संबंध में सीआई समर्थकों के बीच जीवंत बहस चल रही है। स्टेटलेस एजेंट एक स्वच्छ और आसान-से-पुनरुत्पादन वातावरण प्रदान करते हैं। मैं उन्हें ज्यादातर मामलों के लिए चुनता हूं और सोचता हूं कि वे बेहतर दृष्टिकोण हैं।

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

एक स्टेटलेस एजेंट के साथ, जब एक सीआई प्रक्रिया विफल हो जाती है, तो आपके पास आमतौर पर लॉग के अलावा जांच का कोई साधन नहीं रह जाता है।

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

जिस कंपनी के साथ मैंने काम किया, उसने GitHub क्रियाओं पर Azure को चुना क्योंकि Azure ने स्टेटफुल एजेंटों के लिए अनुमति दी थी। असफल सीआई प्रक्रिया को डीबग करते समय यह उनके लिए महत्वपूर्ण था।

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

दोहराने योग्य बनाता है

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

DevOps के दृष्टिकोण से, यह सुनिश्चित करने के लिए कि सॉफ़्टवेयर परिनियोजन सुसंगत और विश्वसनीय हैं, दोहराए जाने योग्य बिल्ड होना आवश्यक है।

रुक-रुक कर विफलताएँ हर जगह DevOps का अभिशाप हैं, और उन्हें ट्रैक करना दर्दनाक है।

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

• निर्भरताएँ - यदि हम निर्भरता के लिए विशिष्ट संस्करणों का उपयोग नहीं करते हैं, तो एक छोटा सा परिवर्तन भी हमारे निर्माण को तोड़ सकता है।

• परतदार परीक्षण - बिना किसी स्पष्ट कारण के कभी-कभी विफल होने वाले परीक्षण सबसे खराब होते हैं।

निर्भरता को परिभाषित करते समय हमें विशिष्ट संस्करणों पर ध्यान देने की आवश्यकता होती है। कई वर्जनिंग योजनाएं हैं, लेकिन पिछले एक दशक में, मानक तीन-नंबर सिमेंटिक वर्जनिंग ने उद्योग को संभाल लिया है।

यह योजना सीआई के लिए बेहद महत्वपूर्ण है क्योंकि इसका उपयोग निर्माण की पुनरावृत्ति को महत्वपूर्ण रूप से प्रभावित कर सकता है जैसे मेवेन के साथ हम कर सकते हैं:

 <dependency> <groupId>group</groupId> <artifactId>artifact</artifactId> <version>2.3.1</version> </dependency>

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

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

उदाहरण के लिए, उस पिछले मामले के लिए, मैं संस्करण 2.3.2 को निहित रूप से उपयोग करना चाहूंगा न कि 2.4.1 । यह मामूली सुरक्षा अपडेट और बग के लिए कुछ दोहराने योग्य है।

लेकिन मावेन संस्करण प्लगइन का उपयोग करने का एक बेहतर तरीका होगा और समय-समय पर mvn versions:use-latest-releases कमांड का आह्वान करें। यह हमारे प्रोजेक्ट को अद्यतित रखने के लिए संस्करणों को नवीनतम में अपडेट करता है।

यह दोहराने योग्य बिल्ड का सीधा हिस्सा है। कठिनाई परतदार परीक्षणों में है। यह इतना सामान्य दर्द है कि कुछ परियोजनाएं विफल परीक्षणों की "उचित मात्रा" को परिभाषित करती हैं, और कुछ परियोजनाएं विफलता को स्वीकार करने से पहले कई बार निर्माण को फिर से चलाती हैं।

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

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

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

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

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

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

परीक्षण विफलताओं के आंकड़े रखना महत्वपूर्ण है, और कभी भी पुनः प्रयास न करें। समस्याग्रस्त परीक्षणों और विफलता के निष्पादन के क्रम को ट्रैक करके, हम अक्सर समस्या के स्रोत का पता लगा सकते हैं।

ज्यादातर बार, विफलता का मूल कारण पूर्व परीक्षण में दोषपूर्ण सफाई के कारण होता है, यही कारण है कि क्रम मायने रखता है और इसकी निरंतरता भी महत्वपूर्ण है।

डेवलपर अनुभव और सीआई प्रदर्शन

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

अक्सर, मैं सीआई चेक पास करने की कोशिश में दिन बिताता था ताकि मैं अपने परिवर्तनों को मर्ज कर सकूं। हर बार जब मैं करीब आता हूं, तो दूसरा डेवलपर पहले अपना परिवर्तन मर्ज कर देगा और मेरा निर्माण तोड़ देगा।

यह विशेष रूप से एक टीम के पैमाने के रूप में कम-से-कम तारकीय डेवलपर अनुभव में योगदान देता है और हम अपने परिवर्तनों को मर्ज करने की तुलना में सीआई कतार में अधिक समय बिताते हैं। इन समस्याओं को कम करने के लिए हम बहुत कुछ कर सकते हैं:

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

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

• CI प्रक्रिया के लिए अतिरिक्त या तेज़ मशीनें आवंटित करें।

• सीआई प्रक्रिया को समानांतर करें। हम कुछ बिल्ड प्रकारों और कुछ परीक्षणों को समानांतर कर सकते हैं।

• परियोजना को छोटी परियोजनाओं में विभाजित करें - ध्यान दें कि इसका मतलब माइक्रोसर्विसेज नहीं है ।

अंततः, यह सीधे डेवलपर्स की उत्पादकता से जुड़ता है। लेकिन हमारे पास इस तरह के ऑप्टिमाइज़ेशन के लिए प्रोफाइलर नहीं हैं। हमें हर बार मापना पड़ता है; यह श्रमसाध्य हो सकता है।

गिटहब क्रियाएँ

GitHub क्रियाएँ GitHub में निर्मित एक सतत एकीकरण/निरंतर वितरण (CI/CD) प्लेटफ़ॉर्म है। यह स्टेटलेस है, हालांकि यह कुछ हद तक एजेंटों की स्वयं-होस्टिंग की अनुमति देता है। मैं इस पर ध्यान केंद्रित कर रहा हूं क्योंकि यह ओपन-सोर्स प्रोजेक्ट्स के लिए मुफ़्त है और क्लोज-सोर्स प्रोजेक्ट्स के लिए एक अच्छा फ्री कोटा है।

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

गिटहब क्रियाओं का परीक्षण करने के लिए, हमें एक नई परियोजना की आवश्यकता है, इस मामले में, मैंने यहां देखे गए कॉन्फ़िगरेशन के साथ JHipster का उपयोग करके उत्पन्न किया:

मैंने एक अलग प्रोजेक्ट बनाया है जो यहाँ GitHub क्रियाओं के उपयोग को प्रदर्शित करता है। ध्यान दें कि आप इसे किसी भी परियोजना के साथ अनुसरण कर सकते हैं; हालाँकि हम इस मामले में मावेन निर्देश शामिल करते हैं, अवधारणा बहुत सरल है।

एक बार प्रोजेक्ट बन जाने के बाद, हम GitHub पर प्रोजेक्ट पेज खोल सकते हैं और एक्शन टैब पर जा सकते हैं।

हम कुछ ऐसा देखेंगे:

निचले दाएं कोने में, हम जावा को मेवेन प्रोजेक्ट प्रकार के साथ देख सकते हैं। एक बार जब हम इस प्रकार को चुन लेते हैं, तो हम एक maven.yml फ़ाइल बनाने की ओर बढ़ते हैं, जैसा कि यहाँ दिखाया गया है:

दुर्भाग्य से, गिटहब द्वारा सुझाए गए डिफ़ॉल्ट maven.yml में एक समस्या शामिल है। यह वह कोड है जो हम इस छवि में देखते हैं:

 name: Java CI with Maven on: push: branches: [ "master" ] pull_request: branches: [ "master" ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up JDK 11 uses: actions/setup-java@v3 with: java-version: '11' distribution: 'temurin' cache: maven - name: Build with Maven run: mvn -B package --file pom.xml # Optional: Uploads the full dependency graph to GitHub to improve the quality of Dependabot alerts this repository can receive - name: Update dependency graph uses: advanced-security/maven-dependency-submission-action@571e99aab1055c2e71a1e2309b9691de18d6b7d6

अंतिम तीन पंक्तियाँ निर्भरता ग्राफ़ को अपडेट करती हैं। लेकिन यह सुविधा विफल रही, या कम से कम यह मेरे लिए विफल रही। उन्हें हटाने से समस्या हल हो गई। शेष कोड मानक YAML कॉन्फ़िगरेशन है।

कोड के शीर्ष के पास pull_request और push लाइन्स यह घोषणा करती हैं कि बिल्ड पुल अनुरोध और मास्टर को पुश दोनों पर चलेगा। इसका मतलब है कि हम कमिट करने से पहले पुल अनुरोध पर अपने परीक्षण चला सकते हैं। यदि परीक्षण विफल रहता है, तो हम प्रतिबद्ध नहीं होंगे।

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

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

सभी YAML फ़ाइलों और विभिन्न CI स्टैक की कॉन्फ़िगरेशन सेटिंग्स से निपटने की तुलना में एक अच्छी शेल स्क्रिप्ट लिखना कभी-कभी आसान होता है।

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

हम यहां सफल पुल अनुरोध देख सकते हैं:

इसका परीक्षण करने के लिए, हम “/api” समापन बिंदु को “/myapi” में बदलकर कोड में एक बग जोड़ सकते हैं। यह नीचे दिखाए गए विफलता का उत्पादन करता है। यह कमिट के लेखक को भेजे गए एक त्रुटि ईमेल को भी ट्रिगर करता है।

जब ऐसी विफलता होती है, तो हम दाईं ओर "विवरण" लिंक पर क्लिक कर सकते हैं। यह हमें सीधे उस त्रुटि संदेश पर ले जाता है जिसे आप यहां देख रहे हैं:

दुर्भाग्य से, यह आमतौर पर एक बेकार संदेश है जो समस्या के समाधान में सहायता प्रदान नहीं करता है। हालाँकि, ऊपर स्क्रॉल करने से वास्तविक विफलता दिखाई देगी जो आमतौर पर हमारे लिए सुविधाजनक रूप से हाइलाइट की जाती है जैसा कि यहाँ देखा गया है:

ध्यान दें कि अक्सर कई विफलताएँ होती हैं इसलिए आगे स्क्रॉल करना समझदारी होगी। इस त्रुटि में, हम देख सकते हैं कि विफलता AccountResourceIT की पंक्ति 394 में एक अभिकथन था जिसे आप यहाँ देख सकते हैं, ध्यान दें कि पंक्ति संख्याएँ मेल नहीं खातीं। इस स्थिति में, पंक्ति 394 विधि की अंतिम पंक्ति है:

 @Test @Transactional void testActivateAccount() throws Exception { final String activationKey = "some activation key"; User user = new User(); user.setLogin("activate-account"); user.setEmail("[email protected]"); user.setPassword(RandomStringUtils.randomAlphanumeric(60)); user.setActivated(false); user.setActivationKey(activationKey); userRepository.saveAndFlush(user); restAccountMockMvc.perform(get("/api/activate?key={activationKey}", activationKey)).andExpect(status().isOk()); user = userRepository.findOneByLogin(user.getLogin()).orElse(null); assertThat(user.isActivated()).isTrue(); }

इसका मतलब है कि मुखर कॉल विफल हो गई। isActivated() false लौटा और परीक्षण में विफल रहा। इससे डेवलपर को समस्या को कम करने और मूल कारण को समझने में मदद मिलनी चाहिए।

उसके पार जाना

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

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

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

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

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

सोनारक्लाउड और सोनारक्यूब दोनों समान कार्यक्षमता प्रदान करते हैं, लेकिन सोनारक्लाउड एक क्लाउड-आधारित सेवा है और इसके लिए सदस्यता की आवश्यकता होती है, जबकि सोनारक्यूब एक ओपन-सोर्स प्लेटफॉर्म है जिसे ऑन-प्रिमाइसेस या क्लाउड सर्वर पर स्थापित किया जा सकता है।

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

जब हम नए पृष्ठ का विश्लेषण करें विकल्प का चयन करते हैं, तो हमें अपने GitHub रिपॉजिटरी तक पहुंच को अधिकृत करने की आवश्यकता होती है। अगला चरण उन परियोजनाओं का चयन कर रहा है जिन्हें हम सोनार क्लाउड में जोड़ना चाहते हैं जैसा कि यहां दिखाया गया है:

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

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

ध्यान दें कि मावेन के साथ उपयोग करने के लिए डिफ़ॉल्ट निर्देश भी हैं जो "मावेन" लेबल वाले बटन पर क्लिक करने पर दिखाई देते हैं।

GitHub में प्रोजेक्ट पर वापस जाकर, हम प्रोजेक्ट सेटिंग टैब पर जा सकते हैं (शीर्ष मेनू में खाता सेटिंग से भ्रमित न हों)। यहाँ, हम "रहस्य और चर" का चयन करते हैं जैसा कि यहाँ दिखाया गया है:

इस खंड में, हम एक नया भंडार रहस्य जोड़ सकते हैं, विशेष रूप से SONAR_TOKEN कुंजी और मान जिसे हमने सोनारक्लाउड से कॉपी किया था, जैसा कि आप यहां देख सकते हैं:

GitHub रिपॉजिटरी सीक्रेट्स एक ऐसी सुविधा है जो डेवलपर्स को GitHub रिपॉजिटरी से जुड़ी संवेदनशील जानकारी को सुरक्षित रूप से संग्रहीत करने की अनुमति देती है, जैसे कि API कुंजियाँ, टोकन और पासवर्ड, जो रिपॉजिटरी द्वारा उपयोग की जाने वाली विभिन्न तृतीय-पक्ष सेवाओं या प्लेटफ़ॉर्म तक पहुँच को प्रमाणित और अधिकृत करने के लिए आवश्यक हैं। .

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

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

GitHub रिपॉजिटरी सीक्रेट्स को सुरक्षित रूप से संग्रहीत किया जाता है और केवल उन अधिकृत उपयोगकर्ताओं द्वारा ही एक्सेस किया जा सकता है जिन्हें रिपॉजिटरी तक पहुंच प्रदान की गई है। सीक्रेट्स का उपयोग वर्कफ़्लोज़, क्रियाओं और रिपॉजिटरी से जुड़ी अन्य लिपियों में किया जा सकता है।

उन्हें पर्यावरण चर के रूप में कोड में पारित किया जा सकता है ताकि यह सुरक्षित, विश्वसनीय तरीके से रहस्यों तक पहुंच और उपयोग कर सके।

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

अब हमें इसे परियोजना में एकीकृत करने की जरूरत है। सबसे पहले, हमें इन दो पंक्तियों को pom.xml फ़ाइल में जोड़ना होगा। ध्यान दें कि आपको अपने नाम से मेल खाने के लिए संगठन के नाम को अपडेट करने की आवश्यकता है। इन्हें एक्सएमएल में सेक्शन में जाना चाहिए:

 <sonar.organization>shai-almog</sonar.organization> <sonar.host.url>https://sonarcloud.io</sonar.host.url>

ध्यान दें कि हमारे द्वारा बनाए गए JHipster प्रोजेक्ट में पहले से ही सोनारक्यूब सपोर्ट है जिसे इस कोड के काम करने से पहले पोम फ़ाइल से हटा दिया जाना चाहिए ।

इसके बाद, हम maven.yml फ़ाइल के "बिल्ड विथ मावेन" भाग को निम्न संस्करण से बदल सकते हैं:

 - name: Build with Maven env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Needed to get PR information, if any SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} run: mvn -B verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar -Dsonar.projectKey=shai-almog_HelloJHipster package

एक बार जब हम ऐसा कर लेते हैं, तो सोनारक्लाउड सिस्टम में मर्ज किए गए प्रत्येक पुल अनुरोध के लिए रिपोर्ट प्रदान करेगा जैसा कि यहां दिखाया गया है:

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

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

दो अतिरिक्त दिलचस्प तत्व जो हमने पहले देखे थे वे हैं कवरेज और डुप्लीकेशन रिपोर्ट। सोनारक्लाउड को उम्मीद है कि परीक्षणों में 80% कोड कवरेज होगा (पुल अनुरोध में कोड का 80% ट्रिगर), यह उच्च है और सेटिंग्स में कॉन्फ़िगर किया जा सकता है।

यह डुप्लिकेट कोड को भी इंगित करता है जो डोंट रिपीट योरसेल्फ (DRY) सिद्धांत के उल्लंघन का संकेत दे सकता है।

आखिरकार

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

यह हमारे जीवन को आसान बनाने के लिए यहां है।

जब इसे बुरी तरह से किया जाता है, तो सीआई प्रक्रिया इस अद्भुत उपकरण को दुःस्वप्न में बदल सकती है। परीक्षा पास करना व्यर्थ की कवायद बन जाता है। हम बार-बार पुन: प्रयास करते हैं जब तक कि हम अंत में विलय नहीं कर लेते। धीमी, भीड़ वाली कतारों के कारण हम विलय के लिए घंटों इंतजार करते हैं।

यह उपकरण जो मदद करने वाला था वह हमारी दासता बन गया। ऐसा नहीं होना चाहिए। सीआई को हमारे जीवन को आसान बनाना चाहिए, इसके विपरीत नहीं।