DevOps - VTB अनुभव का उपयोग करके पूर्ण विकसित इनहाउस विकास कैसे करें

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

 

प्रस्तावना: DevOps एक दर्शन है

पिछले वर्ष में, हमने वीटीबी में DevOps प्रथाओं के आंतरिक विकास और कार्यान्वयन को व्यवस्थित करने के लिए बहुत काम किया है:

• हमने 12 प्रणालियों के लिए आंतरिक विकास प्रक्रियाएं बनाईं;
• हमने 15 पाइपलाइनें लॉन्च कीं, जिनमें से चार को उत्पादन में लाया गया;
• स्वचालित 1445 परीक्षण परिदृश्य;
• हमने इन-हाउस टीमों द्वारा तैयार की गई कई रिलीज़ों को सफलतापूर्वक कार्यान्वित किया।

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

सबसे पहले, कार्यान्वयन एल्गोरिदम सरल और स्पष्ट लग रहा था:

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

इस समय के दौरान, आवश्यक आकार की विकास टीम को कौशल विकसित करना होगा और रिलीज में अपने योगदान की हिस्सेदारी को स्वीकार्य स्तर तक बढ़ाना होगा। और बस इतना ही, हम कार्य को पूरा मान सकते हैं।

ऐसा प्रतीत होता है कि यह आवश्यक परिणाम के लिए पूरी तरह से ऊर्जा-कुशल मार्ग है: यहां DevOps है, यहां टीम के प्रदर्शन मेट्रिक्स हैं, यहां संचित विशेषज्ञता है... लेकिन व्यवहार में, हमें एक और पुष्टि मिली कि DevOps अभी भी दर्शन के बारे में है , और "गीटलैब प्रक्रिया से जुड़ा हुआ, अन्सिबल, नेक्सस और सूची में और नीचे नहीं।"

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

आंतरिक विकास कहाँ से शुरू होता है? 

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

• विदेशी भाषा (MUMPS);
• कंसोल इंटरफ़ेस;
• लोकप्रिय स्वचालन उपकरण और ढाँचे के साथ एकीकरण का अभाव;
• दसियों टेराबाइट्स में डेटा की मात्रा;
• प्रति घंटे 2 मिलियन से अधिक परिचालन का भार;
• महत्व - व्यवसाय-महत्वपूर्ण।

वहीं, हमारी तरफ कोई सोर्स कोड रिपॉजिटरी नहीं थी। बिल्कुल भी। दस्तावेज़ीकरण था, लेकिन सभी प्रमुख ज्ञान और योग्यताएँ एक बाहरी संगठन के पक्ष में थीं।
हमने इसकी विशेषताओं और कम वितरण को ध्यान में रखते हुए, सिस्टम के विकास में लगभग शुरुआत से ही महारत हासिल करना शुरू कर दिया। अक्टूबर 2018 में शुरू हुआ:

• कोड जनरेशन के दस्तावेज़ीकरण और बुनियादी बातों का अध्ययन किया;
• हमने विक्रेता से प्राप्त विकास पर लघु पाठ्यक्रम का अध्ययन किया;
• प्रारंभिक विकास कौशल में महारत हासिल;
• हमने टीम के नए सदस्यों के लिए एक प्रशिक्षण मैनुअल तैयार किया;
• हम टीम को "युद्ध" मोड में शामिल करने पर सहमत हुए;
• कोड गुणवत्ता नियंत्रण के साथ समस्या का समाधान किया गया;
• हमने विकास के लिए एक स्टैंड का आयोजन किया।

हमने विशेषज्ञता विकसित करने और सिस्टम में खुद को डुबोने में तीन महीने बिताए, और 2019 की शुरुआत से, आंतरिक विकास ने उज्ज्वल भविष्य की ओर अपना आंदोलन शुरू किया, कभी-कभी कठिनाई के साथ, लेकिन आत्मविश्वास और उद्देश्यपूर्ण ढंग से।

रिपॉजिटरी माइग्रेशन और ऑटोटेस्ट

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

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

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

यह कैसा था: स्वचालन से पहले का मॉडल

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

असेंबली व्यक्तिगत डिलीवरी के स्तर पर की गई, जो स्वतंत्र वस्तुएं थीं। कोई भी परिवर्तन एक नई डिलीवरी है। अन्य बातों के अलावा, मुख्य रिलीज़ संरचना के 60-70 पैकेजों में 10-15 तकनीकी संस्करण जोड़े गए - रिलीज़ से कुछ जोड़ने या बाहर करने पर प्राप्त संस्करण और रिलीज़ के बाहर बिक्री में परिवर्तन को दर्शाते हुए।

डिलीवरी के भीतर ऑब्जेक्ट एक-दूसरे के साथ ओवरलैप हो गए, खासकर निष्पादन योग्य कोड में, जो आधे से भी कम अद्वितीय था। पहले से स्थापित कोड और जिसकी स्थापना की अभी योजना बनाई गई थी, दोनों पर कई निर्भरताएँ थीं। 

कोड का आवश्यक संस्करण प्राप्त करने के लिए, इंस्टॉलेशन आदेश का सख्ती से पालन करना आवश्यक था, जिसके दौरान वस्तुओं को भौतिक रूप से कई बार, कुछ 10-12 बार, फिर से लिखा गया था।

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

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

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

पहला अपडेट: असेंबली और डिलीवरी के लिए प्रतिबद्ध

इस मार्ग पर एक पाइप के माध्यम से कोड संचारित करके स्वचालन शुरू हुआ:

• भंडारण से तैयार डिलीवरी उठाएँ;
• इसे एक समर्पित वातावरण पर स्थापित करें;
• ऑटोटेस्ट चलाएँ;
• स्थापना परिणाम का मूल्यांकन करें;
• परीक्षण आदेश के पक्ष में निम्नलिखित पाइपलाइन को कॉल करें।

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

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

इसके बाद, कोड की जांच करने और ट्रांसफर करने, पाइप लॉन्च करने और हमारी तरफ असेंबल करने के चरण पहले से ही मौजूद थे।

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

अंतिम समाधान: संचयी स्थापना पैकेज़ 

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

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

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

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

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

एक अतिरिक्त चुनौती बड़ी संख्या में गैर-रिलीज़ थी जिसे ध्यान में रखना पड़ा। लेकिन उत्पाद जैसी शाखा और रिबेस के साथ, कार्य पारदर्शी हो गया।

पहली बार, शीघ्रता से और त्रुटियों के बिना

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

हैरानी की बात यह है कि 800 से अधिक ऑब्जेक्ट वाली पूरी रिलीज़ पहली बार सही ढंग से और केवल 10 मिनट में शुरू हुई। हमने त्रुटियों की तलाश में लॉग की जांच करने में एक घंटा बिताया, लेकिन कोई त्रुटि नहीं मिली।

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

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

परिणाम और निष्कर्ष

एक वर्ष से भी कम समय में हम इसमें सफल रहे:

• एक विदेशी प्रणाली का उपयोग करके पूर्ण आंतरिक विकास का निर्माण करें;
• महत्वपूर्ण विक्रेता निर्भरता को समाप्त करें;
• एक बहुत ही अमित्र विरासत के लिए सीआई/सीडी लॉन्च करें;
• कार्यान्वयन प्रक्रियाओं को एक नए तकनीकी स्तर तक बढ़ाएं;
• तैनाती के समय को महत्वपूर्ण रूप से कम करें;
• कार्यान्वयन त्रुटियों की संख्या में उल्लेखनीय रूप से कमी;
• आत्मविश्वास से अपने आप को एक अग्रणी विकास विशेषज्ञ घोषित करें।

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

स्रोत: www.habr.com