स्क्रिप्ट से लेकर हमारे अपने प्लेटफ़ॉर्म तक: हमने CIAN में विकास को कैसे स्वचालित किया

RIT 2019 में, हमारे सहयोगी अलेक्जेंडर कोरोटकोव ने बनाया रिपोर्ट CIAN में विकास के स्वचालन के बारे में: जीवन और कार्य को सरल बनाने के लिए, हम अपने स्वयं के इंटीग्रो प्लेटफ़ॉर्म का उपयोग करते हैं। यह कार्यों के जीवन चक्र को ट्रैक करता है, डेवलपर्स को नियमित संचालन से राहत देता है और उत्पादन में बग की संख्या को काफी कम करता है। इस पोस्ट में, हम अलेक्जेंडर की रिपोर्ट को पूरक करेंगे और आपको बताएंगे कि कैसे हम सरल स्क्रिप्ट से अपने मंच के माध्यम से ओपन सोर्स उत्पादों के संयोजन तक चले गए और हमारी अलग स्वचालन टीम क्या करती है।
 

शून्य स्तर

"शून्य स्तर जैसी कोई चीज़ नहीं होती, मैं ऐसी कोई चीज़ नहीं जानता"
फिल्म "कुंग फू पांडा" से मास्टर शिफू

कंपनी की स्थापना के 14 साल बाद CIAN में स्वचालन शुरू हुआ। उस समय विकास दल में 35 लोग थे। विश्वास करना कठिन है, है ना? बेशक, स्वचालन किसी न किसी रूप में मौजूद था, लेकिन निरंतर एकीकरण और कोड वितरण के लिए एक अलग दिशा 2015 में आकार लेना शुरू हुई। 

उस समय, हमारे पास लिनक्स/विंडोज सर्वर पर तैनात पायथन, सी# और पीएचपी का एक विशाल मोनोलिथ था। इस राक्षस को तैनात करने के लिए, हमारे पास स्क्रिप्ट का एक सेट था जिसे हम मैन्युअल रूप से चलाते थे। वहाँ मोनोलिथ की असेंबली भी थी, जो शाखाओं के विलय, दोषों को ठीक करने और "निर्माण में कार्यों के एक अलग सेट के साथ" पुनर्निर्माण के दौरान संघर्ष के कारण दर्द और पीड़ा लाती थी। एक सरलीकृत प्रक्रिया इस प्रकार दिखी:

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

हमें अपने स्वयं के सिस्टम का विचार आता है

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

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

व्यावसायिक प्रक्रियाओं में स्वचालन में वृद्धि के कारण, टीमसिटी में परियोजनाओं और रनों की संख्या में वृद्धि हुई है। तो एक नई समस्या आई: एक निःशुल्क टीमसिटी उदाहरण पर्याप्त नहीं था (3 एजेंट और 100 परियोजनाएँ), हमने एक और उदाहरण जोड़ा (3 और एजेंट और 100 परियोजनाएँ), फिर एक और। परिणामस्वरूप, हमें कई समूहों की एक प्रणाली मिली, जिसे प्रबंधित करना मुश्किल था:

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

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

हम परीक्षण स्वचालित करते हैं

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

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

स्वचालन टीम

वर्तमान में हमारे पास 130 डेवलपर्स का स्टाफ है, और हम जारी रखेंगे बढ़ने के लिए. सतत एकीकरण और कोड वितरण टीम (बाद में इसे डिप्लॉय और इंटीग्रेशन या डीआई टीम के रूप में संदर्भित किया जाएगा) में 7 लोग शामिल हैं और यह 2 दिशाओं में काम करती है: इंटेग्रो ऑटोमेशन प्लेटफॉर्म और डेवऑप्स का विकास। 

DevOps CIAN साइट के डेव/बीटा वातावरण, इंटेग्रो वातावरण के लिए जिम्मेदार है, जो डेवलपर्स को समस्याओं को हल करने में मदद करता है और स्केलिंग वातावरण के लिए नए दृष्टिकोण विकसित करता है। इंटेग्रो विकास दिशा स्वयं इंटेग्रो और संबंधित सेवाओं दोनों से संबंधित है, उदाहरण के लिए, जेनकिंस, जीरा, कॉन्फ्लुएंस के लिए प्लगइन्स, और विकास टीमों के लिए सहायक उपयोगिताओं और अनुप्रयोगों को भी विकसित करता है। 

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

CIAN में स्वचालन का लेयर केक

स्वचालन में शामिल सभी प्रणालियों को कई परतों में विभाजित किया जा सकता है:

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

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

integro

आइए इंटेग्रो पर ध्यान केंद्रित करें और प्रौद्योगिकी स्टैक से शुरुआत करें:

• सेंटओएस 7
• डॉकर + खानाबदोश + कौंसल + वॉल्ट
• जावा 11 (पुराना इंटेग्रो मोनोलिथ जावा 8 पर रहेगा)
• स्प्रिंग बूट 2.X + स्प्रिंग क्लाउड कॉन्फ़िगरेशन
• पोस्टग्रेस्क्ल 11
• RabbitMQ 
• अपाचे इग्नाइट
• कैमुंडा (एम्बेडेड)
• ग्राफाना + ग्रेफाइट + प्रोमेथियस + जैगर + ईएलके
• वेब यूआई: रिएक्ट (सीएसआर) + मोबएक्स
• एसएसओ: कीक्लोक

हम माइक्रोसर्विस विकास के सिद्धांत का पालन करते हैं, हालांकि हमारे पास इंटेग्रो के शुरुआती संस्करण के मोनोलिथ के रूप में विरासत है। प्रत्येक माइक्रोसर्विस अपने स्वयं के डॉकर कंटेनर में चलती है, और सेवाएँ HTTP अनुरोधों और RabbitMQ संदेशों के माध्यम से एक दूसरे के साथ संचार करती हैं। माइक्रोसर्विसेज कंसल के माध्यम से एक-दूसरे को ढूंढते हैं और एसएसओ (कीक्लोक, ओएथ 2/ओपनआईडी कनेक्ट) के माध्यम से प्राधिकरण पारित करते हुए उससे अनुरोध करते हैं।

वास्तविक जीवन के उदाहरण के रूप में, जेनकिंस के साथ बातचीत करने पर विचार करें, जिसमें निम्नलिखित चरण शामिल हैं:

1. वर्कफ़्लो प्रबंधन माइक्रोसर्विस (इसके बाद फ़्लो माइक्रोसर्विस के रूप में संदर्भित) जेनकींस में एक बिल्ड चलाना चाहता है। ऐसा करने के लिए, वह जेनकींस (बाद में जेनकींस माइक्रोसर्विस के रूप में संदर्भित) के साथ एकीकरण के लिए माइक्रोसर्विस के आईपी:पोर्ट को खोजने के लिए कॉन्सल का उपयोग करता है और जेनकींस में निर्माण शुरू करने के लिए इसे एक अतुल्यकालिक अनुरोध भेजता है।
2. अनुरोध प्राप्त करने के बाद, जेनकिंस माइक्रोसर्विस एक जॉब आईडी उत्पन्न करती है और प्रतिक्रिया देती है, जिसका उपयोग कार्य के परिणाम की पहचान करने के लिए किया जा सकता है। साथ ही, यह REST API कॉल के माध्यम से जेनकींस में बिल्ड को ट्रिगर करता है।
3. जेनकिंस निर्माण करता है और पूरा होने के बाद, निष्पादन परिणामों के साथ जेनकिंस माइक्रोसर्विस को एक वेबहुक भेजता है।
4. जेनकिंस माइक्रोसर्विस, वेबहुक प्राप्त करने के बाद, अनुरोध प्रसंस्करण के पूरा होने के बारे में एक संदेश उत्पन्न करता है और निष्पादन परिणामों को इसमें संलग्न करता है। उत्पन्न संदेश RabbitMQ कतार में भेजा जाता है।
5. RabbitMQ के माध्यम से, प्रकाशित संदेश फ्लो माइक्रोसर्विस तक पहुंचता है, जो अनुरोध और प्राप्त संदेश से जॉब आईडी का मिलान करके अपने कार्य को संसाधित करने के परिणाम के बारे में सीखता है।

अब हमारे पास लगभग 30 माइक्रोसर्विसेज हैं, जिन्हें कई समूहों में विभाजित किया जा सकता है:

1. विन्यास प्रबंधन।
2. उपयोगकर्ताओं के साथ सूचना और बातचीत (संदेशवाहक, मेल)।
3. स्रोत कोड के साथ कार्य करना.
4. परिनियोजन उपकरण (जेनकींस, खानाबदोश, कौंसल, आदि) के साथ एकीकरण।
5. निगरानी (रिलीज़, त्रुटियाँ, आदि)।
6. वेब उपयोगिताएँ (परीक्षण वातावरण के प्रबंधन, आँकड़े एकत्र करने आदि के लिए यूआई)।
7. कार्य ट्रैकर्स और समान प्रणालियों के साथ एकीकरण।
8. विभिन्न कार्यों के लिए वर्कफ़्लो प्रबंधन।

वर्कफ़्लो कार्य

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

आइए उस वर्कफ़्लो पर नज़र डालें जिसका हम अक्सर उपयोग करते हैं:

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

कैनरी परीक्षणों के बिना DEV+BETA पर पूरी तरह से मैन्युअल परीक्षण (आमतौर पर हम इसी तरह एक मोनोलिथ जारी करते हैं):

अन्य संक्रमण संयोजन भी हो सकते हैं. कभी-कभी कोई मुद्दा जो रास्ता अपनाएगा उसे जीरा में विकल्पों के माध्यम से चुना जा सकता है।

कार्य आंदोलन

आइए उन मुख्य चरणों पर नज़र डालें जो तब किए जाते हैं जब कोई कार्य "DEV परीक्षण + कैनरी परीक्षण" वर्कफ़्लो के माध्यम से आगे बढ़ता है:

1. डेवलपर या पीएम कार्य बनाता है।

2. डेवलपर काम करने के लिए कार्य लेता है। पूरा होने के बाद, यह IN REVIEW स्थिति में बदल जाता है।

3. जीरा, जीरा माइक्रोसर्विस (जीरा के साथ एकीकरण के लिए जिम्मेदार) को एक वेबहुक भेजता है।

4. जीरा माइक्रोसर्विस वर्कफ़्लो शुरू करने के लिए फ़्लो सेवा (आंतरिक वर्कफ़्लो के लिए ज़िम्मेदार जिसमें काम किया जाता है) को एक अनुरोध भेजता है।

5. प्रवाह सेवा के अंदर:

• समीक्षकों को कार्य सौंपा गया है (उपयोगकर्ता माइक्रोसर्विस जो उपयोगकर्ताओं + जीरा माइक्रोसर्विस के बारे में सब कुछ जानता है)।
• सोर्स माइक्रोसर्विस के माध्यम से (यह रिपॉजिटरी और शाखाओं के बारे में जानता है, लेकिन कोड के साथ ही काम नहीं करता है), रिपॉजिटरी की खोज की जाती है जिसमें हमारे मुद्दे की एक शाखा होती है (खोज को सरल बनाने के लिए, शाखा का नाम मुद्दे के साथ मेल खाता है) जिरा में संख्या)। अक्सर, किसी कार्य की एक रिपॉजिटरी में केवल एक शाखा होती है; यह परिनियोजन कतार के प्रबंधन को सरल बनाता है और रिपॉजिटरी के बीच कनेक्टिविटी को कम करता है।
• प्रत्येक पाई गई शाखा के लिए, क्रियाओं का निम्नलिखित क्रम निष्पादित किया जाता है:

  i) मास्टर ब्रांच को अपडेट करना (कोड के साथ काम करने के लिए Git माइक्रोसर्विस)।
  ii) शाखा को डेवलपर (बिटबकेट माइक्रोसर्विसेज) द्वारा परिवर्तनों से अवरुद्ध कर दिया गया है।
  iii) इस शाखा (बिटबकेट माइक्रोसर्विस) के लिए एक पुल अनुरोध बनाया गया है।
  iv) नए पुल अनुरोध के बारे में एक संदेश डेवलपर चैट पर भेजा जाता है (सूचनाओं के साथ काम करने के लिए माइक्रोसर्विस को सूचित करें)।
  v) निर्माण, परीक्षण और तैनाती कार्य DEV (जेनकींस के साथ काम करने के लिए जेनकींस माइक्रोसर्विस) पर शुरू किए गए हैं।
  vi) यदि पिछले सभी चरण सफलतापूर्वक पूरे हो गए हैं, तो इंटेग्रो अपना अप्रूवल पुल रिक्वेस्ट (बिटबकेट माइक्रोसर्विस) में डाल देता है।

• इंटीग्रो नामित समीक्षकों से पुल अनुरोध में अनुमोदन की प्रतीक्षा कर रहा है।
• जैसे ही सभी आवश्यक अनुमोदन प्राप्त हो जाते हैं (स्वचालित परीक्षणों के सकारात्मक रूप से उत्तीर्ण होने सहित), इंटेग्रो कार्य को टेस्ट ऑन डेव (जीरा माइक्रोसर्विस) स्थिति में स्थानांतरित कर देता है।

6. परीक्षक कार्य का परीक्षण करते हैं। यदि कोई समस्या नहीं है, तो कार्य को रेडी फॉर बिल्ड स्थिति में स्थानांतरित कर दिया जाता है।

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

8. कार्य को कैनरी स्थिति (जीरा माइक्रोसर्विस) में स्थानांतरित कर दिया गया है।

9. जेनकिंस कैनरी मोड (आमतौर पर 1-3 उदाहरण) में नोमैड के माध्यम से एक तैनाती कार्य शुरू करता है और तैनाती के बारे में रिलीज मॉनिटरिंग सेवा (डिप्लॉयवॉच माइक्रोसर्विस) को सूचित करता है।

10. डिप्लॉयवॉच माइक्रोसर्विस त्रुटि पृष्ठभूमि एकत्र करती है और यदि आवश्यक हो तो उस पर प्रतिक्रिया करती है। यदि त्रुटि पृष्ठभूमि पार हो गई है (पृष्ठभूमि मानदंड स्वचालित रूप से गणना की जाती है), तो डेवलपर्स को नोटिफाई माइक्रोसर्विस के माध्यम से सूचित किया जाता है। यदि 5 मिनट के बाद डेवलपर ने जवाब नहीं दिया है (रिवर्ट या स्टे पर क्लिक किया है), तो कैनरी इंस्टेंसेस का स्वचालित रोलबैक लॉन्च हो जाता है। यदि पृष्ठभूमि पार नहीं हुई है, तो डेवलपर को मैन्युअल रूप से कार्य परिनियोजन को उत्पादन में लॉन्च करना होगा (यूआई में एक बटन पर क्लिक करके)। यदि डेवलपर ने 60 मिनट के भीतर उत्पादन में तैनाती शुरू नहीं की है, तो सुरक्षा कारणों से कैनरी इंस्टेंसेस को भी वापस ले लिया जाएगा।

11. उत्पादन में तैनाती शुरू करने के बाद:

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

12. यदि गलत माइक्रोसर्विस व्यवहार का पता चलता है तो डेवलपर्स के पास प्रोडक्शन से किसी कार्य को वापस शुरू करने के लिए 30 मिनट का समय होगा। इस समय के बाद, कार्य स्वचालित रूप से मास्टर (Git माइक्रोसर्विस) में विलय हो जाएगा।

13. मास्टर में सफल विलय के बाद, कार्य स्थिति को बंद (जीरा माइक्रोसर्विसेज) में बदल दिया जाएगा।

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

आगे क्या है

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

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

स्रोत: www.habr.com