लिखित DevOps प्रशिक्षण

निरंतर डिलीवरी और डिप्लॉयमेंट की DevOps पाइपलाइन कैसे डिज़ाइन करें?

कई संगठनों में, शायद आपके यहाँ भी, डेवलपर अलग ब्रांच में अकेले कोड लिखते हैं। इससे उनकी व्यक्तिगत उत्पादकता बढ़ती दिखती है, लेकिन टीम की उत्पादकता घटती है।

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

निरंतर इंटीग्रेशन के बिना चुनौती बढ़ती है

कोड मर्ज करना कठिन और थकाने वाला है। इसलिए ज़्यादातर टीमें इंटीग्रेशन या यूज़र एक्सेप्टेंस टेस्ट के लिए ऐप्लिकेशन सौंपने से ठीक पहले मर्ज करती हैं। इससे समस्या बढ़ती है। वे सफल इंटीग्रेशन और साझा कोड की गुणवत्ता की पूरी ज़िम्मेदारी गुणवत्ता आश्वासन टीम को दे देती हैं। इससे परियोजनाओं में देरी, बजट में बड़ी कमी, कम मनोबल और अधूरे लक्ष्य व वादे समझ में आते हैं। दुनिया भर की कंपनियाँ सालाना करीब 600 अरब USD बिना बजट और योजना वाले IT काम, यानी दोबारा काम और अस्थायी उपायों पर गँवाती हैं।

ट्रंक (मुख्य कोड ब्रांच) पर आधारित डेवलपमेंट कैसे मदद करता है?

इस चुनौती का समाधान है ट्रंक-आधारित डेवलपमेंट के साथ निरंतर इंटीग्रेशन और टेस्ट ऑटोमेशन। यह वर्शन कंट्रोल में ब्रांच इस्तेमाल करने का मॉडल है, जिसमें डेवलपर «ट्रंक» नाम की एक ही ब्रांच पर साथ काम करते हैं। वे लंबे समय तक रहने वाली अन्य डेवलपमेंट ब्रांच बनाने के दबाव का विरोध करते हैं।

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

निरंतर इंटीग्रेशन से डिप्लॉय किए जा सकने वाले छोटे हिस्सों में कोड दें

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

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

यदि इस DevOps सिद्धांत से असहमत हैं, तो खुद से पूछें: पहले से त्रुटिपूर्ण मॉड्यूल में नया कोड क्यों जोड़ना चाहेंगे?

आपके पास सही वजह हो सकती है। बस तकनीकी ऋण और एक के ऊपर एक अस्थायी उपाय जोड़ने से बचें।

गेटेड कमिट से ट्रंक-आधारित डेवलपमेंट को अतिरिक्त सुरक्षा

DevOps टीम गेटेड कमिट भी इस्तेमाल कर सकती है। इससे गुणवत्ता बढ़ती है और ट्रंक को सुरक्षा की एक और परत मिलती है।

डेवलपर जब भी कोड चेक इन करना चाहे, ऑटोमेटेड टेस्ट पहले उसे जाँचते हैं। जाँच सफल होने पर ही कोड औपचारिक रूप से ट्रंक में जाता है।

सॉफ़्टवेयर इंजीनियरिंग वैल्यू स्ट्रीम के हर चरण में प्रोडक्शन जैसे परिवेश रखें

कई IT संगठनों में प्रोडक्शन और प्री-प्रोडक्शन (डेवलपमेंट, इंटीग्रेशन और टेस्टिंग) परिवेश अलग होते हैं। ऑपरेटिंग सिस्टम, डेटाबेस, तीसरे पक्ष के टूल और API की कॉन्फ़िगरेशन, वर्शन और पैच अलग हो सकते हैं। अपना कोड भी अलग-अलग परिवेशों में अलग वर्शन पर हो सकता है। प्री-प्रोडक्शन और प्रोडक्शन में JVM वर्शन का मामूली फ़र्क भी पूरा डिप्लॉयमेंट सफल या विफल कर सकता है। परिवेश पर पूरा नियंत्रण और उसके अंदर की जानकारी नहीं है, तो उसके नतीजे नहीं जान सकते।

परिवेश प्रबंधन को रोज़ के डेवलपमेंट और डिलीवरी का हिस्सा बनाएँ

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

IT वैल्यू स्ट्रीम आपके सॉफ़्टवेयर के कोड और उसे चलाने वाले परिवेश, दोनों से लाभ देती है। डेवलपमेंट और ऑपरेशंस विशेषज्ञ समझें कि इसके दो बराबर अहम हिस्से हैं:

1. आंतरिक और/या बाहरी ग्राहकों को लाभ देने वाला सॉफ़्टवेयर बनाने का कोड।
2. आपका सॉफ़्टवेयर चलाने के लिए प्री-प्रोडक्शन और प्रोडक्शन परिवेश बनाने का कोड।

सॉफ़्टवेयर और परिवेश के लिए एक आधिकारिक स्रोत, ट्रंक, रखें
(यानी Infrastructure as Code (IaC) अपनाएँ)

DevOps में प्री-प्रोडक्शन और प्रोडक्शन परिवेश बनाने का काम ट्रंक का हिस्सा होता है। यही Infrastructure as Code (IaC) का सबसे शुद्ध रूप है। डेवलपमेंट और ऑपरेशंस विशेषज्ञ साथ मिलकर इन्फ़्रास्ट्रक्चर को कोड में बनाते हैं। अलग-थलग ऑपरेशंस टीम अक्सर उस सॉफ़्टवेयर की खास ज़रूरतें नहीं जानती जिसे वहाँ चलाना है।

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

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

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

काम पूरा होने की नई परिभाषा (DoD)

निरंतर डिलीवरी और डिप्लॉयमेंट पाइपलाइन चलने पर तय करें कि काम पूरा होने की परिभाषा (Definition of Done, DoD) में अब क्या शामिल होगा।

काम तब «पूरा» माना जाए जब उससे जुड़े ग्राहक फ़ीचर और लाभ:

• ट्रंक से अपने आप या एक क्लिक में बनाए गए हों,
• प्रोडक्शन जैसे परिवेशों में ऑटोमेटेड टेस्ट से जाँचे गए हों,
• प्रोडक्शन जैसे परिवेशों में दिखाए गए हों,
• डिप्लॉय करने के लिए तैयार हों या बेहतर हो कि अपने आप या एक क्लिक में चल रहे प्रोडक्शन में डिप्लॉय हो चुके हों।

निष्कर्ष

DevOps में कोड का इंटीग्रेशन परियोजना के अंत की जगह रोज़ के काम में होता है। डेवलपर, ऑपरेशंस और सूचना सुरक्षा विशेषज्ञ जीवनचक्र के दौरान डिप्लॉयमेंट का बार-बार पूर्वाभ्यास करते हैं। इससे लाइव डिप्लॉयमेंट सुचारु होने की संभावना बढ़ती है।

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