🌔 👨🏼 🏡 सीआई और सीडी के बीच अंतर को समझना: "अगर कुछ दर्द का कारण बनता है, तो इसे अधिक बार करें" 👩🏼‍🎓 🤴🏼 ✅

^{अस्वीकरण ।} ^{Kostis Kapelonis - डेवलपर कोडफ्रेश, सॉफ्टवेयर विकास के सिद्धांतों की रक्षा करने और उन्हें बनाए रखने के लिए, कुबेरनेट्स और कंटेनरों के लिए पहला CI / CD प्लेटफ़ॉर्म तैयार करता है।} ^{कोडफ्रेश का मिशन "कोड से क्लाउड तक सब कुछ स्वचालित और सरल करना।"} ^{एक सॉफ्टवेयर इंजीनियर के रूप में, कोस्टिस के पास अनुप्रयोगों को कंटेनर में रखने, CI / CD पाइपलाइनों के निर्माण और जावा अनुप्रयोगों के विकास के कई वर्षों का अनुभव है।} ^{वह ग्रीस में रहता है और रोलर स्केटिंग पसंद करता है।} ^{जैसा कि कहा जाता है, "अगर कुछ दर्द का कारण बनता है, तो इसे अधिक बार करें।"} ^{निरंतर एकीकरण, संक्षेप में, उच्च आवृत्ति के साथ एकीकरण कदम की पुनरावृत्ति है जिसके कारण "दर्द" होता है।} ^{यह लेख इस बारे में है - विकास के "दर्द" के बारे में और इसे कैसे कम किया जाए।}

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

- क्या आप अपनी टीम में निरंतर एकीकरण का उपयोग करते हैं?
- हाँ, निश्चित रूप से, हम उपकरण X का उपयोग करते हैं!

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

इसलिए, हम उपकरण और तकनीकी शब्दों का उपयोग करके CI / CD के सार को समझाने के सामान्य जाल में पड़ने के बजाय, हम यह बताएंगे कि ये कार्यप्रणाली विकास प्रक्रिया के सबसे महत्वपूर्ण कारक पर आधारित हैं - लोग!

लोगों की कहानी: हार्ड टाइम्स सॉफ्टवेयर एकीकरण

एलिस, बॉब, चार्ली, डेविड और एलिजाबेथ से मिलें - ये सभी सॉफ्टवेयरको इंक के लिए काम करते हैं। SuperBigProject एप्लिकेशन बनाने पर। ऐलिस, बॉब और चार्ली डेवलपर हैं। डेविड एक परीक्षण इंजीनियर है, और एलिजाबेथ एक टीम प्रोजेक्ट मैनेजर है।

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

कुछ बिंदु पर, प्रोजेक्ट मैनेजर एलिजाबेथ पूरी टीम को इकट्ठा करता है और कहता है: "लोग, हमें पहले से ही एक रिलीज जारी करने की आवश्यकता है, इसलिए आप कोशिश करें!"

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

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

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

तो, लोग इस काल्पनिक, लेकिन बहुत यथार्थवादी कहानी में कैसा महसूस करते हैं?

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

सामान्य तौर पर, टीम के सभी सदस्य दुखी होते हैं। वैसे, यदि आपकी कंपनी अभी भी इस तरह के सॉफ़्टवेयर का विकास कर रही है, तो यह समझने की कोशिश करें कि यह विकास प्रक्रिया आपकी टीम के मनोबल के लिए हानिकारक है।

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

एकता के लिए निरंतरता जोड़ना

अब जब हमने देखा है कि "एकीकरण" का अर्थ क्या है, तो यह समझना बहुत आसान है कि "निरंतर एकीकरण" का क्या अर्थ है। जैसा कि कहा जाता है, "अगर कुछ दर्द का कारण बनता है, तो इसे अधिक बार करें।" निरंतर एकीकरण, संक्षेप में, उच्च आवृत्ति के साथ एकीकरण कदम की पुनरावृत्ति है जिसके कारण "दर्द" होता है।

प्रक्रिया को कम दर्दनाक बनाने का सबसे स्पष्ट तरीका आधिकारिक रिलीज की प्रतीक्षा करने के बजाय प्रत्येक मर्ज के बाद अधिक बार एकीकृत करना है।

जब एक टीम निरंतर एकीकरण का अभ्यास करती है, तो:

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

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

सॉफ्टवेयर विकास प्रक्रिया में निरंतर एकीकरण पारंपरिक एकीकरण से बेहतर है क्योंकि:

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

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

हार्ड टाइम्स सॉफ्टवेयर डिलीवरी

अब जब हमने नियमित एकीकरण के इतिहास पर ध्यान दिया है और निरंतर एकीकरण कैसे काम करता है, तो हम इसे विकास प्रक्रिया के अगले स्तर पर ले जा सकते हैं - निरंतर वितरण। यदि हम अपनी मूल कहानी पर लौटते हैं, तो हम सामान्य एकीकरण की प्रक्रिया के समान एक तस्वीर देखेंगे:

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

समय सीमा पर पहुंचने के बाद ही सॉफ्टवेयर वितरण नियमित, अनैतिक एकीकरण जैसी समस्याएं पैदा करता है:

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

इस समस्या का समाधान एकीकरण के मामले में उसी टेम्पलेट के रूप में है। यदि हम इसे अधिक बार बनाकर एकीकरण प्रक्रिया के दर्द को कम कर सकते हैं, तो हम सॉफ्टवेयर वितरण प्रक्रिया में भी ऐसा कर सकते हैं।

वितरण में निरंतरता जोड़ें

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

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

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

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

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

यद्यपि इन सभी आवश्यकताओं को पूरा करने के लिए "क्लाउड" निश्चित रूप से मदद कर सकता है, प्रोग्रामर, डेवलपर्स और ऑपरेटरों दोनों की एक टीम को एक निश्चित स्तर के अनुशासन की आवश्यकता होती है, जो वास्तव में निरंतर सॉफ़्टवेयर वितरण की प्रक्रिया को सुनिश्चित करता है।

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

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

यदि आप एक सीडी का उपयोग करते हैं, तो सॉफ्टवेयर जीवन चक्र को निम्नानुसार दर्शाया जा सकता है:

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

आपकी जानकारी के लिए, निरंतर वितरण के बारे में, साथ ही साथ निरंतर एकीकरण के बारे में, एक पूरी पुस्तक भी लिखी गई है जिसमें से आप इस पद्धति के विवरण का पता लगा सकते हैं।

बोनस: निरंतर तैनाती

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

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

आपको यह समझना चाहिए कि विकास की प्रक्रिया के लिए प्रत्येक बाद का दृष्टिकोण पिछले दृष्टिकोण के कार्यान्वयन पर आधारित है।

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

निम्नलिखित आंकड़े से पता चलता है कि ऐलिस, बॉब, चार्ली, डेविड और एलिजाबेथ द्वारा सीडी और सीआई कवर किए गए सॉफ्टवेयर विकास और कार्यान्वयन प्रक्रिया के कौन से चरण हैं।

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

विज्ञापन का एक सा :)

हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक ऑर्डर देकर या अपने दोस्तों को सलाह देकर, $ 4.99 से डेवलपर्स के लिए क्लाउड VPS , प्रवेश स्तर के सर्वरों के अनूठे एनालॉग पर हैबर उपयोगकर्ताओं के लिए 30% छूट का समर्थन करें, जो हमने आपके लिए आविष्कार किया है: VPS (KVM) E5-2650 v4 (6) के बारे में पूरी सच्चाई Cores) $ 20 से 10GB DDR4 240GB SSD 1Gbps या सर्वर कैसे साझा करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।

डेल R730xd 2 बार सस्ता? केवल हमारे पास 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV नीदरलैंड के 199 डॉलर में से है! डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $ 99 से! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?