स्क्रिप्ट्सपासून आमच्या स्वतःच्या प्लॅटफॉर्मवर: आम्ही CIAN मध्ये विकास कसा स्वयंचलित केला

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

शून्य पातळी

"शून्य पातळी अशी कोणतीही गोष्ट नाही, मला अशी गोष्ट माहित नाही"
"कुंग फू पांडा" चित्रपटातील मास्टर शिफू

कंपनीची स्थापना झाल्यानंतर 14 वर्षांनी CIAN मध्ये ऑटोमेशन सुरू झाले. त्यावेळी विकास संघात 35 जण होते. विश्वास ठेवणे कठीण आहे, बरोबर? अर्थात, ऑटोमेशन काही स्वरूपात अस्तित्वात होते, परंतु सतत एकत्रीकरण आणि कोड वितरणासाठी एक वेगळी दिशा 2015 मध्ये आकार घेऊ लागली. 

त्या वेळी, आमच्याकडे पायथन, सी# आणि पीएचपीचा एक मोठा मोनोलिथ होता, जो लिनक्स/विंडोज सर्व्हरवर तैनात होता. हा राक्षस तैनात करण्यासाठी, आमच्याकडे स्क्रिप्टचा एक संच होता जो आम्ही स्वहस्ते चालवला. मोनोलिथची असेंब्ली देखील होती, ज्याने फांद्या विलीन करताना, दोष दुरुस्त करताना आणि "बिल्डमधील वेगळ्या कार्यांसह" पुनर्बांधणी करताना संघर्षांमुळे वेदना आणि त्रास दिला. एक सरलीकृत प्रक्रिया असे दिसते:

आम्ही यासह आनंदी नव्हतो आणि आम्हाला पुनरावृत्ती करण्यायोग्य, स्वयंचलित आणि व्यवस्थापित करण्यायोग्य बिल्ड आणि उपयोजन प्रक्रिया तयार करायची होती. यासाठी, आम्हाला CI/CD प्रणालीची आवश्यकता होती आणि आम्ही टीमसिटीची विनामूल्य आवृत्ती आणि जेनकिन्सची विनामूल्य आवृत्ती यापैकी एक निवडली, कारण आम्ही त्यांच्याबरोबर काम केले आणि दोन्ही कार्यांच्या संचाच्या दृष्टीने आम्हाला अनुकूल आहेत. आम्ही टीमसिटी हे अगदी अलीकडील उत्पादन म्हणून निवडले. त्या वेळी, आम्ही अद्याप मायक्रोसर्व्हिस आर्किटेक्चर वापरले नव्हते आणि मोठ्या संख्येने कार्ये आणि प्रकल्पांची अपेक्षा केली नव्हती.

आपल्या स्वतःच्या व्यवस्थेची कल्पना आपल्याला येते

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

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

व्यवसाय प्रक्रियांमध्ये ऑटोमेशन वाढल्यामुळे, टीमसिटीमध्ये प्रकल्प आणि धावांची संख्या वाढली आहे. त्यामुळे एक नवीन समस्या आली: एक विनामूल्य टीमसिटी उदाहरण पुरेसे नव्हते (3 एजंट आणि 100 प्रकल्प), आम्ही दुसरे उदाहरण जोडले (3 आणखी एजंट आणि 100 प्रकल्प), नंतर दुसरे. परिणामी, आम्ही अनेक क्लस्टर्सच्या प्रणालीसह समाप्त झालो, जे व्यवस्थापित करणे कठीण होते:

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

मूलभूत ऑटोमेशनच्या वाढीसह (पुल विनंत्या स्वयंचलितपणे तयार करणे, कोड कव्हरेजचे संकलन आणि प्रकाशन आणि इतर तपासण्यांच्या रूपात), शक्य तितक्या मॅन्युअल प्रकाशनांचा त्याग करण्याची आणि हे काम रोबोट्सकडे देण्याची तीव्र इच्छा आहे. याव्यतिरिक्त, कंपनीने कंपनीमधील मायक्रोसर्व्हिसेसकडे जाण्यास सुरुवात केली, ज्यासाठी वारंवार प्रकाशन आवश्यक होते आणि एकमेकांपासून वेगळे होते. अशा प्रकारे आम्ही हळूहळू आमच्या मायक्रोसर्व्हिसेसच्या स्वयंचलित रिलीझवर आलो (आम्ही सध्या प्रक्रियेच्या जटिलतेमुळे मोनोलिथ मॅन्युअली रिलीझ करत आहोत). परंतु, जसे सहसा घडते, एक नवीन जटिलता उद्भवली. 

आम्ही चाचणी स्वयंचलित करतो

प्रकाशनांच्या ऑटोमेशनमुळे, काही चाचणी टप्पे वगळल्यामुळे, विकास प्रक्रिया वेगवान झाल्या आहेत. आणि यामुळे गुणवत्तेचे तात्पुरते नुकसान झाले. हे क्षुल्लक वाटते, परंतु प्रकाशनाच्या प्रवेग सोबत, उत्पादन विकासाची पद्धत बदलणे आवश्यक होते. चाचणीचे ऑटोमेशन, रिलीझ केलेल्या कोडसाठी विकसकाच्या वैयक्तिक जबाबदारीबद्दल (येथे आम्ही "डोक्यात कल्पना स्वीकारणे" बद्दल बोलत आहोत, आर्थिक दंड नाही) बद्दल विचार करणे आवश्यक होते आणि त्यामधील बग्स, तसेच निर्णय. स्वयंचलित उपयोजनाद्वारे कार्य सोडणे/रिलीझ करू नका. 

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

ऑटोमेशन टीम

आमच्याकडे सध्या 130 डेव्हलपरचे कर्मचारी आहेत आणि आम्ही सुरू ठेवतो वाढू. सतत एकत्रीकरण आणि कोड डिलिव्हरीसाठी (यापुढे डिप्लॉय अँड इंटिग्रेशन किंवा DI टीम म्हणून संदर्भित) टीममध्ये 7 लोक असतात आणि 2 दिशांमध्ये काम करतात: इंटिग्रो ऑटोमेशन प्लॅटफॉर्म आणि DevOps चा विकास. 

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

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

CIAN येथे ऑटोमेशनचा लेयर केक

ऑटोमेशनमध्ये सामील असलेल्या सर्व प्रणाली अनेक स्तरांमध्ये विभागल्या जाऊ शकतात:

1. बाह्य प्रणाली (जिरा, बिटबकेट इ.). विकास पथके त्यांच्यासोबत काम करतात.
2. इंटिग्रो प्लॅटफॉर्म. बर्‍याचदा, विकसक त्याच्याशी थेट कार्य करत नाहीत, परंतु हे सर्व ऑटोमेशन चालू ठेवते.
3. वितरण, ऑर्केस्ट्रेशन आणि शोध सेवा (उदाहरणार्थ, जेकनिन्स, कॉन्सुल, नोमॅड). त्यांच्या मदतीने, आम्ही सर्व्हरवर कोड उपयोजित करतो आणि सेवा एकमेकांसोबत काम करत असल्याची खात्री करतो.
4. भौतिक स्तर (सर्व्हर, OS, संबंधित सॉफ्टवेअर). आमचा कोड या स्तरावर कार्य करतो. हे एकतर भौतिक सर्व्हर किंवा आभासी सर्व्हर (LXC, KVM, डॉकर) असू शकते.

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

अखंड

चला Integro वर लक्ष केंद्रित करू आणि तंत्रज्ञान स्टॅकसह प्रारंभ करूया:

• CentOS 7
• डॉकर + नोमॅड + कॉन्सुल + व्हॉल्ट
• Java 11 (जुना इंटिग्रो मोनोलिथ Java 8 वर राहील)
• स्प्रिंग बूट 2.X + स्प्रिंग क्लाउड कॉन्फिग
• PostgreSql 11
• ससा MQ 
• अपाचे प्रज्वलित
• कमुंडा (एम्बेडेड)
• ग्राफाना + ग्रेफाइट + प्रोमिथियस + जेगर + ELK
• वेब UI: प्रतिक्रिया (CSR) + MobX
• SSO: कीक्लोक

आम्ही मायक्रोसर्व्हिस डेव्हलपमेंटच्या तत्त्वाचे पालन करतो, जरी आमच्याकडे इंटिग्रोच्या सुरुवातीच्या आवृत्तीच्या मोनोलिथच्या रूपात वारसा आहे. प्रत्येक मायक्रोसर्व्हिस स्वतःच्या डॉकर कंटेनरमध्ये चालते आणि सेवा HTTP विनंत्या आणि RabbitMQ संदेशांद्वारे एकमेकांशी संवाद साधतात. मायक्रोसर्व्हिसेस कॉन्सुलद्वारे एकमेकांना शोधतात आणि SSO (कीक्लोक, OAuth 2/OpenID कनेक्ट) द्वारे अधिकृतता देऊन त्यांना विनंती करतात.

वास्तविक जीवनातील उदाहरण म्हणून, जेनकिन्सशी संवाद साधण्याचा विचार करा, ज्यामध्ये खालील चरणांचा समावेश आहे:

1. वर्कफ्लो मॅनेजमेंट मायक्रोसर्व्हिस (यापुढे फ्लो मायक्रोसर्व्हिस म्हणून संदर्भित) जेनकिन्समध्ये बिल्ड चालवू इच्छित आहे. हे करण्यासाठी, तो जेनकिन्स (यापुढे जेनकिन्स मायक्रोसर्व्हिस म्हणून संदर्भित) सह एकत्रीकरणासाठी मायक्रोसर्व्हिसचा IP:PORT शोधण्यासाठी कॉन्सुल वापरतो आणि जेनकिन्समध्ये बिल्ड सुरू करण्यासाठी त्याला अॅसिंक्रोनस विनंती पाठवतो.
2. विनंती प्राप्त केल्यानंतर, जेनकिन्स मायक्रोसर्व्हिस जॉब आयडी तयार करते आणि प्रतिसाद देते, ज्याचा वापर नंतर कामाचा परिणाम ओळखण्यासाठी केला जाऊ शकतो. त्याच वेळी, ते REST API कॉलद्वारे जेनकिन्समधील बिल्डला ट्रिगर करते.
3. जेनकिन्स बिल्ड करते आणि पूर्ण झाल्यानंतर, जेनकिन्स मायक्रोसर्व्हिसला अंमलबजावणी परिणामांसह एक वेबहुक पाठवते.
4. जेनकिन्स मायक्रोसर्व्हिस, वेबहुक प्राप्त केल्यानंतर, विनंती प्रक्रिया पूर्ण झाल्याबद्दल संदेश व्युत्पन्न करते आणि अंमलबजावणीचे परिणाम त्यास संलग्न करते. व्युत्पन्न केलेला संदेश RabbitMQ रांगेत पाठवला जातो.
5. RabbitMQ द्वारे, प्रकाशित संदेश फ्लो मायक्रोसर्व्हिसपर्यंत पोहोचतो, जो विनंती आणि प्राप्त संदेशातील जॉब आयडी जुळवून त्याच्या कार्यावर प्रक्रिया करण्याच्या परिणामाबद्दल शिकतो.

आता आमच्याकडे सुमारे 30 मायक्रो सर्व्हिसेस आहेत, ज्या अनेक गटांमध्ये विभागल्या जाऊ शकतात:

1. कॉन्फिगरेशन व्यवस्थापन.
2. वापरकर्त्यांशी माहिती आणि संवाद (मेसेंजर, मेल).
3. स्त्रोत कोडसह कार्य करणे.
4. उपयोजन साधनांसह एकत्रीकरण (जेनकिन्स, भटक्या, सल्लागार इ.).
5. देखरेख (रिलीझ, त्रुटी इ.).
6. वेब उपयुक्तता (चाचणी वातावरण व्यवस्थापित करण्यासाठी, आकडेवारी गोळा करण्यासाठी UI).
7. टास्क ट्रॅकर्स आणि तत्सम सिस्टमसह एकत्रीकरण.
8. वेगवेगळ्या कामांसाठी वर्कफ्लो व्यवस्थापन.

कार्यप्रवाह कार्ये

इंटिग्रो टास्क लाइफसायकलशी संबंधित क्रियाकलाप स्वयंचलित करते. सोप्या भाषेत, एखाद्या कार्याचे जीवनचक्र हे जिरामधील कार्याचा कार्यप्रवाह समजले जाईल. आमच्या डेव्हलपमेंट प्रोसेसमध्ये प्रोजेक्ट, टास्कचा प्रकार आणि विशिष्ट टास्कमध्ये निवडलेल्या पर्यायांवर अवलंबून अनेक वर्कफ्लो बदल आहेत. 

आपण बर्‍याचदा वापरतो तो कार्यप्रवाह पाहू:

आकृतीमध्ये, गियर सूचित करतो की संक्रमणास इंटिग्रोद्वारे स्वयंचलितपणे कॉल केले जाते, तर मानवी आकृती सूचित करते की एखाद्या व्यक्तीद्वारे संक्रमण स्वहस्ते म्हटले जाते. या वर्कफ्लोमध्ये कार्य करू शकणारे अनेक मार्ग पाहू या.

कॅनरी चाचण्यांशिवाय DEV + BETA वर पूर्णपणे मॅन्युअल चाचणी (सामान्यत: अशा प्रकारे आपण मोनोलिथ सोडतो):

इतर संक्रमण संयोजन असू शकतात. कधी कधी एखादी समस्या घेईल तो मार्ग जिरामधील पर्यायांद्वारे निवडला जाऊ शकतो.

कार्य चळवळ

एखादे कार्य जेव्हा “DEV Testing + Canary Tests” वर्कफ्लोमधून पुढे जाते तेव्हा केल्या जाणार्‍या मुख्य पायऱ्या पाहू या:

1. विकासक किंवा पंतप्रधान कार्य तयार करतात.

2. डेव्हलपर हे काम कामावर घेतो. पूर्ण झाल्यानंतर, ते पुनरावलोकन स्थितीवर स्विच करते.

3. जिरा जिरा मायक्रोसर्व्हिसला वेबहुक पाठवते (जिरा सह एकत्रीकरणासाठी जबाबदार).

4. जिरा मायक्रोसर्व्हिस वर्कफ्लो सुरू करण्यासाठी फ्लो सेवेला (अंतर्गत वर्कफ्लोसाठी जबाबदार आहे ज्यामध्ये काम केले जाते) विनंती पाठवते.

5. फ्लो सेवेच्या आत:

• पुनरावलोकनकर्त्यांना कार्य नियुक्त केले आहे (वापरकर्ते मायक्रोसर्व्हिस ज्यांना वापरकर्त्यांबद्दल सर्व काही माहित आहे + जिरा मायक्रोसर्व्हिस).
• स्त्रोत मायक्रोसर्व्हिसद्वारे (याला भांडार आणि शाखांबद्दल माहिती आहे, परंतु कोडसह कार्य करत नाही), आमच्या समस्येची शाखा असलेल्या भांडारांसाठी शोध केला जातो (शोध सोपे करण्यासाठी, शाखेचे नाव समस्येशी जुळते. जिरा मध्ये संख्या). बर्‍याचदा, टास्कची एका रेपॉजिटरीमध्ये फक्त एक शाखा असते; हे उपयोजन रांगेचे व्यवस्थापन सुलभ करते आणि भांडारांमधील कनेक्टिव्हिटी कमी करते.
• प्रत्येक सापडलेल्या शाखेसाठी, क्रियांचा खालील क्रम केला जातो:

  i) मुख्य शाखा अद्यतनित करणे (कोडसह कार्य करण्यासाठी Git मायक्रो सर्व्हिस).
  ii) शाखा विकासकाद्वारे (बिटबकेट मायक्रोसर्व्हिस) बदलांपासून अवरोधित केली आहे.
  iii) या शाखेसाठी (Bitbucket microservice) पुल विनंती तयार केली आहे.
  iv) नवीन पुल विनंतीबद्दलचा संदेश विकसक चॅटवर पाठवला जातो (सूचनांसोबत काम करण्यासाठी मायक्रोसर्व्हिसला सूचित करा).
  v) DEV (जेनकिन्ससोबत काम करण्यासाठी जेनकिन्स मायक्रोसर्व्हिस) वर बिल्ड, टेस्ट आणि डिप्लॉय टास्क सुरू केल्या आहेत.
  vi) जर मागील सर्व पायऱ्या यशस्वीरीत्या पूर्ण झाल्या, तर Integro पूल रिक्वेस्टमध्ये (Bitbucket microservice) त्याचे अप्रूव्ह ठेवते.

• Integro नियुक्त समीक्षकांकडून पुल विनंती मंजूर होण्याची वाट पाहत आहे.
• सर्व आवश्यक मंजूरी मिळताच (स्वयंचलित चाचण्या सकारात्मक उत्तीर्ण झाल्यासह), इंटिग्रो हे टास्क ऑन डेव्ह (जिरा मायक्रोसर्व्हिस) स्थितीकडे हस्तांतरित करते.

6. परीक्षक कार्य चाचणी करतात. कोणतीही समस्या नसल्यास, कार्य तयार करण्यासाठी तयार स्थितीत हस्तांतरित केले जाते.

7. इंटिग्रो "पाहतो" की कार्य रिलीझसाठी तयार आहे आणि कॅनरी मोडमध्ये (जेनकिन्स मायक्रोसर्व्हिस) तैनात करणे सुरू करते. प्रकाशनाची तयारी नियमांच्या संचाद्वारे निर्धारित केली जाते. उदाहरणार्थ, कार्य आवश्यक स्थितीत आहे, इतर कार्यांवर कोणतेही लॉक नाहीत, सध्या या मायक्रोसर्व्हिसचे कोणतेही सक्रिय अपलोड नाहीत इ.

8. कार्य कॅनरी स्थिती (जिरा मायक्रोसर्व्हिस) मध्ये हस्तांतरित केले आहे.

9. जेनकिन्स नोमॅडद्वारे कॅनरी मोडमध्ये तैनाती कार्य लाँच करते (सामान्यतः 1-3 उदाहरणे) आणि तैनातीबद्दल रिलीज मॉनिटरिंग सर्व्हिस (डिप्लॉयवॉच मायक्रोसर्व्हिस) सूचित करते.

10. DeployWatch microservice त्रुटी पार्श्वभूमी गोळा करते आणि आवश्यक असल्यास त्यावर प्रतिक्रिया देते. त्रुटी पार्श्वभूमी ओलांडल्यास (पार्श्वभूमी मानक स्वयंचलितपणे मोजले जाते), विकासकांना सूचित मायक्रोसर्व्हिसद्वारे सूचित केले जाते. जर 5 मिनिटांनंतर विकसकाने प्रतिसाद दिला नाही (रिव्हर्ट किंवा स्टे क्लिक करा), तर कॅनरी उदाहरणांचा स्वयंचलित रोलबॅक लॉन्च केला जाईल. जर पार्श्वभूमी ओलांडली नसेल, तर विकासकाने उत्पादनासाठी (UI मधील बटण क्लिक करून) टास्क डिप्लॉयमेंट मॅन्युअली लाँच करणे आवश्यक आहे. जर 60 मिनिटांच्या आत विकासकाने उत्पादनासाठी उपयोजन सुरू केले नाही, तर सुरक्षिततेच्या कारणास्तव कॅनरी उदाहरणे देखील मागे घेतली जातील.

11. उत्पादनासाठी उपयोजन सुरू केल्यानंतर:

• कार्य उत्पादन स्थिती (जिरा मायक्रोसर्व्हिस) मध्ये हस्तांतरित केले आहे.
• जेनकिन्स मायक्रोसर्व्हिस डिप्लॉयमेंट प्रक्रिया सुरू करते आणि डिप्लॉयमेंट बद्दल डिप्लॉयवॉच मायक्रोसर्व्हिसला सूचित करते.
• DeployWatch मायक्रोसर्व्हिस तपासते की उत्पादनावरील सर्व कंटेनर अद्यतनित केले गेले आहेत (अशी प्रकरणे होती जेव्हा सर्व अद्यतनित केले गेले नाहीत).
• अधिसूचना मायक्रोसर्व्हिस द्वारे, उपयोजनाच्या परिणामांबद्दल एक सूचना उत्पादनाला पाठविली जाते.

12. चुकीची मायक्रोसर्व्हिस वर्तणूक आढळल्यास डेव्हलपर्सकडे उत्पादनातून एखादे कार्य रोल बॅक करणे सुरू करण्यासाठी 30 मिनिटे असतील. या वेळेनंतर, कार्य आपोआप मास्टर (Git microservice) मध्ये विलीन केले जाईल.

13. मास्टरमध्ये यशस्वी विलीन झाल्यानंतर, कार्य स्थिती बंद (जिरा मायक्रोसर्व्हिस) मध्ये बदलली जाईल.

आकृती पूर्णपणे तपशीलवार असल्याचे भासवत नाही (वास्तविकतेमध्ये आणखी पायऱ्या आहेत), परंतु ते आपल्याला प्रक्रियांमध्ये एकत्रीकरणाच्या डिग्रीचे मूल्यांकन करण्यास अनुमती देते. आम्ही ही योजना आदर्श मानत नाही आणि स्वयंचलित प्रकाशन आणि उपयोजन समर्थनाच्या प्रक्रियेत सुधारणा करत आहोत.

पुढे काय

ऑटोमेशनच्या विकासासाठी आमच्याकडे मोठ्या योजना आहेत, उदाहरणार्थ, मोनोलिथ रिलीझ दरम्यान मॅन्युअल ऑपरेशन्स काढून टाकणे, स्वयंचलित तैनाती दरम्यान देखरेख सुधारणे आणि विकासकांशी संवाद सुधारणे.

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

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