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

DevOps अभ्यासहरू काम गर्छन्। हामी आफैं यो कुरामा विश्वस्त थियौं जब हामीले रिलीज स्थापना समय १० पटक घटायौं। FIS प्रोफाइल प्रणालीमा, जुन हामीले VTB मा प्रयोग गर्छौं, स्थापनाले अब 10 भन्दा 90 मिनेट लिन्छ। रिलीज निर्माण समय दुई हप्ताबाट दुई दिनमा घटेको छ। निरन्तर कार्यान्वयन त्रुटिहरूको संख्या लगभग न्यूनतममा झरेको छ। "व्यक्तिगत श्रम" बाट टाढा हुन र विक्रेतामा निर्भरता हटाउन, हामीले बैसाखीको साथ काम गर्नुपर्‍यो र अप्रत्याशित समाधानहरू खोज्नुपर्‍यो। कट तल हामीले कसरी पूर्ण आन्तरिक विकास निर्माण गर्यौं भन्ने बारे विस्तृत कथा छ।

 

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

गत वर्षमा, हामीले VTB मा DevOps अभ्यासहरूको आन्तरिक विकास र कार्यान्वयनलाई व्यवस्थित गर्न धेरै काम गरेका छौं:

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

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

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

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

यस अवधिमा, आवश्यक आकारको विकास टोलीले सीपहरू विकास गर्नुपर्छ र स्वीकार्य स्तरमा रिलीजहरूमा आफ्नो योगदानको अंश बढाउनु पर्छ। र यो हो, हामी कार्य पूरा भएको विचार गर्न सक्छौं।

यस्तो देखिन्छ कि यो आवश्यक परिणामको लागि पूर्ण रूपमा ऊर्जा-कुशल मार्ग हो: यहाँ DevOps छ, यहाँ टोलीको प्रदर्शन मेट्रिक्स छन्, यहाँ संचित विशेषज्ञता छ... तर व्यवहारमा, हामीले अर्को पुष्टि प्राप्त गर्‍यौं कि DevOps अझै पनि दर्शनको बारेमा छ। , र "गिटल्याब प्रक्रियामा संलग्न, उत्तरदायी, नेक्सस र सूची तल थपिएको छैन।"

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

आन्तरिक विकास कहाँबाट सुरु हुन्छ? 

यो काम गर्न सबैभन्दा अनुकूल प्रणाली थिएन। वास्तुगत रूपमा, यो एक ठूलो गैर-सम्बन्धित DBMS थियो, धेरै अलग-अलग कार्यान्वयनयोग्य वस्तुहरू (लिपि, प्रक्रियाहरू, ब्याचहरू, आदि) समावेश थिए, जसलाई आवश्यकता अनुसार बोलाइयो, र ब्ल्याक बक्सको सिद्धान्तमा काम गर्‍यो: यसले अनुरोध र मुद्दाहरू प्राप्त गर्दछ। एक प्रतिक्रिया। ध्यान दिनुपर्ने अन्य कठिनाइहरू समावेश छन्:

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

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

• कागजात र कोड उत्पादन को आधारभूत अध्ययन;
• हामीले विक्रेताबाट प्राप्त विकासमा छोटो पाठ्यक्रम अध्ययन गर्यौं;
• प्रारम्भिक विकास कौशलमा महारत हासिल;
• हामीले नयाँ टोलीका सदस्यहरूका लागि प्रशिक्षण पुस्तिका कम्पाइल गरेका छौं;
• हामी टोलीलाई "लडाई" मोडमा समावेश गर्न सहमत भयौं;
• कोड गुणस्तर नियन्त्रण संग समस्या समाधान;
• हामीले विकासको लागि एक अडान राख्यौं।

हामीले विशेषज्ञता विकास गर्न र प्रणालीमा आफूलाई डुबाउन तीन महिना बितायौं, र 2019 को सुरुदेखि, इनहाउस विकासले कहिलेकाहीँ कठिनाइका साथ, तर आत्मविश्वास र उद्देश्यपूर्ण रूपमा उज्ज्वल भविष्यतर्फ आफ्नो आन्दोलन सुरु गर्‍यौं।

भण्डार माइग्रेसन र स्वत: परीक्षणहरू

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

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

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

यो कस्तो थियो: स्वचालन अघि मोडेल

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

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

वितरण भित्रका वस्तुहरू एकअर्कासँग ओभरल्याप भएका छन्, विशेष गरी कार्यान्वयनयोग्य कोडमा, जुन आधाभन्दा कम अद्वितीय थियो। त्यहाँ पहिले नै स्थापित कोड र जसको स्थापना भर्खर योजना गरिएको थियो दुवै मा धेरै निर्भरताहरू थिए। 

कोडको आवश्यक संस्करण प्राप्त गर्न, स्थापना आदेशलाई कडाईका साथ पालना गर्न आवश्यक थियो, जुन समयमा वस्तुहरू भौतिक रूपमा धेरै पटक पुन: लेखिएको थियो, केहि 10-12 पटक।

प्याकेजहरूको ब्याच स्थापना गरेपछि, मैले सेटिङहरू प्रारम्भ गर्न निर्देशनहरू म्यानुअल रूपमा पालना गर्नुपर्‍यो। विज्ञप्ति विक्रेता द्वारा भेला र स्थापना गरिएको थियो। रिलीजको संरचना लगभग कार्यान्वयनको क्षण भन्दा पहिले स्पष्ट गरिएको थियो, जसमा "decoupling" प्याकेजहरू सिर्जना गरिएको थियो। नतिजाको रूपमा, आपूर्तिको एक महत्त्वपूर्ण भाग "decouplings" को आफ्नै पुच्छरको साथ रिलीजबाट रिलीजमा सारियो।

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

यस दृष्टिकोणको तार्किक नतिजा वस्तुहरूको कुटिल संस्करणहरू, अनावश्यक कोड, छुटेका निर्देशनहरू र वस्तुहरूको बेहिसाब पारस्परिक प्रभावहरूको रूपमा अनिवार्य स्थापना त्रुटिहरू थिए, जुन रिलीज पछि ज्वरोले हटाइएको थियो। 

पहिलो अपडेटहरू: कमिट असेंबली र डेलिभरी

यस मार्गमा पाइप मार्फत कोड प्रसारण गरेर स्वचालन सुरु भयो:

• भण्डारणबाट समाप्त डेलिभरी उठाउनुहोस्;
• यसलाई समर्पित वातावरणमा स्थापना गर्नुहोस्;
• स्वचालित परीक्षणहरू चलाउनुहोस्;
• स्थापना परिणाम मूल्याङ्कन;
• परीक्षण आदेशको छेउमा निम्न पाइपलाइनलाई कल गर्नुहोस्।

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

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

यस पछि, त्यहाँ पहिले नै अवस्थित चरणहरू थिए कोड जाँच गर्न र स्थानान्तरण गर्न, पाइप सुरु गर्न र हाम्रो छेउमा भेला गर्न।

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

अन्तिम समाधान: संचयी स्थापना प्याकेजहरू 

हामीले राम्रोसँग बुझ्यौं कि विक्रेताका निर्देशनहरू स्क्रिप्टिङ एकदमै स्वचालन थियो; हामीले प्रक्रिया आफैंमा पुनर्विचार गर्नुपर्‍यो। समाधान स्पष्ट थियो - आवश्यक संस्करणहरूको सबै वस्तुहरूको साथ रिलीज शाखाबाट संचयी आपूर्ति सङ्कलन गर्न।

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

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

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

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

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

पहिलो पटक, छिटो र त्रुटि बिना

हामीले आशावादी मनोवृत्ति र विभिन्न सर्किटहरूमा एक दर्जन भन्दा बढी सफल स्थापनाहरूका साथ रिलीजमा पुग्यौं। तर शाब्दिक रूपमा अन्तिम म्यादको एक दिन अघि, यो पत्ता लाग्यो कि विक्रेताले स्वीकृत तरिकामा स्थापनाको लागि रिलीज तयार गर्न काम पूरा गरेको छैन। यदि कुनै कारणले हाम्रो निर्माणले काम गर्दैन भने, रिलीज अवरुद्ध हुनेछ। यसबाहेक, हाम्रो प्रयासहरू मार्फत, जुन विशेष गरी अप्रिय छ। हामीसँग पछि हट्ने बाटो थिएन । त्यसकारण, हामीले वैकल्पिक विकल्पहरू मार्फत सोच्यौं, कार्य योजनाहरू तयार गर्‍यौं र स्थापना सुरु गर्‍यौं।

अचम्मको कुरा, 800 भन्दा बढी वस्तुहरू समावेश भएको सम्पूर्ण रिलीज, पहिलो पटक र केवल 10 मिनेटमा सही रूपमा सुरु भयो। हामीले त्रुटिहरू खोज्दै लगहरू जाँच गर्न एक घण्टा बितायौं, तर कुनै फेला पारेनौं।

पूरै भोलिपल्ट रिलिज च्याटमा मौनता थियो: कुनै कार्यान्वयन समस्याहरू, कुटिल संस्करणहरू वा "अनुपयुक्त" कोड। यो कुनै न कुनै रूपमा अप्ठ्यारो पनि थियो। पछि, केही टिप्पणीहरू देखा परे, तर अन्य प्रणालीहरू र अघिल्लो अनुभवको तुलनामा, तिनीहरूको संख्या र प्राथमिकता उल्लेखनीय रूपमा कम थियो।

संचयी प्रभावबाट थप प्रभाव विधानसभा र परीक्षणको गुणस्तरमा वृद्धि थियो। पूर्ण रिलीजको बहु स्थापनाहरूको कारण, निर्माण त्रुटिहरू र डिप्लोइमेन्ट त्रुटिहरू समयमै पहिचान गरियो। पूर्ण रिलीज कन्फिगरेसनहरूमा परीक्षणले थप रूपमा वस्तुहरूको पारस्परिक प्रभावमा दोषहरू पहिचान गर्न सम्भव बनायो जुन वृद्धिशील स्थापनाहरूमा देखा पर्दैन। यो पक्कै पनि एक सफलता थियो, विशेष गरी रिलीज मा हाम्रो 57% योगदान दिए।

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

एक वर्ष भन्दा कम समयमा हामीले व्यवस्थापन गर्यौं:

• एक विदेशी प्रणाली प्रयोग गरी पूर्ण आन्तरिक विकास निर्माण गर्नुहोस्;
• महत्वपूर्ण विक्रेता निर्भरता हटाउनुहोस्;
• धेरै मित्रवत विरासतको लागि CI/CD सुरुवात गर्नुहोस्;
• नयाँ प्राविधिक स्तरमा कार्यान्वयन प्रक्रियाहरू बढाउनुहोस्;
• उल्लेखनीय रूपमा तैनाती समय घटाउनुहोस्;
• उल्लेखनीय रूपमा कार्यान्वयन त्रुटिहरूको संख्या घटाउनुहोस्;
• आत्मविश्वासका साथ आफैलाई एक अग्रणी विकास विशेषज्ञको रूपमा घोषणा गर्नुहोस्।

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

स्रोत: www.habr.com