लिखित DevOps प्रशिक्षण
गुणवत्ता सुनिश्चित करने के लिए निरंतर समीक्षा क्यों शुरू करें?
संगठन प्रोडक्शन डिप्लॉयमेंट के ठीक पहले समीक्षा, ऑडिट, निरीक्षण और अनुमोदन पर बहुत निर्भर हैं। इन्हें अक्सर ऐसे लोग करते हैं जिनका काम से दूर का या कोई संबंध नहीं है। कभी उन्हें काम की ग़लत समझ होती है और प्रोडक्शन में कोड डालने से ठीक पहले आपको उसे समझाना पड़ता है।
बाहरी नियंत्रण की समस्याएँ
कई संगठनों में आपसी भरोसा बनाने से नियंत्रण जोड़ना आसान है। इसलिए बदलाव फ़ॉर्म में और सवाल, पदानुक्रम में मंज़ूरी की नई परतें और बदलाव समझने व मंज़ूर करने के लिए ज़्यादा समय, बाहरी नियंत्रण की आम समस्याएँ हैं।
आदेश और नियंत्रण की कम भरोसे वाली संस्कृति में घटनाएँ बार-बार होती हैं। दुष्चक्र बनता है: असल काम और दोहराती समस्याएँ साफ़ नहीं दिखतीं और मुश्किल डिप्लॉयमेंट की संख्या घटाने के लिए काम बड़े बैच में होता है। लंबा लीड टाइम जल्दी बाज़ार में पहुँचने की क्षमता घटाता है। धीमे, देर से और काम न आने वाले फ़ीडबैक से टीमें ग़लतियों से नहीं सीख पातीं।
सक्षम DevOps संगठन जानते हैं कि काम और उसकी समस्याएँ सबसे अच्छी तरह वही समझते हैं जो उसके सबसे करीब हैं। अतिरिक्त बाहरी नियंत्रण और अनुमोदन से वैल्यू स्ट्रीम में लाभ नहीं जुड़ता। नेतृत्व की बड़ी चुनौती है ऐसा भरोसे का माहौल बनाना जहाँ काम दिखता हो, और असली सम्मान व आपसी भरोसा रोज़ के काम का हिस्सा हों।
समय-समय के निरीक्षण से ध्यान हटाकर रोज़ के काम में सहकर्मी समीक्षा अपनाएँ। डेवलपर, ऑपरेशंस, गुणवत्ता आश्वासन और सूचना सुरक्षा विशेषज्ञ लगातार मिलकर काम करें और एक-दूसरे का काम जाँचें, ताकि सुरक्षित डिप्लॉयमेंट हो।
बाहरी नियंत्रण के बिना जटिल काम का समन्वय
एक टीम का प्रोजेक्ट भी जटिल है। एक ही सिस्टम के अलग कंपोनेंट कई टीमें सँभालें, तो जटिलता बढ़ती है। ये उपाय आपकी टीम की मदद करेंगे:
- ऐसे बदलाव बोर्ड जिनमें प्रबंधकों के साथ विषय विशेषज्ञ हों, बदलाव से पहले अलग-अलग टीमों की निर्भरताएँ पहचानने में मदद करते हैं।
- SOA और माइक्रोसर्विस पर आधारित कम आपसी निर्भरता वाले आर्किटेक्चर से निर्भरता और संवाद की मेहनत घटती है।
- DevOps टीमों के तकनीकी प्रतिनिधि निर्भरताएँ और डेवलपमेंट व डिप्लॉयमेंट का क्रम पहचानें।
- बदलावों में तालमेल और यह देखने के लिए कि दूसरे उन्हें कैसे समझ रहे हैं, साझा चैट प्लैटफ़ॉर्म पर निरंतर संवाद करें।
- माइग्रेशन और इन्फ़्रास्ट्रक्चर बदलाव जैसे अधिक प्रभावशाली और जोखिम भरे कामों के लिए टेस्ट परिवेश में पूर्वाभ्यास और फ़ेलओवर व पूरा रोलबैक जैसे उपाय ज़रूरी हैं।
उच्च प्रदर्शन वाले संगठन सहकर्मी समीक्षा पर ज़्यादा और बाहरी मंज़ूरी पर कम निर्भर रहते हैं
Amazon, Netflix, Etsy और GitHub समेत कई अग्रणी DevOps संगठन «Pull Request» से समीक्षा और डिप्लॉयमेंट की प्रक्रिया चलाते हैं। तरीका यह है:
- डेवलपर ट्रंक से अलग डेवलपमेंट ब्रांच बनाती है। यह कुछ कार्यदिवस से ज़्यादा न रहे और इसका नाम स्पष्ट हो, जैसे «login-screen-v2»। वह वर्कस्टेशन पर स्थानीय रूप से काम करती है और नियमित रूप से ब्रांच वर्शन कंट्रोल में चेक इन करती है।
- जब ब्रांच ट्रंक में मर्ज के लिए तैयार लगे, वह समीक्षा के लिए पुल रिक्वेस्ट खोलती है।
- टीम के दूसरे सदस्यों से फ़ीडबैक और मंज़ूरी मिलने पर वह कोड ट्रंक में मर्ज करती और प्रोडक्शन में डिप्लॉय करती है।
डेटाबेस स्कीमा या सूचना सुरक्षा पर असर वाले बदलाव के लिए वह अन्य विषय विशेषज्ञों, जैसे डेटाबेस प्रशासक या सुरक्षा विशेषज्ञ, का फ़ीडबैक लेने के लिए अतिरिक्त पुल रिक्वेस्ट भेज सकती है।
समीक्षा में भी छोटे बैच रखें। वरना समय ज़्यादा लगता है और समीक्षा करने वाले इंजीनियरों पर बोझ पड़ता है। बदलाव बड़ा हो, तो जोखिम घातीय रूप से बढ़ता और समीक्षा कम भरोसेमंद होती है। बदलाव बड़ा और समझने में कठिन है, तो डेवलपर से छोटे, समझने योग्य हिस्सों में बाँटने को कहें।
वरिष्ठता या अनुभव चाहे जो हो, टीम में सभी के बदलावों की कोई और समीक्षा करे। सभी कमिट के क्रम पर नज़र रखें, ताकि संभावित टकराव पाइपलाइन या प्रोडक्शन को प्रभावित करने से पहले सुलझें।
पेयर प्रोग्रामिंग अकेले या टेस्ट-ड्रिवन डेवलपमेंट (TDD) के साथ कोड लिखते समय ही सहकर्मी समीक्षा संभव बनाती है। एक डेवलपर ऐप्लिकेशन कोड और दूसरा ऑटोमेटेड टेस्ट लिखता है। समान टीम और आवश्यकताओं पर मापा गया कि पेयर प्रोग्रामिंग 15% अधिक समय लेती है, लेकिन 85% कोडिंग त्रुटियाँ कम करती है। इसलिए विचार करें कि इसे अपनी टीम में अपनाएँ या नहीं।
काम की जगह पर सीधे कोड समीक्षा, चेक-इन की ऑटोमेटेड सूचनाएँ और समीक्षा व कोड गुणवत्ता में मदद करने वाले टूल भी अपनाने पर विचार करें।
निष्कर्ष
हर DevOps टीम को अपनी डिलीवरी की गुणवत्ता का ज़िम्मेदार बनाएँ। ऐसी संस्कृति बनाएँ जो निरंतर, अच्छी कोड समीक्षा को अच्छी कोडिंग जितना महत्व दे।
