स्क्रिप्टबाट हाम्रो आफ्नै प्लेटफर्ममा: हामीले CIAN मा कसरी स्वचालित विकास गर्यौं

RIT 2019 मा, हाम्रा सहकर्मी अलेक्जेंडर कोरोत्कोभले बनाएका थिए रिपोर्ट CIAN मा विकासको स्वचालन बारे: जीवन र कामलाई सरल बनाउन, हामी हाम्रो आफ्नै Integro प्लेटफर्म प्रयोग गर्छौं। यसले कार्यहरूको जीवन चक्रलाई ट्र्याक गर्दछ, नियमित कार्यहरूको विकासकर्ताहरूलाई राहत दिन्छ र उत्पादनमा बगहरूको संख्यालाई उल्लेखनीय रूपमा कम गर्दछ। यस पोष्टमा, हामी अलेक्जेन्डरको रिपोर्टलाई पूरक गर्नेछौं र हामी कसरी सरल स्क्रिप्टहरूबाट हाम्रो आफ्नै प्लेटफर्म मार्फत खुला स्रोत उत्पादनहरू संयोजन गर्न गयौं र हाम्रो छुट्टै स्वचालन टोलीले के गर्छ भनेर बताउनेछौं।
 

शून्य स्तर

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

CIAN मा स्वचालन कम्पनी स्थापना भएको 14 वर्ष पछि सुरु भयो। त्यसबेला विकास टोलीमा ३५ जना थिए । विश्वास गर्न गाह्रो, हैन? निस्सन्देह, स्वचालन कुनै न कुनै रूपमा अवस्थित थियो, तर निरन्तर एकीकरण र कोड वितरणको लागि छुट्टै दिशा 35 मा आकार लिन थाल्यो। 

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

हामी यससँग खुसी थिएनौं, र हामी दोहोर्याउन मिल्ने, स्वचालित र व्यवस्थित निर्माण र तैनाती प्रक्रिया निर्माण गर्न चाहन्थ्यौं। यसको लागि, हामीलाई CI/CD प्रणाली चाहिन्छ, र हामीले Teamcity को नि: शुल्क संस्करण र Jenkins को नि: शुल्क संस्करण बीच छनौट गर्यौं, किनकि हामीले तिनीहरूसँग काम गर्यौं र दुवै प्रकार्यहरूको सेटको सन्दर्भमा हामीलाई उपयुक्त छ। हामीले Teamcity लाई हालैको उत्पादनको रूपमा रोज्यौं। त्यसबेला हामीले माइक्रोसर्भिस आर्किटेक्चर प्रयोग गरेका थिएनौं र ठूलो संख्यामा कार्य र परियोजनाहरूको आशा पनि गरेका थिएनौं।

हामी आफ्नै प्रणालीको विचारमा आएका छौं

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

Teamcity ले निर्माण र तैनाती प्रक्रियाहरू सुरु गर्ने स्तरमा स्वचालनसँग सम्झौता गर्दछ, जबकि Integro ले विकास प्रक्रियाहरूको शीर्ष-स्तर स्वचालनमा केन्द्रित छ। Bitbucket मा सम्बन्धित स्रोत कोड को प्रशोधन संग Jira मा मुद्दाहरु संग काम संयोजन गर्न आवश्यक थियो। यस चरणमा, Integro विभिन्न प्रकारका कार्यहरूसँग काम गर्नका लागि आफ्नै कार्यप्रवाहहरू हुन थाल्यो। 

व्यापार प्रक्रियाहरूमा स्वचालनमा भएको बृद्धिको कारण, टीमसिटीमा परियोजनाहरू र रनहरूको संख्या बढेको छ। त्यसैले एउटा नयाँ समस्या आयो: एउटा नि:शुल्क Teamcity उदाहरण पर्याप्त थिएन (3 एजेन्ट र 100 परियोजनाहरू), हामीले अर्को उदाहरण थप्यौं (3 थप एजेन्टहरू र 100 परियोजनाहरू), त्यसपछि अर्को। नतिजाको रूपमा, हामीले धेरै क्लस्टरहरूको प्रणालीको साथ समाप्त गर्यौं, जुन व्यवस्थापन गर्न गाह्रो थियो:

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

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

हामी परीक्षण स्वचालित गर्छौं

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

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

स्वचालन टोली

हामीसँग हाल 130 विकासकर्ताहरूको कर्मचारी छ, र हामी जारी राख्छौं बढ्नु। निरन्तर एकीकरण र कोड डेलिभरीको लागि टोली (यसपछि डिप्लोय एण्ड इन्टिग्रेशन वा DI टोली भनिन्छ) 7 व्यक्तिहरू समावेश गर्दछ र 2 दिशाहरूमा काम गर्दछ: Integro स्वचालन प्लेटफर्म र DevOps को विकास। 

DevOps CIAN साइट, Integro वातावरणको Dev/Beta वातावरणको लागि जिम्मेवार छ, जसले विकासकर्ताहरूलाई समस्या समाधान गर्न र स्केलिंग वातावरणहरूमा नयाँ दृष्टिकोणहरू विकास गर्न मद्दत गर्दछ। Integro विकास दिशाले Integro आफैं र सम्बन्धित सेवाहरू, उदाहरणका लागि, जेनकिन्स, जिरा, कन्फ्लुएन्सका लागि प्लगइनहरू, र विकास टोलीहरूको लागि सहायक उपयोगिताहरू र अनुप्रयोगहरू पनि विकास गर्दछ। 

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

CIAN मा स्वचालन को तह केक

स्वचालनमा संलग्न सबै प्रणालीहरूलाई धेरै तहहरूमा विभाजन गर्न सकिन्छ:

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

यस अवधारणाको आधारमा, हामी DI टोली भित्र जिम्मेवारीका क्षेत्रहरू विभाजन गर्छौं। पहिलो दुई तहहरू Integro विकास दिशाको जिम्मेवारीको क्षेत्रमा छन्, र अन्तिम दुई स्तरहरू पहिले नै DevOps को जिम्मेवारीको क्षेत्रमा छन्। यो विभाजनले हामीलाई कार्यहरूमा ध्यान केन्द्रित गर्न अनुमति दिन्छ र अन्तरक्रियामा हस्तक्षेप गर्दैन, किनकि हामी एकअर्काको नजिक छौं र निरन्तर ज्ञान र अनुभव आदानप्रदान गर्दछौं।

अक्षुण्ण

Integro मा फोकस गरौं र टेक्नोलोजी स्ट्याकको साथ सुरु गरौं:

• CentOS 7
• Docker + Nomad + Consul + Vault
• Java 11 (पुरानो Integro monolith Java 8 मा रहनेछ)
• Spring Boot 2.X + Spring Cloud कन्फिग
• PostgreSql 11
• खरगोश MQ 
• अपाचे प्रज्वलित
• क्यामुन्डा (इम्बेडेड)
• Grafana + Graphite + Prometheus + Jaeger + ELK
• वेब UI: प्रतिक्रिया (CSR) + MobX
• SSO: कीक्लोक

हामी माइक्रोसर्भिस डेभलपमेन्टको सिद्धान्त पालन गर्छौं, यद्यपि हामीसँग Integro को प्रारम्भिक संस्करणको मोनोलिथको रूपमा विरासत छ। प्रत्येक माइक्रोसेवा आफ्नै डकर कन्टेनरमा चल्छ, र सेवाहरूले HTTP अनुरोधहरू र RabbitMQ सन्देशहरू मार्फत एकअर्कासँग सञ्चार गर्छन्। माइक्रोसर्भिसेसहरूले कन्सुल मार्फत एकअर्कालाई फेला पार्छन् र SSO (Keycloak, OAuth 2/OpenID Connect) मार्फत प्राधिकरण पास गर्दै त्यसलाई अनुरोध गर्छन्।

वास्तविक जीवनको उदाहरणको रूपमा, जेनकिन्ससँग अन्तरक्रिया गर्ने विचार गर्नुहोस्, जसमा निम्न चरणहरू छन्:

1. कार्यप्रवाह व्यवस्थापन माइक्रोसर्भिस (यसपछि फ्लो माइक्रोसर्भिस भनिन्छ) जेनकिन्समा निर्माण चलाउन चाहन्छ। यो गर्नका लागि, उसले जेनकिन्स (यसपछि जेनकिन्स माइक्रोसर्भिस भनेर चिनिन्छ) को लागि माइक्रोसर्भिसको IP:PORT फेला पार्न कन्सुल प्रयोग गर्दछ र यसलाई जेनकिन्समा निर्माण सुरु गर्न एसिन्क्रोनस अनुरोध पठाउँदछ।
2. अनुरोध प्राप्त गरेपछि, जेनकिन्स माइक्रोसर्भिसले कामको ID मार्फत जवाफ दिन्छ, जुन कामको नतिजा पहिचान गर्न प्रयोग गर्न सकिन्छ। एकै समयमा, यसले REST API कल मार्फत जेनकिन्समा निर्माणलाई ट्रिगर गर्दछ।
3. जेनकिन्सले निर्माण कार्य गर्दछ र, पूरा भएपछि, जेनकिन्स माइक्रोसर्भिसलाई कार्यान्वयनको नतिजासहितको वेबहुक पठाउँदछ।
4. जेनकिन्स माइक्रोसर्भिसले वेबहुक प्राप्त गरिसकेपछि, अनुरोध प्रशोधन पूरा भएको बारे सन्देश उत्पन्न गर्दछ र कार्यान्वयन परिणामहरू संलग्न गर्दछ। उत्पन्न सन्देश RabbitMQ कतारमा पठाइन्छ।
5. RabbitMQ मार्फत, प्रकाशित सन्देश Flow microservice मा पुग्छ, जसले अनुरोध र प्राप्त सन्देशबाट Job ID लाई मिलाएर आफ्नो कार्य प्रशोधन गर्ने नतिजाको बारेमा जान्दछ।

अब हामीसँग लगभग 30 माइक्रो सेवाहरू छन्, जसलाई धेरै समूहहरूमा विभाजन गर्न सकिन्छ:

1. कन्फिगरेसन व्यवस्थापन।
2. प्रयोगकर्ताहरूसँग जानकारी र अन्तरक्रिया (मेसेन्जर, मेल)।
3. स्रोत कोडसँग काम गर्दै।
4. परिनियोजन उपकरणहरू (जेनकिन्स, घुमन्ते, कन्सुल, आदि) संग एकीकरण।
5. अनुगमन (रिलिज, त्रुटि, आदि)।
6. वेब उपयोगिताहरू (परीक्षण वातावरणहरू प्रबन्ध गर्न, तथ्याङ्क सङ्कलन, इत्यादिको लागि UI)।
7. टास्क ट्र्याकरहरू र समान प्रणालीहरूसँग एकीकरण।
8. विभिन्न कार्यहरूको लागि कार्यप्रवाह व्यवस्थापन।

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

Integro ले कार्य जीवनचक्रसँग सम्बन्धित गतिविधिहरूलाई स्वचालित बनाउँछ। सरल शब्दहरूमा, कार्यको जीवन चक्रलाई जिरामा कार्यको कार्यप्रवाहको रूपमा बुझिनेछ। हाम्रो विकास प्रक्रियाहरूमा परियोजना, कार्यको प्रकार र विशेष कार्यमा चयन गरिएका विकल्पहरूमा निर्भर गर्दै धेरै कार्यप्रवाह भिन्नताहरू छन्। 

हामी प्रायः प्रयोग गर्ने कार्यप्रवाहलाई हेरौं:

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

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

त्यहाँ अन्य संक्रमण संयोजन हुन सक्छ। कहिलेकाहीँ कुनै मुद्दा लिने बाटो जिरामा विकल्पहरू मार्फत चयन गर्न सकिन्छ।

कार्य आन्दोलन

"DEV Testing + Canary Tests" कार्यप्रवाह मार्फत कार्य सर्दा प्रदर्शन हुने मुख्य चरणहरू हेरौं:

1. विकासकर्ता वा PM ले कार्य सिर्जना गर्दछ।

2. विकासकर्ताले कार्यलाई काम गर्न लगाउँछ। पूरा भएपछि, यो समीक्षा स्थितिमा स्विच हुन्छ।

3. जिराले जिरा माइक्रोसर्भिस (जिरासँग एकीकरणको लागि जिम्मेवार) मा वेबहुक पठाउँछ।

4. जिरा माइक्रोसर्भिसले कार्यप्रवाह सुरु गर्न फ्लो सेवा (आन्तरिक कार्यप्रवाहहरूको लागि जिम्मेवार) लाई कार्यप्रवाह सुरु गर्न अनुरोध पठाउँछ।

5. प्रवाह सेवा भित्र:

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

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

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

6. परीक्षकहरूले कार्यको परीक्षण गर्छन्। यदि त्यहाँ कुनै समस्याहरू छैनन् भने, कार्यलाई निर्माण स्थितिको लागि तयारमा हस्तान्तरण गरिएको छ।

7. Integro "हेर्छ" कि कार्य रिलीजको लागि तयार छ र क्यानरी मोड (Jenkins microservice) मा यसको तैनाती सुरु हुन्छ। रिलिजको लागि तयारी नियमहरूको सेट द्वारा निर्धारण गरिन्छ। उदाहरणका लागि, कार्य आवश्यक स्थितिमा छ, अन्य कार्यहरूमा कुनै लकहरू छैनन्, त्यहाँ हाल यो माइक्रोसेवाको कुनै सक्रिय अपलोडहरू छैनन्, आदि।

8. कार्य क्यानरी स्थिति (Jira microservice) मा हस्तान्तरण गरिएको छ।

9. जेनकिन्सले क्यानरी मोड (सामान्यतया 1-3 उदाहरणहरू) मा Nomad मार्फत डिप्लोइमेन्ट कार्य सुरु गर्छ र डिप्लोइमेन्टको बारेमा रिलीज निगरानी सेवा (DeployWatch microservice) लाई सूचित गर्दछ।

10. DeployWatch microservice ले त्रुटि पृष्ठभूमि सङ्कलन गर्छ र आवश्यक भएमा त्यसमा प्रतिक्रिया दिन्छ। यदि त्रुटि पृष्ठभूमि नाघ्यो (पृष्ठभूमि मानक स्वचालित रूपमा गणना गरिन्छ), विकासकर्ताहरूलाई सूचना माइक्रोसेवा मार्फत सूचित गरिन्छ। यदि 5 मिनेट पछि विकासकर्ताले प्रतिक्रिया दिएको छैन (उल्टाउनुहोस् वा रहनुहोस् क्लिक गर्नुहोस्), त्यसपछि क्यानरी उदाहरणहरूको स्वचालित रोलब्याक सुरु हुन्छ। यदि पृष्ठभूमि नाघेको छैन भने, त्यसपछि विकासकर्ताले म्यानुअल रूपमा उत्पादनमा टास्क डिप्लोइमेन्ट सुरु गर्नुपर्छ (UI मा बटन क्लिक गरेर)। यदि विकासकर्ताले ६० मिनेट भित्र उत्पादनमा डिप्लोइमेन्ट सुरु गरेन भने, क्यानरी उदाहरणहरू पनि सुरक्षा कारणहरूका लागि फिर्ता हुनेछन्।

11. उत्पादनमा तैनाती सुरु गरेपछि:

• कार्य उत्पादन स्थिति (Jira microservice) मा हस्तान्तरण गरिएको छ।
• जेन्किन्स माइक्रोसर्भिसले डिप्लोइमेन्ट प्रक्रिया सुरु गर्छ र डिप्लोयमेन्टको बारेमा डिप्लोयवाच माइक्रोसर्भिसलाई सूचित गर्छ।
• DeployWatch माइक्रोसर्भिसले उत्पादनमा भएका सबै कन्टेनरहरू अद्यावधिक गरिएका छन् भनी जाँच गर्दछ (त्यहाँ घटनाहरू थिए जब सबै अद्यावधिक गरिएको थिएन)।
• अधिसूचना माइक्रोसर्भिस मार्फत, डिप्लोइमेन्टको नतिजाको बारेमा एक सूचना उत्पादनमा पठाइन्छ।

12. यदि गलत माइक्रोसेवा व्यवहार पत्ता लाग्यो भने विकासकर्ताहरूसँग उत्पादनबाट कार्य रोल ब्याक गर्न सुरु गर्न 30 मिनेट हुनेछ। यस समय पछि, कार्य स्वतः मास्टर (Git microservice) मा मर्ज हुनेछ।

13. मास्टर मा सफल मर्ज पछि, कार्य स्थिति बन्द (Jira microservice) मा परिवर्तन हुनेछ।

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

अब के

हामीसँग स्वचालनको विकासका लागि ठूला योजनाहरू छन्, उदाहरणका लागि, मोनोलिथ रिलीजको समयमा म्यानुअल अपरेशनहरू हटाउने, स्वचालित डिप्लोइमेन्टको समयमा अनुगमन सुधार गर्ने, र विकासकर्ताहरूसँग अन्तरक्रिया सुधार गर्ने।

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

स्रोत: www.habr.com