DevOps - VTB अनुभव वापरून संपूर्ण इनहाऊस विकास कसा तयार करायचा

DevOps सराव कार्य करतात. जेव्हा आम्ही प्रकाशन स्थापनेची वेळ 10 पट कमी केली तेव्हा आम्हाला याची खात्री पटली. FIS प्रोफाइल सिस्टीममध्ये, जी आम्ही VTB वर वापरतो, इंस्टॉलेशनला आता 90 ऐवजी 10 मिनिटे लागतात. रिलीझ बिल्ड टाइम दोन आठवड्यांवरून दोन दिवसांपर्यंत कमी झाला आहे. सातत्यपूर्ण अंमलबजावणीतील दोषांची संख्या जवळजवळ कमीतकमी कमी झाली आहे. "व्यक्ती श्रम" पासून दूर जाण्यासाठी आणि विक्रेत्यावरील अवलंबित्व दूर करण्यासाठी, आम्हाला क्रॅचसह काम करावे लागले आणि अनपेक्षित उपाय शोधावे लागले. कट खाली आम्ही एक पूर्ण वाढ झालेला अंतर्गत विकास कसा तयार केला याबद्दल तपशीलवार कथा आहे.

 

प्रस्तावना: DevOps हे एक तत्वज्ञान आहे

गेल्या वर्षभरात, आम्ही VTB वर DevOps पद्धतींचा अंतर्गत विकास आणि अंमलबजावणी आयोजित करण्यासाठी बरेच काम केले आहे:

• आम्ही 12 प्रणालींसाठी अंतर्गत विकास प्रक्रिया तयार केल्या आहेत;
• आम्ही 15 पाइपलाइन सुरू केल्या, त्यापैकी चार उत्पादनासाठी आणल्या गेल्या;
• स्वयंचलित 1445 चाचणी परिस्थिती;
• आम्ही इन-हाऊस संघांनी तयार केलेल्या अनेक प्रकाशनांची यशस्वीपणे अंमलबजावणी केली.

इनहाऊस डेव्हलपमेंट आणि DevSecOps पद्धतींची अंमलबजावणी आयोजित करणे सर्वात कठीण म्हणजे FIS प्रोफाइल सिस्टीम - नॉन-रिलेशनल DBMS वर किरकोळ उत्पादन प्रोसेसर. तरीही, आम्ही विकास तयार करण्यात, पाइपलाइन लाँच करण्यात, उत्पादनावर वैयक्तिक नॉन-रिलीझ पॅकेजेस स्थापित करण्यात आणि रिलीझ कसे एकत्र करायचे हे शिकू शकलो. कार्य सोपे नव्हते, परंतु मनोरंजक आणि अंमलबजावणीमध्ये स्पष्ट निर्बंध नसलेले: ही प्रणाली आहे - आपल्याला घरातील विकास तयार करणे आवश्यक आहे. उत्पादक वातावरणापूर्वी सीडी वापरणे ही एकमेव अट आहे.

सुरुवातीला, अंमलबजावणी अल्गोरिदम सोपे आणि स्पष्ट दिसत होते:

• आम्ही प्रारंभिक विकास कौशल्य विकसित करतो आणि कोड टीमकडून स्थूल दोषांशिवाय स्वीकारार्ह दर्जा प्राप्त करतो;
• आम्ही शक्य तितक्या विद्यमान प्रक्रियांमध्ये समाकलित करतो;
• स्पष्ट टप्प्यांमधील कोड हस्तांतरित करण्यासाठी, आम्ही पाइपलाइन कापतो आणि त्याचे एक टोक पुढे ढकलतो.

या काळात, आवश्यक आकाराच्या विकास कार्यसंघाने कौशल्ये विकसित केली पाहिजेत आणि रीलिझमध्ये त्याच्या योगदानाचा वाटा स्वीकार्य पातळीवर वाढवला पाहिजे. आणि तेच आहे, आम्ही पूर्ण केलेल्या कार्याचा विचार करू शकतो.

असे दिसते की आवश्यक परिणामासाठी हा पूर्णपणे ऊर्जा-कार्यक्षम मार्ग आहे: येथे DevOps आहे, येथे संघाचे कार्यप्रदर्शन मेट्रिक्स आहेत, येथे संचित कौशल्य आहे... परंतु व्यवहारात, आम्हाला आणखी एक पुष्टी मिळाली की DevOps अजूनही तत्त्वज्ञानाविषयी आहे , आणि "गिटलॅब प्रक्रियेशी संलग्न केलेले नाही, उत्तरदायी, नेक्सस आणि सूचीच्या खाली."

कृती आराखड्याचे पुन्हा एकदा विश्लेषण केल्यावर, आमच्या लक्षात आले की आम्ही स्वतःमध्ये एक प्रकारचा आउटसोर्सिंग विक्रेता तयार करत आहोत. म्हणून, वर वर्णन केलेल्या अल्गोरिदममध्ये प्रक्रिया पुनर्अभियांत्रिकी जोडण्यात आली, तसेच या प्रक्रियेत अग्रगण्य भूमिका प्राप्त करण्यासाठी संपूर्ण विकास मार्गावर कौशल्याचा विकास केला गेला. सर्वात सोपा पर्याय नाही, परंतु हा वैचारिकदृष्ट्या योग्य विकासाचा मार्ग आहे.
 

घरातील विकास कोठे सुरू होतो? 

काम करण्यासाठी ही सर्वात अनुकूल प्रणाली नव्हती. आर्किटेक्चरलदृष्ट्या, हे एक मोठे नॉन-रिलेशनल डीबीएमएस होते, ज्यामध्ये अनेक स्वतंत्र एक्झिक्यूटेबल ऑब्जेक्ट्स (स्क्रिप्ट, प्रक्रिया, बॅचेस इ.) असतात, ज्यांना आवश्यकतेनुसार कॉल केले जाते आणि ब्लॅक बॉक्सच्या तत्त्वावर कार्य केले जाते: त्यास विनंती आणि समस्या प्राप्त होतात. प्रतिसाद. लक्षात घेण्यासारख्या इतर अडचणींमध्ये हे समाविष्ट आहे:

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

त्याच वेळी, आमच्या बाजूला कोणतेही स्त्रोत कोड भांडार नव्हते. अजिबात. दस्तऐवजीकरण होते, परंतु सर्व मुख्य ज्ञान आणि क्षमता बाह्य संस्थेच्या बाजूने होत्या.
आम्ही प्रणालीची वैशिष्ट्ये आणि कमी वितरण लक्षात घेऊन जवळजवळ सुरवातीपासूनच सिस्टमच्या विकासावर प्रभुत्व मिळवण्यास सुरुवात केली. ऑक्टोबर 2018 मध्ये सुरू झाले:

• दस्तऐवजीकरण आणि कोड निर्मितीच्या मूलभूत गोष्टींचा अभ्यास केला;
• आम्ही विक्रेत्याकडून मिळालेल्या विकासावरील शॉर्ट कोर्सचा अभ्यास केला;
• प्राविण्य प्राप्त प्रारंभिक विकास कौशल्ये;
• आम्ही नवीन कार्यसंघ सदस्यांसाठी प्रशिक्षण पुस्तिका संकलित केली;
• आम्ही संघाला "लढाऊ" मोडमध्ये समाविष्ट करण्यास सहमती दिली;
• कोड गुणवत्ता नियंत्रणासह समस्येचे निराकरण केले;
• आम्ही विकासासाठी भूमिका मांडली.

आम्ही तीन महिने कौशल्य विकसित करण्यात आणि स्वतःला प्रणालीमध्ये बुडवण्यात घालवले आणि 2019 च्या सुरुवातीपासून, इनहाऊस डेव्हलपमेंटने उज्ज्वल भविष्याकडे वाटचाल सुरू केली, काहीवेळा अडचणीसह, परंतु आत्मविश्वासाने आणि उद्देशाने.

रेपॉजिटरी स्थलांतर आणि ऑटोटेस्ट्स

पहिले DevOps कार्य भांडार आहे. आम्ही त्वरीत प्रवेश देण्यावर सहमत झालो, परंतु सध्याच्या SVN मधून एका ट्रंक शाखेसह आमच्या लक्ष्य Git वर अनेक शाखांच्या मॉडेलमध्ये संक्रमण आणि Git Flow च्या विकासासह स्थलांतर करणे आवश्यक होते. आमच्याकडे त्यांच्या स्वतःच्या पायाभूत सुविधांसह 2 संघ आहेत, तसेच परदेशात विक्रेत्याच्या संघाचा भाग आहे. मला दोन गिट्ससह जगायचे होते आणि सिंक्रोनाइझेशन सुनिश्चित करायचे होते. अशा परिस्थितीत हे दोन वाईट गोष्टींपेक्षा कमी होते.

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

ऑटोटेस्ट्सची समस्या आश्चर्यकारकपणे सहजपणे सोडवली गेली - आम्हाला एक तयार फ्रेमवर्क प्रदान करण्यात आला. सिस्टमची वैशिष्ठ्ये लक्षात घेऊन, स्वतंत्र ऑपरेशन कॉल करणे हा व्यवसाय प्रक्रियेचा एक समजण्यासारखा भाग होता आणि त्याच वेळी युनिट चाचणी म्हणून काम केले. फक्त चाचणी डेटा तयार करणे आणि स्क्रिप्ट कॉल करण्याचा आणि निकालांचे मूल्यांकन करण्याचा इच्छित क्रम सेट करणे बाकी होते. ऑपरेशनच्या आकडेवारीच्या आधारे तयार केलेल्या परिस्थितींची यादी, प्रक्रियेची गंभीरता आणि विद्यमान प्रतिगमन पद्धती, भरल्या गेल्यावर, स्वयंचलित चाचण्या दिसू लागल्या. आता आम्ही पाइपलाइन बांधण्यास सुरुवात करू शकतो.

ते कसे होते: ऑटोमेशनपूर्वीचे मॉडेल

अंमलबजावणी प्रक्रियेचे विद्यमान मॉडेल ही एक वेगळी कथा आहे. प्रत्येक बदल स्वहस्ते एक वेगळे वाढीव प्रतिष्ठापन पॅकेज म्हणून हस्तांतरित केले गेले. पुढे जिरा मध्ये मॅन्युअल नोंदणी आणि वातावरणात मॅन्युअल स्थापना आली. वैयक्तिक पॅकेजेससाठी, सर्वकाही स्पष्ट दिसत होते, परंतु प्रकाशनाच्या तयारीसह, गोष्टी अधिक क्लिष्ट होत्या.

असेंब्ली वैयक्तिक वितरणाच्या पातळीवर केली गेली, जी स्वतंत्र वस्तू होती. कोणताही बदल नवीन वितरण आहे. इतर गोष्टींबरोबरच, मुख्य प्रकाशन रचनेच्या 60-70 पॅकेजेसमध्ये 10-15 तांत्रिक आवृत्त्या जोडल्या गेल्या - रिलीझमधून काहीतरी जोडताना किंवा वगळताना आणि रिलीझच्या बाहेरील विक्रीतील बदल प्रतिबिंबित करताना प्राप्त झालेल्या आवृत्त्या.

डिलिव्हरीमधील ऑब्जेक्ट्स एकमेकांशी ओव्हरलॅप होतात, विशेषत: एक्झिक्युटेबल कोडमध्ये, जे अर्ध्यापेक्षा कमी अद्वितीय होते. आधीपासून स्थापित केलेल्या कोडवर आणि ज्याची स्थापना नुकतीच नियोजित केली गेली होती त्या दोन्हीवर अनेक अवलंबन होते. 

कोडची आवश्यक आवृत्ती प्राप्त करण्यासाठी, इंस्टॉलेशन ऑर्डरचे काटेकोरपणे पालन करणे आवश्यक होते, ज्या दरम्यान ऑब्जेक्ट्स भौतिकरित्या अनेक वेळा, काही 10-12 वेळा पुन्हा लिहिल्या गेल्या.

पॅकेजेसचा बॅच स्थापित केल्यानंतर, सेटिंग्ज सुरू करण्यासाठी मला व्यक्तिचलितपणे सूचनांचे पालन करावे लागले. रिलीझ विक्रेत्याने एकत्र केले आणि स्थापित केले. अंमलबजावणीच्या क्षणापूर्वी रिलीजची रचना स्पष्ट केली गेली होती, ज्यामध्ये "डीकपलिंग" पॅकेजेस तयार करणे समाविष्ट होते. परिणामी, पुरवठ्याचा एक महत्त्वाचा भाग "डीकपलिंग्ज" च्या स्वतःच्या शेपटीने रिलीझपासून रिलीझकडे हलविला गेला.

आता हे स्पष्ट झाले आहे की या दृष्टिकोनासह - पॅकेज स्तरावर रिलीझ कोडे एकत्र करणे - एकल मास्टर शाखेचा कोणताही व्यावहारिक अर्थ नव्हता. उत्पादनाच्या स्थापनेसाठी दीड ते दोन तास शारीरिक श्रम लागले. हे चांगले आहे की कमीत कमी इंस्टॉलर स्तरावर ऑब्जेक्ट प्रोसेसिंगचा क्रम निर्दिष्ट केला होता: फील्ड आणि स्ट्रक्चर्स त्यांच्यासाठी डेटा आणि प्रक्रियांपूर्वी प्रविष्ट केल्या होत्या. तथापि, हे केवळ एका स्वतंत्र पॅकेजमध्ये कार्य करते.

या दृष्टिकोनाचा तार्किक परिणाम म्हणजे ऑब्जेक्ट्सच्या कुटिल आवृत्त्या, अनावश्यक कोड, गहाळ सूचना आणि ऑब्जेक्ट्सच्या परस्पर प्रभावांसाठी बेहिशेबी स्थापना दोष, जे प्रकाशनानंतर तापाने काढून टाकले गेले. 

प्रथम अद्यतने: असेंब्ली आणि वितरण

या मार्गावर पाईपद्वारे कोड प्रसारित करून ऑटोमेशन सुरू झाले:

• स्टोरेजमधून तयार झालेले वितरण घ्या;
• एका समर्पित वातावरणात ते स्थापित करा;
• ऑटोटेस्ट्स चालवा;
• स्थापनेच्या परिणामाचे मूल्यांकन करा;
• चाचणी कमांडच्या बाजूला खालील पाइपलाइनवर कॉल करा.

पुढील पाइपलाइनने जिरामध्ये कार्याची नोंदणी केली पाहिजे आणि निवडलेल्या चाचणी लूपवर कमांड वितरित होण्याची प्रतीक्षा करावी, जे कार्य अंमलबजावणीच्या वेळेवर अवलंबून असते. ट्रिगर - दिलेल्या पत्त्यावर वितरणासाठी तत्परतेबद्दल एक पत्र. हे, अर्थातच, एक स्पष्ट क्रॅच होते, परंतु मला कुठेतरी सुरुवात करायची होती. मे 2019 मध्ये, आमच्या वातावरणाच्या तपासणीसह कोडचे हस्तांतरण सुरू झाले. प्रक्रिया सुरू झाली आहे, फक्त ते सभ्य आकारात आणणे बाकी आहे:

• प्रत्येक बदल एका वेगळ्या शाखेत केला जातो, जो इंस्टॉलेशन पॅकेजशी संबंधित असतो आणि लक्ष्य मास्टर शाखेत विलीन होतो;
• पाइपलाइन लाँच ट्रिगर हे विलीनीकरण विनंतीद्वारे मास्टर ब्रँचमध्ये नवीन कमिटचे स्वरूप आहे, जे इनहाऊस टीममधील देखभालकर्त्यांनी बंद केले आहे;
• रेपॉजिटरीज दर पाच मिनिटांनी एकदा सिंक्रोनाइझ केले जातात;
• इन्स्टॉलेशन पॅकेजची असेंब्ली सुरू केली आहे - विक्रेत्याकडून मिळालेल्या असेंबलरचा वापर करून.

यानंतर, कोड तपासण्यासाठी आणि हस्तांतरित करण्यासाठी, पाईप लाँच करण्यासाठी आणि आमच्या बाजूला एकत्र करण्यासाठी आधीपासूनच विद्यमान पायऱ्या होत्या.

हा पर्याय जुलैमध्ये सुरू करण्यात आला होता. संक्रमणाच्या अडचणींमुळे विक्रेता आणि आघाडीच्या ओळीत काही असंतोष निर्माण झाला, परंतु पुढच्या महिन्यात आम्ही सर्व खडबडीत कडा काढून टाकण्यात आणि संघांमध्ये एक प्रक्रिया स्थापित करण्यात व्यवस्थापित केले. आमच्याकडे आता कमिट आणि डिलिव्हरीद्वारे असेंब्ली आहे.
ऑगस्टमध्ये, आम्ही आमच्या पाइपलाइनचा वापर करून उत्पादनावर वेगळ्या पॅकेजची पहिली स्थापना पूर्ण करण्यात व्यवस्थापित केले आणि सप्टेंबरपासून, अपवाद न करता, वैयक्तिक नॉन-रिलीझ पॅकेजेसची सर्व स्थापना आमच्या सीडी टूलद्वारे केली गेली. याव्यतिरिक्त, आम्ही विक्रेत्यापेक्षा लहान संघासह 40% रिलीझ कंपोझिशनमध्ये इनहाऊस टास्कचा वाटा साध्य करण्यात व्यवस्थापित केले - हे निश्चित यश आहे. सर्वात गंभीर कार्य राहिले - रिलीझ एकत्र करणे आणि स्थापित करणे.

अंतिम उपाय: संचयी स्थापना पॅकेजेस 

विक्रेत्याच्या सूचनांचे स्क्रिप्टिंग करणे हे तसे ऑटोमेशन होते हे आम्हाला चांगले समजले; आम्हाला प्रक्रियेचाच पुनर्विचार करावा लागला. समाधान स्पष्ट होते - आवश्यक आवृत्त्यांच्या सर्व वस्तूंसह प्रकाशन शाखेतून एकत्रित पुरवठा गोळा करणे.

आम्ही संकल्पनेच्या पुराव्यासह सुरुवात केली: आम्ही मागील अंमलबजावणीच्या सामग्रीनुसार प्रकाशन पॅकेज हाताने एकत्र केले आणि ते आमच्या वातावरणात स्थापित केले. सर्व काही कार्य केले, संकल्पना व्यवहार्य असल्याचे दिसून आले. पुढे, आम्ही इनिशिएलायझेशन सेटिंग्ज स्क्रिप्ट करण्याच्या आणि कमिटमध्ये समाविष्ट करण्याच्या समस्येचे निराकरण केले. आम्ही एक नवीन पॅकेज तयार केले आणि समोच्च अद्यतनाचा भाग म्हणून चाचणी वातावरणात त्याची चाचणी केली. अंमलबजावणी कार्यसंघाच्या विस्तृत टिप्पण्यांसह, स्थापना यशस्वी झाली. पण मुख्य गोष्ट अशी आहे की आम्हाला आमच्या असेंब्लीसह नोव्हेंबरच्या रिलीजमध्ये प्रोडक्शनमध्ये जाण्याची परवानगी देण्यात आली होती.

फक्त एक महिना शिल्लक असताना, हाताने निवडलेल्या पुरवठा स्पष्टपणे सूचित करतात की वेळ संपत आहे. त्यांनी विमोचन शाखेतून बांधणी करण्याचे ठरवले, पण ते वेगळे का करायचे? आमच्याकडे उत्पादनासारखे उत्पादन नाही आणि विद्यमान शाखा चांगल्या नाहीत - तेथे बरेच अनावश्यक कोड आहेत. आम्‍हाला तातडीनं प्रोड-लाइक्स कमी करण्‍याची आवश्‍यकता आहे आणि हे तीन हजारांहून अधिक कमिट आहे. हाताने एकत्र करणे हा अजिबात पर्याय नाही. आम्ही एक स्क्रिप्ट स्केच केली आहे जी उत्पादन प्रतिष्ठापन लॉगद्वारे चालते आणि शाखेत कमिट गोळा करते. तिसऱ्या वेळी ते योग्यरित्या कार्य केले, आणि "फाइलसह समाप्त केल्यानंतर" शाखा तयार झाली. 

आम्ही आमच्या स्वतःच्या बिल्डरला इंस्टॉलेशन पॅकेजसाठी लिहिले आणि एका आठवड्यात ते पूर्ण केले. मग आम्हाला सिस्टमच्या मुख्य कार्यक्षमतेतून इंस्टॉलर सुधारित करावे लागले, कारण ते ओपन-सोर्स आहे. तपासण्या आणि बदलांच्या मालिकेनंतर, निकाल यशस्वी मानला गेला. यादरम्यान, रिलीझची रचना आकार घेतली, ज्याच्या योग्य स्थापनेसाठी चाचणी सर्किटला उत्पादनासह संरेखित करणे आवश्यक होते आणि यासाठी एक स्वतंत्र स्क्रिप्ट लिहिली गेली.

स्वाभाविकच, पहिल्या स्थापनेबद्दल बर्याच टिप्पण्या होत्या, परंतु एकूणच कोडने कार्य केले. आणि तिसऱ्या स्थापनेनंतर सर्वकाही चांगले दिसू लागले. मॅन्युअल मोडमध्ये रचना नियंत्रण आणि ऑब्जेक्ट्सच्या आवृत्ती नियंत्रणाचे स्वतंत्रपणे परीक्षण केले गेले, जे या टप्प्यावर अगदी न्याय्य होते.

एक अतिरिक्त आव्हान हे मोठ्या संख्येने नॉन-रिलीझ होते जे लक्षात घेतले पाहिजे. परंतु प्रॉड सारखी शाखा आणि रिबेसमुळे कार्य पारदर्शक झाले.

प्रथमच, द्रुत आणि त्रुटींशिवाय

आम्ही आशावादी वृत्तीने आणि वेगवेगळ्या सर्किट्सवर एक डझनहून अधिक यशस्वी इंस्टॉलेशन्ससह प्रकाशनाशी संपर्क साधला. परंतु अक्षरशः अंतिम मुदतीच्या एक दिवस आधी, असे दिसून आले की विक्रेत्याने स्वीकारलेल्या पद्धतीने स्थापनेसाठी प्रकाशन तयार करण्याचे काम पूर्ण केले नाही. काही कारणास्तव आमची बिल्ड कार्य करत नसल्यास, प्रकाशन विस्कळीत होईल. शिवाय, आमच्या प्रयत्नांद्वारे, जे विशेषतः अप्रिय आहे. आमच्याकडे माघार घेण्याचा मार्ग नव्हता. म्हणून, आम्ही पर्यायी पर्यायांचा विचार केला, कृती योजना तयार केल्या आणि स्थापना सुरू केली.

आश्चर्याची गोष्ट म्हणजे, 800 हून अधिक वस्तूंचा समावेश असलेले संपूर्ण प्रकाशन, प्रथमच आणि फक्त 10 मिनिटांत योग्यरित्या सुरू झाले. आम्ही त्रुटी शोधण्यात लॉग तपासण्यात एक तास घालवला, परंतु काही सापडले नाही.

संपूर्ण दुसऱ्या दिवशी रिलीझ चॅटमध्ये शांतता होती: कोणतीही अंमलबजावणी समस्या, कुटिल आवृत्त्या किंवा "अयोग्य" कोड नाही. ते काहीसे अस्ताव्यस्तही होते. नंतर, काही टिप्पण्या उदयास आल्या, परंतु इतर प्रणाली आणि मागील अनुभवाच्या तुलनेत त्यांची संख्या आणि प्राधान्य लक्षणीयपणे कमी होते.

एकत्रित प्रभावाचा अतिरिक्त परिणाम म्हणजे असेंब्ली आणि चाचणीच्या गुणवत्तेत वाढ. पूर्ण प्रकाशनाच्या एकाधिक स्थापनेमुळे, बिल्ड दोष आणि उपयोजन त्रुटी वेळेवर ओळखल्या गेल्या. पूर्ण रिलीझ कॉन्फिगरेशनमधील चाचणीमुळे वाढीव स्थापनेदरम्यान न दिसणार्‍या वस्तूंच्या परस्पर प्रभावातील दोष ओळखणे शक्य झाले. हे निश्चितपणे यशस्वी ठरले, विशेषत: रिलीजमध्ये आमचे 57% योगदान दिले.

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

एका वर्षापेक्षा कमी कालावधीत आम्ही व्यवस्थापित केले:

• एक विदेशी प्रणाली वापरून पूर्ण वाढ झालेला अंतर्गत विकास तयार करा;
• गंभीर विक्रेता अवलंबित्व दूर करा;
• अतिशय मैत्रीपूर्ण वारसासाठी CI/CD लाँच करा;
• नवीन तांत्रिक स्तरावर अंमलबजावणी प्रक्रिया वाढवा;
• उपयोजन वेळ लक्षणीयरीत्या कमी करा;
• अंमलबजावणी त्रुटींची संख्या लक्षणीयरीत्या कमी करा;
• आत्मविश्वासाने स्वतःला एक आघाडीचे विकास तज्ञ म्हणून घोषित करा.

अर्थात, जे वर्णन केले आहे त्यातील बरेच काही पूर्णपणे बकवास दिसते, परंतु ही प्रणालीची वैशिष्ट्ये आणि त्यामध्ये अस्तित्वात असलेल्या प्रक्रियेच्या मर्यादा आहेत. या क्षणी, बदलांमुळे IS प्रोफाइल उत्पादने आणि सेवांवर परिणाम झाला आहे (मास्टर खाती, प्लास्टिक कार्ड, बचत खाती, एस्क्रो, रोख कर्ज), परंतु संभाव्यतः हा दृष्टिकोन कोणत्याही IS वर लागू केला जाऊ शकतो ज्यासाठी DevOps पद्धती लागू करण्याचे कार्य सेट केले आहे. संचयी मॉडेल अनेक वितरणांमधून त्यानंतरच्या अंमलबजावणीसाठी (रिलीझ न झालेल्यांसह) सुरक्षितपणे प्रतिकृती बनवले जाऊ शकते.

स्त्रोत: www.habr.com