👸🏼 💋 👧🏿 लाइन बंद करो या अपनी पाइपलाइन को पंप करो, यो 🔯 👶 💴

यदि आपकी रिलीज़ तेज़, स्वचालित और विश्वसनीय हो, तो आप इस लेख को नहीं पढ़ सकते हैं।

पहले, हमारी रिलीज़ प्रक्रिया मैन्युअल, धीमी और छोटी गाड़ी थी।
स्प्रिंट के बाद हमने स्प्रिंट को विफल कर दिया, क्योंकि हमारे पास अगली स्प्रिंट समीक्षा के लिए सुविधाओं को बनाने और बाहर करने का समय नहीं था। हमें अपनी रिलीज़ से नफरत थी। अक्सर वे तीन से चार दिनों तक रहते थे।

इस लेख में, हम स्टॉप द लाइन प्रथा का वर्णन करेंगे, जिसने हमें लेआउट मुद्दों को ठीक करने पर ध्यान केंद्रित करने में मदद की। केवल तीन महीनों में, हम तैनाती दर को 10 गुना बढ़ाने में कामयाब रहे। आज, हमारी तैनाती पूरी तरह से स्वचालित है, और मोनोलिथ की रिहाई में केवल 4-5 घंटे लगते हैं।

लाइन बंद करो। टीम द्वारा आविष्कृत अभ्यास

मुझे याद है कि हम स्टॉप द लाइन के साथ कैसे आए थे। एक सामान्य पूर्वव्यापी में, हमने लंबी रिलीज पर चर्चा की जो हमें स्प्रिंट लक्ष्यों को प्राप्त करने से रोकती है। हमारे डेवलपर्स ने सुझाव दिया:

- [सर्गेई] चलो रिलीज की मात्रा को सीमित करें। यह हमें परीक्षण करने, कीड़े को ठीक करने और तेजी से तैनात करने में मदद करेगा।
- [डिमा] क्या हम प्रगति (डब्ल्यूआईपी सीमा) में काम पर प्रतिबंध लगा सकते हैं? उदाहरण के लिए, जैसे ही हमने 10 कार्य पूरे किए हैं, हम विकास को रोक देते हैं।
- [डेवलपर्स] लेकिन कार्य आकार में भिन्न हो सकते हैं। इससे बड़ी रिलीज़ की समस्या हल नहीं होगी।
- [I] जारी करने की अवधि के आधार पर प्रतिबंध लगाते हैं, और कार्यों की संख्या पर नहीं। यदि रिलीज में बहुत अधिक समय लगता है तो हम विकास रोक देंगे।

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

हमने एक सरल फ्लिप चार्ट पर "स्टॉप द लाइन बोर्ड" भी पेश किया। उस पर, हम ऐसे कार्यों को लिखते हैं जो या तो वर्तमान रिलीज़ को आगे बढ़ाने में मदद करते हैं, या इसके देरी के कारणों से बचने में मदद करते हैं।

बेशक, स्टॉप द लाइन एक आसान निर्णय नहीं है, लेकिन यह अभ्यास निरंतर वितरण और वास्तविक DevOps की दिशा में एक महत्वपूर्ण कदम है।

डोडो आईएस का इतिहास (तकनीकी प्रस्तावना)

डोडो आईएस को मुख्य रूप से .Net फ्रेमवर्क पर यूआई के साथ रिएक्ट / रिडक्स पर लिखा गया है, jQuery पर जगह है और कोणीय के साथ अन्तर्निहित है। अभी भी स्विफ्ट और कोटलीन पर iOS और Android के लिए ऐप मौजूद हैं।

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

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

निरंतर एकीकरण (सीआई) एक अभ्यास है जो डेवलपर्स को लगातार काम के क्रम में कोड बनाए रखने में मदद करता है, छोटे चरणों में उत्पाद को बढ़ाता है, कई ऑटोटेस्ट्स के साथ सीआई बिल्ड के समर्थन के साथ कम से कम एक शाखा में दैनिक एकीकृत करता है।

जब कई टीमें एक ही उत्पाद पर काम करती हैं और CI का अभ्यास करती हैं, तो सामान्य शाखा में परिवर्तन की संख्या तेजी से बढ़ती है। जितना अधिक परिवर्तन आप जमा करते हैं, उतना अधिक इस परिवर्तन में छिपे हुए दोष और संभावित समस्याएं होंगी। यही कारण है कि टीमें अक्सर परिवर्तनों को तैनात करना पसंद करती हैं, जो सीआई के बाद अगले तार्किक कदम के रूप में सतत वितरण (सीडी) के अभ्यास की ओर जाता है।

सीडी अभ्यास आपको किसी भी समय कोड में कोड को तैनात करने की अनुमति देता है। यह अभ्यास एक परिनियोजन पाइपलाइन पर आधारित है - स्वचालित या मैन्युअल चरणों का एक सेट जो किसी उत्पाद के रास्ते में किसी उत्पाद की वृद्धि की जांच करता है।

हमारी तैनाती पाइपलाइन इस तरह दिखती है:

अंजीर। 1. डोडो आईएस की तैनाती पाइपलाइन

आइए जल्दी से जारी करें: समस्या से रूपांतरित लाइन पर रोकें

धीमी रिलीज का दर्द। वे इतने लंबे क्यों हैं? के विश्लेषण

एक्सट्रीम प्रोग्रामिंग (एक्सपी) में एक सुनहरा नियम होता है: यदि कुछ दर्द होता है, तो इसे जितनी बार संभव हो सके। हमारी रिहाई हमेशा एक दर्द रही है। हमने परीक्षण वातावरण को तैनात करने, डेटाबेस को पुनर्स्थापित करने, परीक्षण चलाने (आमतौर पर कई बार), यह पता लगाने के लिए कि वे क्यों गिरे, बग को ठीक किया और आखिरकार, जारी करने के लिए कई दिन बिताए।

स्प्रिंट 2 सप्ताह तक रहता है, और रिलीज तीन दिनों के लिए रोल करता है। शुक्रवार को स्प्रिंट रिव्यू से पहले इसे जारी करने में सक्षम होने के लिए, आपको सोमवार को अच्छे तरीके से रिलीज़ शुरू करना चाहिए। इसका मतलब है कि हम केवल 50% समय के लिए स्प्रिंट करने के लक्ष्य पर काम कर रहे हैं। और अगर हम हर दिन जारी कर सकते हैं, तो काम की उत्पादक अवधि बढ़कर 80-90% हो जाएगी।

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

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

अंजीर। 2. सीएलडी आरेख: लंबे समय तक रिलीज भी लंबे समय तक रिलीज होती है

क्यूए कमांड के साथ प्रतिगमन स्वचालन

कदम जो एक रिलीज बनाते हैं

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

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

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

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

लाइन रोकने के लिए एक कदम। #IreleaseEveryDay पहल

हमने #IReleaseEveryDay जैसी सोच वाले समुदाय का निर्माण किया और विचार किया कि कैसे तैनाती की पाइपलाइन को गति दी जाए। पहली क्रियाएं इस प्रकार थीं:

हमने बार-बार और अनावश्यक परीक्षणों को फेंककर यूआई परीक्षणों के सेट को काफी कम कर दिया। कई मिनटों के परीक्षण के समय में यह कमी आई;
हमने डेटाबेस और डेटा एन्क्रिप्शन की प्रारंभिक वसूली के कारण पर्यावरण को स्थापित करने का समय कम कर दिया। उदाहरण के लिए, अब हम रात में डेटाबेस की एक बैकअप प्रतिलिपि बनाते हैं, और जैसे ही रिलीज़ शुरू होता है, हम कुछ सेकंड में परीक्षण वातावरण को बैकअप डेटाबेस में बदल देते हैं।

उपरोक्त समाधानों के लिए धन्यवाद, हमने औसत रिलीज का समय कम कर दिया, लेकिन यह अभी भी लंबे समय तक नाराज था। यह व्यवस्था परिवर्तन का समय है।

क्या होगा अगर ...

हमने नियम पेश किया कि यदि रिलीज़ 48 घंटे से अधिक समय तक रहता है, तो हम चमकती रोशनी को चालू करते हैं और मोनोलिथ की व्यावसायिक विशेषताओं पर सभी टीमों के काम को रोकते हैं। मोनोलिथ पर काम करने वाली सभी टीमों को विकास को रोकना चाहिए और वर्तमान रिलीज को बिक्री में रोल करने या उन कारणों को खत्म करने पर ध्यान केंद्रित करना चाहिए जिन्होंने रिलीज में देरी की।

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

Entourage फ्लैशर

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

अंजीर। 3. ब्लिंकर लाइन बंद करो

टीम प्रतिरोध और छोटे तोड़फोड़

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

एक स्क्रैम मास्टर के रूप में, मैं नियमों के उल्लंघन के साथ नहीं रख सकता था, इसलिए मैंने एक सामान्य पूर्वव्यापी में इस मुद्दे को उठाया। हमारे बीच कठिन बातचीत हुई। अधिकांश टीमों ने सहमति व्यक्त की कि नियम सभी पर लागू होते हैं। हम सहमत थे कि प्रत्येक टीम को नियमों का पालन करना चाहिए, भले ही वह उनसे सहमत न हो। और उसी समय के बारे में कि आप अगले पूर्वव्यापी की प्रतीक्षा किए बिना नियमों को कैसे बदल सकते हैं।

क्या काम नहीं किया था?

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

कुछ समाधान त्वरित सुधार थे जो समस्याओं को हल करने के बजाय उन्हें छिपाते थे। उदाहरण के लिए, कई परीक्षणों को टाइमआउट बढ़ाकर या रिट्रेज जोड़कर मरम्मत की गई थी। इनमें से एक परीक्षण 21 मिनट तक चला। परीक्षण एक सूचकांक के बिना तालिका में सबसे हाल ही में बनाए गए कर्मचारी के लिए देखा गया। अनुरोध के तर्क को सही करने के बजाय, प्रोग्रामर ने 3 रिट्रीस जोड़े। परिणामस्वरूप, धीमी परीक्षा धीमी हो गई। जब स्टॉप द लाइन एक मालिक टीम के साथ आया, जिसने परीक्षण समस्याओं पर ध्यान केंद्रित किया, तो अगले तीन स्प्रिंटों पर वे 2-3 बार हमारे परीक्षणों को गति देने में कामयाब रहे।

स्टॉप द लाइन का अभ्यास करने के बाद टीमों का व्यवहार कैसा रहा?

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

पहले, टीमें व्यवस्थित रूप से तकनीकी ऋण में संलग्न नहीं थीं। अब हमारे पास तकनीकी सुधार का एक बैकलॉग है जिसका विश्लेषण हम स्टॉप द लाइन के दौरान करते हैं। उदाहरण के लिए, हमने .Net कोर पर परीक्षणों को फिर से लिखा है, जिससे हमें उन्हें डॉकर में चलाने की अनुमति मिली। डॉकर में चल रहे परीक्षणों ने हमें परीक्षणों को समानांतर बनाने और उनके निष्पादन समय को कम करने के लिए सेलेनियम ग्रिड का उपयोग करने की अनुमति दी।

पहले, टीमें परीक्षण के लिए एक क्यूए टीम और तैनाती के लिए एक बुनियादी ढांचे की टीम पर निर्भर थीं। अब खुद को छोड़कर भरोसा करने वाला कोई नहीं है। टीमें खुद उत्पादन में कोड का परीक्षण करती हैं और जारी करती हैं। ये असली हैं, नकली DevOps नहीं।

लाइन ऑफ स्टॉप विधि का विकास

एक सामान्य स्प्रिंट रेट्रोस्पेक्टिव में, हम प्रयोगों की समीक्षा कर रहे हैं। अगले कुछ पूर्वव्यापी दृष्टिकोणों पर, हमने उदाहरण के लिए, स्टॉप टू द लाइन नियम में कई बदलाव किए हैं:

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

नुकसान की लागत

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

• नवंबर - 2 106 000 पी।
• दिसंबर - 503 504 पी।
• जनवरी - 1 219 767 पी।
• फरवरी - 2 002 278 पी।
• मार्च - 0 पी।
• अप्रैल - 0 पी।
• मई - 361 138 पी।

इस तरह की पारदर्शिता स्वस्थ दबाव बनाती है और तैनाती पाइपलाइन की समस्याओं को तुरंत हल करने के लिए टीमों को प्रेरित करती है। इन नंबरों को देखकर, हमारी टीमें समझती हैं कि कुछ भी मुफ्त में नहीं मिलता है, और प्रत्येक स्टॉप द लाइन हमें एक बहुत पैसा मिलता है।

परिणाम

वास्तव में, स्टॉप द लाइन प्रैक्टिस एक आत्म-सुदृढ़ीकरण चक्र (छवि 2) को दो संतुलन चक्र (छवि 4) में परिवर्तित करता है। लाइन बंद करो हमें तैनाती पाइपलाइन को बेहतर बनाने पर ध्यान केंद्रित करने में मदद करता है जब यह बहुत धीमा हो जाता है। केवल 4 स्प्रिंट में, हम:

12 स्थिर रिलीज को गिरा दिया
30% से कम समय का निर्माण
स्थिर UI और API परीक्षण। अब वे सभी वातावरणों और यहां तक कि स्थानीय स्तर पर भी गुजरते हैं।
चमकती परीक्षणों से छुटकारा पाएं
हमारे परीक्षणों पर भरोसा करना शुरू कर दिया।

अंजीर। 4. सीएलडी चार्ट: लाइन बैलेंस रिलीज समय को रोकें

स्क्रैम मास्टर्स से निष्कर्ष

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

निश्चित रूप से, व्यापार से विश्वास और समर्थन की आवश्यकता होती है, जो पूरी पारदर्शिता के साथ ही संभव है। सभी टीम प्रतिनिधियों के साथ एक नियमित, सामान्य पूर्वव्यापी जैसे फीडबैक, नई प्रथाओं का आविष्कार, कार्यान्वयन और संशोधित करने में मदद करता है।

समय के साथ, स्टॉप द लाइन को खुद को मारना चाहिए। जितनी बार हम लाइन को रोकते हैं, जितना अधिक हम तैनाती पाइपलाइन में निवेश करते हैं, उतना ही स्थिर और तेजी से रिलीज हो जाता है, रोकने का कम कारण। अंत में, रेखा कभी भी बंद नहीं होगी, जब तक कि हम सीमा को कम करने का निर्णय नहीं लेते हैं, उदाहरण के लिए, 48 से 24 घंटे तक। लेकिन, इस अभ्यास के लिए धन्यवाद, हमने रिलीज़ प्रक्रिया में बहुत सुधार किया है। टीमों ने न केवल विकास में, बल्कि उत्पादों के मूल्य के त्वरित वितरण में भी अनुभव प्राप्त किया ये वास्तविक DevOps हैं।

आगे क्या है? मुझे नहीं पता शायद हम जल्द ही इस प्रथा को त्याग देंगे। टीमें तय करेंगी। लेकिन यह स्पष्ट है कि हम निरंतर वितरण और DevOps की ओर बढ़ते रहेंगे। एक दिन, एक दिन में कई बार एक मोनोलिथ जारी करने का मेरा सपना सच हो जाएगा।

लाइन बंद करो या अपनी पाइपलाइन को पंप करो, यो