लिखित DevOps प्रशिक्षण
DevOps संगठन को टेस्ट ऑटोमेशन की ज़रूरत क्यों है?
यदि आपके सॉफ़्टवेयर डिलीवरी विभाग में अब तक ठीक टेस्ट ऑटोमेशन नहीं है, तो डेवलपमेंट और टेस्टिंग के बीच तालमेल की कमी है। डेवलपरों को गुणवत्ता का फ़ीडबैक तब मिलता है जब वे दूसरे कामों में लग चुके हैं। वे अक्सर अपने लिखे या छूटे कोड और दोषों का संबंध नहीं देख पाते। उस समय के संदर्भ में लौटने की मेहनत उत्पादकता घटाती है। देर से फ़ीडबैक मिलने पर सिस्टम और दोष का संबंध जटिल और अस्पष्ट होता है। अस्थायी उपाय के बिना अच्छी गुणवत्ता का सुधार मिलना कठिन है।
ऑटोमेशन के बिना DevOps संगठन को गुणवत्तापूर्ण उत्पाद और सेवाएँ देने में ज़्यादा समय और पैसे लगेंगे। 21वीं सदी में यह किसी तकनीकी संगठन के लिए बढ़ने योग्य व्यवसाय मॉडल नहीं है, चाहे वह किसी भी उद्योग में हो।
आप टेस्ट ऑटोमेट कर सकते हैं,
लेकिन गुणवत्ता बनाने के लिए टीम की समझ चाहिए
DevOps टीम जितने संभव हों उतने टेस्ट केस ऑटोमेट करे। टेस्ट ऑटोमेट हो सकते हैं, लेकिन गुणवत्ता बनाने की टीम की सोच नहीं। ऐसे कामों पर लोगों का समय न लगाएँ जिन्हें सॉफ़्टवेयर बार-बार कर सकता है।
अच्छे टेस्ट ऑटोमेशन के DevOps सिद्धांत
- टेस्ट ऑटोमेशन से काम की गुणवत्ता पर तेज़ और शुरुआती फ़ीडबैक मिले।
- एक जैसी परिस्थितियों में अलग-अलग रन के परिणाम सुसंगत, पूर्वनिर्धारित और दोहराने योग्य हों।
- टेस्ट ग़लत पॉज़िटिव न दें।
- कुछ भरोसेमंद ऑटोमेटेड टेस्ट, बहुत से मैन्युअल और अविश्वसनीय टेस्ट से बेहतर हैं जिनके नतीजे समान परिस्थितियों में भी बदल सकते हैं।
- पहले उन मुख्य फ़ीचर और लाभों को जाँचें जो सिस्टम आंतरिक और बाहरी ग्राहकों को देते हैं। इतना ऑटोमेशन भी किसी ऑटोमेशन के न होने से बहुत बेहतर है।
- फिर जितने संभव हों उतने टेस्ट केस ऑटोमेट करें, ताकि DevOps टीम अपने लोगों के समय का बेहतर इस्तेमाल करे।
- धीमे और समय-समय पर मिलने वाले फ़ीडबैक से बचें। जब आप या कोई डेवलपर ट्रंक में कोड चेक इन करने की कोशिश करे, तुरंत फ़ीडबैक चाहिए।
- ऑटोमेटेड टेस्ट धीमे हैं, तो टेस्ट और/या सॉफ़्टवेयर तेज़ करें। यह भरोसेमंद डिलीवरी प्लैटफ़ॉर्म और पाइपलाइन के साथ ग्राहक सेवा की गुणवत्ता के लिए भी ज़रूरी है। और तेज़ नतीजों के लिए टेस्ट समानांतर चलाएँ।
- टेस्ट-ड्रिवन डेवलपमेंट पर विचार करें। पहले ऑटोमेटेड टेस्ट लिखें, फिर सॉफ़्टवेयर बनाएँ।
निरंतर डिलीवरी और डिप्लॉयमेंट पाइपलाइन के लिए टेस्ट ऑटोमेशन अहम है
जैसा पहले देखा, DevOps में डेवलपर खुद कोड प्रोडक्शन में डिप्लॉय कर सकते हैं। शुरुआती DevOps टीमों में देखा गया कि डेवलपर ट्रंक में कोड जल्दी चेक इन और टिकट बंद करते हैं, लेकिन प्रोडक्शन रिलीज़ का बटन दबाने से हिचकते हैं। उन्हें प्रोडक्शन बिगड़ने और दोष अपने ऊपर आने का डर है।
व्यापक और भरोसेमंद ऑटोमेटेड टेस्ट कवरेज बनाने के बाद ही टीमों ने यह डर दूर किया।
Google में डेवलपर ट्रंक में कोड चेक इन करे, तो शुरुआती स्टैटिक कोड, दोहराव और टेस्ट कवरेज विश्लेषण के बाद करीब दस लाख ऑटोमेटेड टेस्ट केस चलते हैं। सभी जाँचें पास होने पर ट्रंक से बिल्ड बनता है, प्रोडक्शन में जाता है और अन्य सर्वरों पर कॉपी होता है। इसी तरह Google की 5,000 छोटी और स्वतंत्र टीमें उत्पादक रहती हैं और हर दिन दसियों हज़ार प्रोडक्शन डिप्लॉयमेंट करती हैं। टेस्ट ऑटोमेशन के बिना यह संभव नहीं होता।
तेज़ और भरोसेमंद फ़ीडबैक से ही डिप्लॉयमेंट पाइपलाइन सुरक्षित और सही बनी रहती है। ऑटोमेटेड टेस्ट विफल हों और पाइपलाइन रुक जाए, तो कोई और चेक-इन करने से पहले टीम त्रुटिपूर्ण कोड और कॉन्फ़िगरेशन ठीक करती है। पाइपलाइन में कोई ऐसी त्रुटि मिले जिसे ऑटोमेटेड टेस्ट पहले पहचानकर रोक सकता था, तो वह टेस्ट केस बनाएँ और टेस्ट रिपॉज़िटरी में जोड़ें।
ऑटोमेट किए जा सकने वाले टेस्ट
- यूनिट टेस्ट: ऐप्लिकेशन के अलग-अलग फ़ंक्शन, क्लास या मॉड्यूल जाँचते हैं।
- एक्सेप्टेंस टेस्ट: ग्राहकों को मिलने वाले फ़ीचर और लाभ जाँचते हैं।
- इंटीग्रेशन (सेवा) टेस्ट: ऐप्लिकेशन के आपसी काम और शुरू से अंत तक सेवा का प्रवाह जाँचते हैं।
- प्रदर्शन और स्ट्रेस टेस्ट: जाँचते हैं कि अपेक्षित और अप्रत्याशित ग्राहक लोड में सेवाएँ कितनी अच्छी तरह स्केल करती हैं। यह सबसे अधिक इस्तेमाल होने वाली सेवाओं के लिए खास ज़रूरी है।
- गैर-कार्यात्मक टेस्ट: सुरक्षा, उपलब्धता, क्षमता और स्केलेबिलिटी जाँचते हैं।
यदि यूनिट और एक्सेप्टेंस टेस्ट ऑटोमेट करना मुश्किल है और आप इंटीग्रेशन टेस्ट ऑटोमेशन पर ज़्यादा निर्भर हैं, तो शायद आर्किटेक्चर के हिस्से आपस में बहुत निर्भर हैं। उन्हें अलग करने के तरीके खोजें।
निष्कर्ष
इस अध्याय में हमने टेस्ट ऑटोमेशन का महत्व समझाया। इससे सुरक्षित और तेज़ डिलीवरी संभव होती है।
आपका संगठन DevOps अपनाए या नहीं, टेस्ट ऑटोमेशन के बिना सफल, उत्पादक और लाभदायक विश्वस्तरीय IT संगठन बनाना संभव नहीं है, जो आंतरिक और बाहरी ग्राहकों को अच्छी सेवा दे।
