निरंतर वितरण परिनियोजन मॉडल
- 4 मिनट्स
आपने सॉफ़्टवेयर-डिलीवरी मॉडल के रूप में "महाकाव्य परिनियोजन" के कई नुकसानों के बारे में सीखा है, लेकिन यह जानना कि क्या अच्छी तरह से काम नहीं करता है, केवल आधी लड़ाई है। इस इकाई में, आप उस अखंड विधि के विकल्प के बारे में सीखते हैं, और यह बेहतर विश्वसनीयता के आपके लक्ष्य को कैसे आगे बढ़ा सकता है।
यह दो संबंधित शब्दों को अलग करने के लायक भी है जो कभी-कभी एक दूसरे के स्थान पर उपयोग किए जाते हैं:
- निरंतर वितरण: स्वचालित परीक्षणों से गुजरने वाला प्रत्येक परिवर्तन उत्पादन के लिए तैनात करने के लिए तैयार है, लेकिन उत्पादन के लिए वास्तविक रिलीज एक मैनुअल अनुमोदन द्वारा गेट किया जाता है।
- निरंतर परिनियोजन: स्वचालित परीक्षणों से गुजरने वाला प्रत्येक परिवर्तन स्वचालित रूप से उत्पादन के लिए जारी किया जाता है, जिसमें कोई मैन्युअल गेट नहीं होता है।
दोनों एक ही नींव (लगातार एकीकरण, स्वचालित परीक्षण, दोहराने योग्य पाइपलाइन) पर निर्भर करते हैं। यह मॉड्यूल उन साझा नींवों पर केंद्रित है।
निरंतर वितरण क्या है?
निरंतर वितरण एक ऐसी विधि है जिसके द्वारा आपके कोडबेस में हर परिवर्तन को तेज़, कम तनावपूर्ण, कम जोखिम भरा और अधिक प्रतिलिपि प्रस्तुत करने योग्य तरीके से जारी किया जाता है। प्रत्येक सॉफ़्टवेयर परिनियोजन या एक महाकाव्य घटना को अपडेट करने के बजाय, निरंतर वितरण इसे एक त्वरित, नियमित, पूर्वानुमानित अनुभव में बदल देता है जो मांग पर होता है।
परिनियोजन आवृत्ति: निरंतर वितरण मॉडल के साथ, परिनियोजन अक्सर होता है। ताल मासिक, साप्ताहिक, दैनिक या प्रति घंटा भी हो सकता है। कुंजी यह है कि आप छोटे, अधिक केंद्रित परिवर्तनों को परिनियोजित करते हैं, अधिक बार.
कोड कमिट द्वारा ट्रिगर: पहले से शेड्यूल की गई रिलीज़ विंडो की प्रतीक्षा करने के बजाय, कोड कमिट होने पर डिलीवरी पाइपलाइन शुरू हो जाती है. यह कोड सॉफ्टवेयर, इन्फ्रास्ट्रक्चर या यहां तक कि सॉफ्टवेयर कॉन्फ़िगरेशन जैसी चीजें भी हो सकता है। प्रत्येक परिवर्तन को फिर बनाया जाता है, परीक्षण किया जाता है और रिलीज के लिए तैयार रखा जाता है। आपके संगठन के नियंत्रणों के आधार पर, अनुमोदन के बाद भी उत्पादन में प्रचार हो सकता है.
स्वचालित परीक्षण: आप न केवल कोड का परीक्षण करने के लिए एकीकृत स्वचालित परीक्षण का उपयोग कर सकते हैं, बल्कि उन परीक्षणों के परिणामों पर त्वरित प्रतिक्रिया भी प्रदान कर सकते हैं। यह त्वरित प्रतिक्रिया है जो आपको असफल परीक्षणों से जल्दी से पुनरावृति और पुनर्प्राप्त करने की अनुमति देती है।
एक बार आपके कोड का परीक्षण हो जाने के बाद, आप परीक्षण, क्यूए, और इसके बाद जैसे मंचित वातावरण की एक श्रृंखला में तैनाती का अंत तक परीक्षण कर सकते हैं। इन परिवेशों के माध्यम से अपने परिनियोजन को रोल करना परिनियोजन अनुभव का एक एकीकृत हिस्सा बन जाता है।
ऐतिहासिक रिकॉर्ड: न केवल आप परिनियोजन गतिविधियों का एक ऐतिहासिक रिकॉर्ड चाहते हैं, आप किसी भी समय अपने उत्पादन वातावरण को समेटने में सक्षम होना चाहते हैं। आप समझना चाहते हैं कि किस परिनियोजन ने आपका वर्तमान उत्पादन परिवेश बनाया है. इस ज्ञान के साथ, आप कॉन्फ़िगरेशन, परीक्षण के परिणाम और कोड जैसी चीजों का पता लगा सकते हैं, जो तैनाती को ट्रिगर करने वाले व्यक्तिगत पुल अनुरोध पर वापस आ जाते हैं।
परिनियोजन लक्ष्य
अब जब आप जानते हैं कि निरंतर डिलीवरी कैसे काम करती है, तो उन लक्ष्यों पर विचार करें जो निरंतर डिलीवरी और अन्य DevOps प्रथाएं सॉफ़्टवेयर समाधान तैनात करते समय आपको प्राप्त करने में मदद करती हैं।
लक्ष्य 1: उन सेवाओं की विश्वसनीयता बढ़ाते हुए सेवाओं को तैनात करने से जुड़े तनाव को कम करें
सॉफ्टवेयर और बुनियादी ढांचे की तैनाती के तनाव को कम करने से उन्हें चलाने वाले इंजीनियरों के दिन-प्रतिदिन के अनुभव में सुधार होता है। विश्वसनीयता में परिणामी वृद्धि से अंतिम उपयोगकर्ताओं को भी लाभ होता है, जो कम आउटेज और व्यवधान देखते हैं।
लक्ष्य 2: उस समय के बीच के समय को कम करें जब आप जानते हैं कि परिवर्तन की आवश्यकता है और जब उस परिवर्तन को उत्पादन में परिनियोजित किया जाता है
उदाहरण के लिए, मान लीजिए कि आपने राजस्व को प्रभावित करने वाले कोड दोष की पहचान कर ली है और आप जानते हैं कि इसे ठीक करने का तरीका ठीक है। परिपक्व DevOps प्रथाओं के साथ, प्रतिबद्धता से उत्पादन तक का रास्ता छोटा और पूर्वानुमानित है। परिवर्तन बनाया गया है, प्रासंगिक वातावरण में स्वचालित रूप से परीक्षण किया जाता है, और मिनटों के भीतर रिलीज के लिए तैयार किया जाता है। एक बार आवश्यक अनुमोदन देने के बाद, इसे भविष्य की रिलीज विंडो के लिए आयोजित करने के बजाय उत्पादन में बढ़ावा दिया जा सकता है।
लक्ष्य 3: एक विचार रखने और प्रयोग करने योग्य सॉफ़्टवेयर वितरित करने के बीच का समय कम करें
यह लक्ष्य पिछले वाले के समान है, लेकिन यह सुधार के बजाय नवाचार पर ध्यान केंद्रित करता है। किसी नए विचार पर कार्य करने में आपको कितना समय लगता है? इस परिनियोजन मॉडल के साथ, आप एक नई अवधारणा को उत्पादन प्रणाली में इस विश्वास के साथ एकीकृत कर सकते हैं कि यह जोड़ वर्तमान प्रणाली को नहीं तोड़ेगा या बाधित नहीं करेगा। यह आत्मविश्वास आपको नई सुविधाओं को शीघ्रता से वितरित करने देता है।
परिनियोजन परिणाम
इस इकाई में चर्चा किए गए लक्ष्य केवल सैद्धांतिक आकांक्षाएं नहीं हैं, वे मापने योग्य हैं। 2014 से, DevOps रिसर्च एंड असेसमेंट (DORA) टीम ने सॉफ्टवेयर डिलीवरी प्रदर्शन पर वार्षिक स्टेट ऑफ DevOps शोध प्रकाशित किया है। हाल के वर्षों में, इस काम को एक्सेलेरेट स्टेट ऑफ DevOps रिपोर्ट के रूप में प्रकाशित किया गया है। वर्तमान DORA मॉडल पांच डिलीवरी मेट्रिक्स को ट्रैक करता है:
- परिनियोजन आवृत्ति
- लीड टाइम बदलें
- विफल दर बदलें
- परिनियोजन पुनर्प्राप्ति समय विफल
- परिनियोजन पुनर्कार्य दर
साल-दर-साल, शोध से पता चलता है कि उच्च प्रदर्शन करने वाली टीमें अधिक बार परिवर्तन करती हैं, प्रतिबद्धता से उत्पादन में तेजी से आगे बढ़ती हैं, असफल तैनाती से जल्द ही उबरती हैं, और तैनाती से संबंधित मुद्दों को ठीक करने में कम समय बिताती हैं। नवीनतम शोध और मीट्रिक परिभाषाओं के लिए, DORA के सॉफ़्टवेयर डिलीवरी मेट्रिक्स देखें।
ये परिणाम इस विचार को मान्य करते हैं कि परिनियोजन अभ्यास मायने रखते हैं।
अपने ज्ञान की जाँच करें
प्रतिक्रिया
क्या यह पेज मददगार था?
नहीं
इस विषय में मदद चाहिए?
क्या आप इस विषय को आपको स्पष्ट करने या आपका मार्गदर्शन के लिए Ask Learn का उपयोग करना चाहते हैं?