लिपियों से लेकर हमारे अपने मंच: कैसे हम सियान संस्थान में स्वचालित विकास करते हैं

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

स्तर शून्य

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

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

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



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

हमें अपने सिस्टम का आइडिया आता है

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

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

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



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

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

स्वचालित परीक्षण

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

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

स्वचालन टीम

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

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

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

सियान में पफ पाई स्वचालन

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

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

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

integro

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

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

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



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

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

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

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

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

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

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



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

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



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

टास्क आंदोलन

"DEV + कैनरी परीक्षण के लिए परीक्षण" वर्कफ़्लो पर कार्य करते समय किए जाने वाले मूल चरणों पर विचार करें:

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

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

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

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

5. फ्लो सेवा के अंदर:

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

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

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

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

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

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

11. उत्पादन के लिए तैनाती शुरू करने के बाद:

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

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

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

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

आगे क्या है

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

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