8.1 CI/CD और डिलीवरी

अवलोकन और प्रेरणा

कंटीन्यूअस इंटीग्रेशन और कंटीन्यूअस डिलीवरी (CI/CD) कोड लिखने और इसे उपयोगकर्ताओं के सामने सुरक्षित रूप से रखने के बीच का संयोजी ऊतक हैं। कंटीन्यूअस इंटीग्रेशन का मतलब है कि हर परिवर्तन को बार-बार एक साझा मेनलाइन में मर्ज किया जाता है, फिर स्वचालित रूप से बनाया और परीक्षित किया जाता है, ताकि एकीकरण समस्याएँ एक लंबे रिलीज़ चक्र के अंत के बजाय मिनटों में सामने आएँ। कंटीन्यूअस डिलीवरी का मतलब है कि पाइपलाइन पास करने वाला हर परिवर्तन डिप्लॉय करने योग्य स्थिति में रखा जाता है, ताकि उत्पादन में रिलीज़ करना एक इंजीनियरिंग हड़बड़ी के बजाय एक व्यावसायिक निर्णय बन जाए। कंटीन्यूअस डिप्लॉयमेंट एक कदम और आगे जाता है और बिना किसी मानवीय गेट के हर पास होने वाले परिवर्तन को स्वचालित रूप से रिलीज़ करता है।

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

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

यह भी देखें: अध्याय 8.4 (प्लेटफ़ॉर्म इंजीनियरिंग और डेवलपर अनुभव), अध्याय 8.5 (परीक्षण और प्रक्रिया स्वचालन), और अध्याय 7.4 (उत्पाद एनालिटिक्स और प्रयोग) फ़ीचर-फ़्लैग (रनटाइम स्विच जो बिना फिर से डिप्लॉय किए उपयोगकर्ताओं को कार्यक्षमता उजागर करते हैं) और प्रगतिशील डिलीवरी (स्वास्थ्य मीट्रिक की स्वचालित निगरानी करते हुए धीरे-धीरे एक परिवर्तन जारी करना) द्वारा सक्षम किए गए प्रयोग प्रथाओं के लिए।

मुख्य सिद्धांत

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

सिफारिशें

पाइपलाइन को गुणवत्ता गेट की एक श्रृंखला के रूप में डिज़ाइन करें

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

एक बार बनाएँ, हर जगह प्रोन्नत करें

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

पाइपलाइन को नीति के लिए प्रवर्तन बिंदु बनाएँ

आवश्यक जाँचों (कोड समीक्षा स्वीकृति, परीक्षण कवरेज सीमाएँ, सुरक्षा स्कैन परिणाम, हस्ताक्षरित कमिट) को सीधे पाइपलाइन और ब्रांच सुरक्षा नियमों में एन्कोड करें। एक विकी में रहने वाली मैनुअल नीति समयसीमा के दबाव में नियमित रूप से बाईपास कर दी जाती है। पाइपलाइन में एन्कोड की गई नीति हर परिवर्तन पर समान रूप से और स्वचालित रूप से लागू होती है।

मेनलाइन को हमेशा रिलीज़ करने योग्य रखें

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

डिप्लॉयमेंट रणनीतियों को जानबूझकर चुनें

डिप्लॉयमेंट रणनीति को सेवा के जोखिम और विस्फोट त्रिज्या से मिलाएँ:

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

स्वचालित रोलबैक के साथ प्रगतिशील डिलीवरी अपनाएँ

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

विनियमित वातावरण के लिए रिलीज़ प्रबंधन और परिवर्तन नियंत्रण प्रदान करें

विनियमित सेटिंग में, एक हल्का लेकिन वास्तविक परिवर्तन-प्रबंधन रिकॉर्ड रखें। स्वचालित रूप से कैप्चर करें कि हर परिवर्तन को किसने स्वीकृत किया, कौन से परीक्षण चले, और कौन सी कलाकृति डिप्लॉय की गई। वास्तव में उच्च-जोखिम वाले परिवर्तनों के लिए परिवर्तन सलाहकार प्रक्रियाओं का उपयोग करें, लेकिन उन्हें उन्हीं मामलों के लिए आरक्षित रखें। हर नियमित परिवर्तन को साप्ताहिक बोर्ड के माध्यम से रूट करना स्वचालन के मूल्य को नष्ट करता है। इसके बजाय मानक, पूर्व-स्वीकृत परिवर्तन प्रकारों के लिए लक्ष्य रखें जो बिना समारोह के पाइपलाइन के माध्यम से बहते हैं।

ट्रेड-ऑफ़: पक्ष और विपक्ष

दृष्टिकोण	पक्ष	विपक्ष	सबसे अच्छा फिट
कंटीन्यूअस डिलीवरी (मैनुअल रिलीज़ गेट)	व्यवसाय समय को नियंत्रित करता है; विनियमित रिलीज़ विंडो के लिए मज़बूत	मेनलाइन को शिप करने योग्य रखने के लिए अनुशासन की आवश्यकता	परिवर्तन विंडो वाले उद्यम
कंटीन्यूअस डिप्लॉयमेंट (पूरी तरह स्वचालित)	सबसे तेज़ फ़ीडबैक; सबसे छोटे बैच	परिपक्व परीक्षण और अवलोकनीयता की माँग करता है	उच्च-भरोसे वाली, उच्च-आवृत्ति टीमें
ब्लू-ग्रीन	तत्काल रोलबैक; सरल मानसिक मॉडल	स्विच के दौरान वातावरण लागत दोगुनी करता है	तेज़ी से पूर्ववत करने की आवश्यकता वाली महत्वपूर्ण सेवाएँ
कैनरी + प्रगतिशील डिलीवरी	विस्फोट त्रिज्या सीमित करता है; डेटा-संचालित	बनाना जटिल; अच्छे मीट्रिक की आवश्यकता	बड़े पैमाने पर उपयोगकर्ता-सामने वाले सिस्टम
फ़ीचर फ़्लैग	डिप्लॉय को रिलीज़ से अलग करता है	साफ़ न किए जाने पर फ़्लैग ऋण	अधूरा काम सुरक्षित रूप से शिप करने वाली टीमें

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. कमिट-स्टेज फ़ीडबैक समय के लिए आपका लक्ष्य क्या है, और जब सुइट दस मिनट से आगे निकल जाती है तो क्या काटा जाता है? एक धीमा कमिट स्टेज चुपचाप कंटीन्यूअस इंटीग्रेशन को मार देता है, क्योंकि डेवलपर हरे रंग की प्रतीक्षा करना बंद कर देते हैं और परिवर्तनों को बैच करना शुरू कर देते हैं। अभी संख्या तय करें (यह अध्याय दस मिनट से कम के लिए तर्क देता है) और इसे बनाए रखने का तंत्र तय करें: समानांतर वर्कर, एक सख्त परीक्षण पिरामिड, और धीमी एकीकरण जाँचों को बाद के चरण में ले जाना। उद्यम पैमाने पर यह एक प्लेटफ़ॉर्म निर्णय है, क्योंकि सैकड़ों इंजीनियर एक ही पाइपलाइन साझा करते हैं और हर जोड़ा गया मिनट हर कमिट में गुणा हो जाता है। बैठक में वास्तविक डेटा लाएँ: वर्तमान p50 और p95 पाइपलाइन अवधि, सबसे धीमे दस परीक्षण, और लोग कितनी बार प्रतीक्षा करने के बजाय फिर से चलाते हैं। यदि आप लक्ष्य नहीं बता सकते और इसे संख्याओं के साथ बचाव नहीं कर सकते, तो आपकी पाइपलाइन एक CI पोशाक पहने बैच प्रक्रिया की ओर बह रही है।

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

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

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

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

6. मानवीय गेट वाली कंटीन्यूअस डिलीवरी और पूर्ण कंटीन्यूअस डिप्लॉयमेंट के बीच सीमा कहाँ है, और रोलबैक सीमाएँ कौन तय करता है? कंटीन्यूअस डिलीवरी एक व्यक्ति को रिलीज़ समय के नियंत्रण में रखती है, जो सांविधिक परिवर्तन विंडो और उच्च-विस्फोट-त्रिज्या सिस्टम के अनुकूल है, जबकि कंटीन्यूअस डिप्लॉयमेंट हर पास होने वाले परिवर्तन को स्वचालित रूप से शिप करता है और सुरक्षित रहने के लिए परिपक्व परीक्षण, अवलोकनीयता, और स्वचालित रोलबैक की माँग करता है। एक बड़े या विनियमित संगठन के लिए उत्तर शायद ही कभी समान होता है: आपकी मार्केटिंग साइट लगातार डिप्लॉय कर सकती है जबकि आपका भुगतान कोर एक दस्तावेज़ीकृत मानवीय गेट रखता है, और प्रति सेवा स्तर वह रेखा खींचना अनावश्यक घर्षण और लापरवाह स्वचालन दोनों को रोकता है। प्रतिस्पर्धी विचार गति और बैच आकार बनाम नियंत्रण और ऑडिटेबिलिटी हैं, साथ ही उन स्वास्थ्य मीट्रिक की इंजीनियरिंग लागत जिनकी स्वचालित रोलबैक को आवश्यकता होती है। साक्ष्य लाएँ: प्रति-सेवा परिवर्तन-विफलता दर, पुनर्प्राप्ति का औसत समय, वर्तमान रिलीज़ गति, और वस्तुनिष्ठ संकेत (त्रुटि दर, लेटेंसी, संतृप्ति) जिन पर आप बिना किसी मानव के प्रोन्नत या रोलबैक करने के लिए भरोसा करेंगे। सरकारी और उद्यम सेटिंग में, हर स्तर को इससे जोड़ें कि रोलबैक सीमाओं का मालिक कौन है और गेटेड रिलीज़ से पूर्ण स्वचालन की किसी भी चाल को कौन स्वीकृत करता है, ताकि निर्णय बहने के बजाय जानबूझकर हो।

क्षेत्र लेंस

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

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

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

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

उदाहरण

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

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

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

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

CI/CD निवेश पर रिटर्न परिवर्तनों के लिए कम लीड टाइम, कम परिवर्तन-विफलता दर, और घटनाएँ होने पर तेज़ रिकवरी के रूप में सामने आता है: वे मीट्रिक जिन्हें अनुसंधान लगातार डिलीवरी प्रदर्शन और संगठनात्मक परिणामों दोनों से जोड़ता है। तेज़, छोटी रिलीज़ उस समन्वय ओवरहेड को कम करती हैं जो पैमाने पर इंजीनियरिंग क्षमता खपत करता है, और स्वचालित सत्यापन उत्पादन दोषों की आग बुझाने के महँगे, मनोबल गिराने वाले काम को कम करता है।

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

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

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

स्तर 2: विकास। स्वचालित बिल्ड और यूनिट परीक्षण हर कमिट पर चलते हैं, लेकिन प्रथाएँ टीम दर टीम भिन्न होती हैं। डिप्लॉयमेंट स्क्रिप्टेड हैं फिर भी अभी भी मैनुअल रूप से ट्रिगर और पर्यवेक्षित होते हैं, कुछ वातावरण संगत हैं, और कलाकृतियाँ अभी भी प्रति चरण फिर से बनाई जा सकती हैं। जहाँ एक पाइपलाइन मौजूद है वह अक्सर एक स्नोफ्लेक है जिसे साझा नहीं किया जा सकता।

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

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

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

चर्चा के लिए विचार

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

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

• Jez Humble and David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.
• Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps.
• Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook.
• Gene Kim, Kevin Behr, and George Spafford, The Phoenix Project.
• Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering.
• Pete Hodgson, “Feature Toggles (Feature Flags)” (essay).
• ITIL (Information Technology Infrastructure Library), change management guidance.