सेलेक्ट में निरंतर एकीकरण

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

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

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

निरंतर एकीकरण क्या है?

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

निरंतर एकीकरण निम्नलिखित सिद्धांतों पर आधारित है:

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

इन सभी सिद्धांतों को व्यवहार में लाने से क्या प्राप्त हो सकता है?
सबसे पहले, एक बार और सभी के लिए अलग-अलग प्रोग्रामर द्वारा किए गए परिवर्तनों और परिवर्तनों की समस्या को हल करने के लिए: सब कुछ स्वचालित रूप से होता है।

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

तीसरा, नियमित परीक्षण आपको उचित स्तर पर उत्पाद की गुणवत्ता बनाए रखने की अनुमति देता है।

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

सीआई प्रणाली चयन

पहला निरंतर एकीकरण उपकरण जिसका हमने उपयोग करने की कोशिश की वह था एटलसियन बांस। उस समय तक, हम पहले से ही एटलसियन JIRA का सक्रिय रूप से उपयोग कर रहे थे, और बांस के पक्ष में मुख्य तर्क उपयोगकर्ता इंटरफ़ेस की एकता और अन्य एटलसियन सेवाओं के साथ एकीकरण में आसानी थी।

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

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

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

एक और खोज में एक उपयुक्त CI उपकरण पाया गया: यह TeamCity, JetBrains उत्पाद है। इसके निस्संदेह फायदे हैं:

• सेटअप और प्रशासन की सादगी;
• मानक के रूप में "बॉक्स से बाहर" फ़ंक्शन का एक काफी बड़ा सेट;
• विभिन्न विकास वातावरणों के साथ एकीकृत करने की क्षमता;
• हमारे द्वारा उपयोग किए जाने वाले एटलसियन उत्पादों (JIRA और Confluence) के साथ एकीकृत करने की क्षमता;
• एक टेम्पलेट परियोजना की उपस्थिति;
• काफी लचीली लाइसेंसिंग शर्तें।

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

एक निष्कर्ष के बजाय

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

• 102 परियोजनाएं;
• 280 विधानसभाएं;
• 320 जीबी कलाकृतियों;
• प्रत्येक सप्ताह लगभग 1,000 नए बिल्ड किए जाते हैं।

नियमित संचालन के स्वचालन के परिणामस्वरूप, हम एक सप्ताह में लगभग 33 घंटे बचाने में सक्षम थे। हम जारी समय को मौजूदा सेवाओं के विकास और सुधार के साथ-साथ नए लोगों की शुरूआत के लिए समर्पित करते हैं।

जो लोग हबेरा की पोस्ट पर टिप्पणी नहीं कर सकते, हम अपने ब्लॉग पर आमंत्रित करते हैं।