एंटरप्राइज देवोप्सेस: कैसे एक बड़ी कंपनी माइक्रोसर्विसेज इकट्ठा करती है

सभी को नमस्कार!

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

पहले, उत्पाद मोनोलिथिक थे, लेकिन अब हम आत्मविश्वास से माइक्रोसिस्टवर्क एप्लिकेशन की ओर बढ़ रहे हैं। DevOps को इस तकनीकी छलांग प्रदान करने के लिए एक महत्वाकांक्षी कार्य का सामना करना पड़ा -।

नतीजतन, हमें एक सफल विधानसभा अवधारणा मिली, जिसे हम एक सर्वोत्तम अभ्यास के रूप में साझा करना चाहते हैं। तकनीकी विवरणों के साथ कार्यान्वयन का विवरण काफी बड़ा होगा, हम इस लेख के ढांचे के भीतर ऐसा नहीं करेंगे।

सामान्य मामले में, विधानसभा कुछ कलाकृतियों का दूसरों में रूपांतरण है।

किसकी दिलचस्पी होगी

वे कंपनियां जो पूरी तरह से तृतीय-पक्ष संगठन के लिए तैयार किए गए सॉफ़्टवेयर की आपूर्ति करती हैं और इसके लिए भुगतान करती हैं।

यहां बाहरी वितरण के बिना विकास कैसा दिख सकता है:

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

यदि आप बाहरी आपूर्ति के साथ सामना नहीं कर रहे हैं, तो नीचे जो लिखा गया है, वह बहुत अधिक बेमानी या यहां तक ​​कि पागल भी लगेगा।

व्यवहार में, लाइसेंस और एन्क्रिप्शन के लिए अंतरराष्ट्रीय आवश्यकताओं के अनुपालन में सब कुछ किया जाना चाहिए, अन्यथा कम से कम कानूनी परिणाम उत्पन्न होंगे।

उल्लंघन का एक उदाहरण एक GPL3 लाइसेंस के साथ एक पुस्तकालय से कोड लेना और इसे एक व्यावसायिक अनुप्रयोग में एम्बेड करना है।

माइक्रोसर्विसेज के उद्भव के लिए बदलाव की आवश्यकता है

हमें विधानसभा और अखंड अनुप्रयोगों के वितरण में व्यापक अनुभव प्राप्त हुआ है।

कई जेनकिंस सर्वर, हजारों CI जॉब, जेनकिंस पर आधारित कई पूरी तरह से स्वचालित असेंबली लाइन, दर्जनों समर्पित रिलीज इंजीनियर, कॉन्फ़िगरेशन प्रबंधन पर अपने स्वयं के विशेषज्ञ समूह।

ऐतिहासिक रूप से, कंपनी में दृष्टिकोण यह था: डेवलपर्स स्रोत कोड लिखते हैं, और देवओप्स विधानसभा प्रणाली के कॉन्फ़िगरेशन का आविष्कार और लिखते हैं।

नतीजतन, हमारे पास कॉर्पोरेट पारिस्थितिकी तंत्र में ऑपरेशन के लिए डिज़ाइन किए गए दो या तीन विशिष्ट विधानसभा कॉन्फ़िगरेशन थे। योजनाबद्ध रूप से, यह इस तरह दिखता है:

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

सूक्ष्मजीव विभिन्न अनुप्रयोगों में मुख्य रूप से विभिन्न अनुप्रयोगों से भिन्न होते हैं।

यह कम से कम प्रत्येक प्रोग्रामिंग भाषा के लिए बहुत सारे असेंबली कॉन्फ़िगरेशन का पता लगाता है। केंद्रीकृत नियंत्रण असंभव हो जाता है।

यथासंभव विधानसभा स्क्रिप्ट को सरल बनाने और डेवलपर्स को स्वतंत्र रूप से संपादित करने के लिए सक्षम करना आवश्यक है।

सरल संकलन और पैकेजिंग ( हरे रंग में आरेख में) के अलावा, इन लिपियों में कॉर्पोरेट पारिस्थितिकी तंत्र ( लाल रंग में आरेख) के साथ एकीकरण के लिए बहुत सारे कोड हैं।

इसलिए, विधानसभा को "ब्लैक बॉक्स" के रूप में देखने का निर्णय लिया गया, जिसमें एक "स्मार्ट" विधानसभा वातावरण सभी समस्याओं को हल कर सकता है, केवल संकलन और पैकेजिंग के अलावा।

काम की शुरुआत में यह स्पष्ट नहीं था कि ऐसी प्रणाली कैसे प्राप्त की जाए। DevOps कार्यों के लिए वास्तु निर्णय लेने के लिए अनुभव और ज्ञान की आवश्यकता होती है। उन्हें कैसे प्राप्त करें? संभावित विकल्प नीचे हैं:

• इंटरनेट पर जानकारी के लिए खोजें।
• खुद का अनुभव और देवओप्स टीम का ज्ञान। ऐसा करने के लिए, प्रोग्रामर की इस टीम को बहुमुखी अनुभव के साथ बनाना अच्छा है।
• अनुभव और ज्ञान DevOps टीम के बाहर प्राप्त किया। कंपनी के कई डेवलपर्स के पास अच्छे विचार हैं - आपको उन्हें सुनने की जरूरत है। संचार सहायक है।
• हम आविष्कार करते हैं और प्रयोग करते हैं!

क्या मुझे स्वचालन की आवश्यकता है?

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

1. अचेतन स्तर
   
   
   
   

   हमें प्रति सप्ताह एक विधानसभा जारी करने की आवश्यकता है, हमारे लोग ठीक कर रहे हैं। यह स्वाभाविक है, इसके बारे में बात क्यों करें?

2. "कारीगर" का स्तर, अंततः "डोजर" के स्तर में परिवर्तित हो रहा है
   
   
   
   

   प्रति दिन दो विधानसभाओं का उत्पादन आवश्यक रूप से और त्रुटियों के बिना करना आवश्यक है। हमारे पास वासा है, वह इसे ठंडा करता है, और कोई भी उसे इस समय खर्च नहीं करता है।

3. कारख़ाना स्तर
   
   
   
   

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

   
   

   इस स्तर पर, कार्य को ठोस निष्पादक से अलग किया जाता है और इस तरह यह एक प्रक्रिया में बदल जाता है।

   
   

   परिणाम एक स्पष्ट, काम किया, रन-इन और पाठ के साथ प्रक्रिया के सैकड़ों बार वर्णन को सही करेगा।

4. "स्वचालित उत्पादन" का स्तर
   
   
   
   

   असेंबलियों के लिए आधुनिक आवश्यकताएं बढ़ रही हैं: सब कुछ तेज, विश्वसनीय होना चाहिए, प्रति दिन 800 असेंबली प्रदान की जानी चाहिए। यह महत्वपूर्ण है, क्योंकि ऐसे संस्करणों के बिना कंपनी प्रतिस्पर्धी लाभ खो देगी।

   
   

   महंगा स्वचालन हो रहा है, और योग्य DevOps के एक जोड़े को चालू रख सकते हैं। आगे स्केलिंग अब एक समस्या नहीं है।

प्रत्येक कार्य स्वचालन के अंतिम चरण तक नहीं पहुंचना चाहिए।

अक्सर कमांड लाइन के साथ एक शिल्पकार आसानी से और प्रभावी ढंग से समस्याओं को हल करेगा।

स्वचालन प्रक्रिया को "जमा देता है", ऑपरेशन की लागत को कम करता है और परिवर्तन की लागत को बढ़ाता है।

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

विधानसभाएं क्या हैं और तैयार विधानसभा प्रणाली द्वारा समस्या का समाधान क्यों नहीं किया जाता है

हम विधानसभा एकत्रीकरण स्तरों को निर्धारित करने के लिए निम्न वर्गीकरण का उपयोग करते हैं।

• एल 1। एक बड़े आवेदन का एक छोटा स्वतंत्र हिस्सा। यह एक घटक, माइक्रोसिस्ट सेवा या एक सहायक पुस्तकालय हो सकता है। एल 1 विधानसभा रैखिक तकनीकी समस्याओं का एक समाधान है: संकलन, पैकेजिंग, निर्भरता के साथ काम करना। Maven, gradle, npm, grunt और अन्य बिल्ड सिस्टम इसका बहुत अच्छा काम करते हैं। उनमें से सैकड़ों हैं।

  L1 असेंबली को तैयार-किए गए तृतीय-पक्ष टूल का उपयोग करके किया जाना चाहिए।

• L2 +। एकीकरण की इकाइयाँ। L1 इकाइयाँ बड़े संरचनाओं में संयोजित होती हैं, उदाहरण के लिए, पूर्ण-सूक्ष्मदर्शी अनुप्रयोगों में। इनमें से कई अनुप्रयोगों को एकल समाधान के रूप में बंडल किया जा सकता है। हम "+" संकेत का उपयोग करते हैं, क्योंकि विधानसभा एकत्रीकरण के स्तर के आधार पर, L3 या L4 के स्तर को भी असाइन किया जा सकता है।

  
  

  तृतीय-पक्ष की दुनिया में ऐसी विधानसभाओं का एक उदाहरण लिनक्स वितरण की तैयारी है। मेटा-पैकेज वहाँ।

  
  

  काफी जटिल तकनीकी कार्यों के अलावा (जैसे कि यह एक: ru.wikipedia.org/wiki/D dependency_hell )। L2 + असेंबली अक्सर अंतिम उत्पाद होते हैं और इसलिए कई प्रक्रिया आवश्यकताएं होती हैं: अधिकारों की एक प्रणाली, जिम्मेदार लोगों को ठीक करना, कानूनी त्रुटियों की अनुपस्थिति, विभिन्न प्रलेखन की आपूर्ति।

  
  

  L2 + में, स्वचालन द्वारा प्रक्रिया की आवश्यकताओं को प्राथमिकता दी जाती है।

  
  

  यदि स्वचालित समाधान काम नहीं करता है क्योंकि यह इच्छुक लोगों के लिए सुविधाजनक है, तो इसे लागू नहीं किया जाएगा।

  
  

  L2 + विधानसभाओं को विशेष रूप से कंपनी की प्रक्रियाओं के अनुरूप एक मालिकाना उपकरण द्वारा प्रदर्शन किया जाएगा। क्या आपको लगता है कि लिनक्स पैकेज मैनेजर सिर्फ उसी के साथ आते हैं?

हमारी सबसे अच्छी प्रैक्टिस

आधारभूत संरचना

लोहे की स्थायी उपलब्धता

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

स्वराज्य

सभी CI प्रक्रियाओं में, इंटरनेट उपलब्ध नहीं है। सभी आवश्यक संसाधनों को आंतरिक रूप से प्रतिबिंबित और कैश किया गया है। आंशिक रूप से भी github.com (धन्यवाद, npm!) इन मुद्दों में से अधिकांश आर्टिफैक्ट द्वारा हल किए गए हैं।

इसलिए, मावेन सेंट्रल से कलाकृतियों को हटाने या लोकप्रिय रिपॉजिटरी को बंद करने पर हम शांत हैं। एक उदाहरण है: Community.oracle.com/community/java/javanet-forge-sunset ।

मिररिंग से विधानसभा का समय काफी कम हो जाता है, कॉर्पोरेट इंटरनेट चैनल मुक्त हो जाता है। कम महत्वपूर्ण नेटवर्क संसाधन निर्माण स्थिरता को बढ़ाते हैं।

प्रत्येक प्रकार की कलाकृतियों के लिए तीन रिपोजिटरी

1. देव एक भंडार है जहां कोई भी किसी भी मूल की कलाकृतियों को प्रकाशित कर सकता है। यहां आप पहले ही दिन से कॉर्पोरेट मानकों के पालन के बिना मौलिक रूप से नए दृष्टिकोणों के साथ प्रयोग कर सकते हैं।
2. स्टेजिंग केवल एक विधानसभा पाइपलाइन के साथ एक रिपोजिटरी आबादी है।
3. रिलीज - एकल विधानसभाएं, बाहरी वितरण के लिए तैयार। यह मैनुअल पुष्टिकरण के साथ एक विशेष हस्तांतरण ऑपरेशन से भरा है।

30 दिन का नियम

देव- और स्टेजिंग-रिपॉजिटरी से हम 30 दिनों से अधिक पुरानी सब कुछ हटा देते हैं। यह सुनिश्चित करने में मदद करता है कि सभी के पास सर्वर डिस्क स्थान की एक सीमित राशि खर्च करके समान प्रकाशन अवसर हों।

रिलीज को हमेशा के लिए संग्रहीत किया जाता है, यदि आवश्यक हो तो संग्रह किया जाता है।

विधानसभा का स्वच्छ वातावरण

अक्सर असेंबली के बाद, सहायक फाइलें सिस्टम में रहती हैं, जो अन्य विधानसभा प्रक्रियाओं को प्रभावित कर सकती हैं। विशिष्ट उदाहरण:

• सबसे आम समस्या एक गलत असेंबली द्वारा क्षतिग्रस्त कैश है (कैसे नीचे वर्णित कैश से निपटने के लिए);
• कुछ उपयोगिताओं, जैसे कि npm, $ घर निर्देशिका में सेवा फाइलें छोड़ती हैं जो इन उपयोगिताओं के सभी बाद के लॉन्च को प्रभावित करती हैं;
• एक विशेष असेंबली कुछ / tmp विभाजन में सभी डिस्क स्थान खर्च कर सकती है, जिससे पर्यावरण की सामान्य अनुपलब्धता हो जाएगी।

इसलिए, डॉकटर कंटेनरों के पक्ष में एकीकृत वातावरण को छोड़ना बेहतर है। कंटेनर में निश्चित संस्करणों के साथ विशिष्ट असेंबली के लिए केवल आवश्यक सॉफ़्टवेयर होना चाहिए।

DevOps असेंबली डॉकटर छवियों का एक संग्रह रखता है, जिसे लगातार अपडेट किया जाता है। पहले लगभग छह थे, फिर यह 30 साल से कम था, फिर हमने सॉफ्टवेयर सूची से स्वचालित छवि निर्माण की स्थापना की। अब आवश्यकता ('मावेन 3.3.9', 'अजगर') जैसी आवश्यकताओं को निर्दिष्ट करें - और पर्यावरण तैयार है।

आत्म निदान

यह केवल अनुरोधों के लिए उपयोगकर्ता सहायता को व्यवस्थित करने के लिए आवश्यक नहीं है, हमें स्वयं अपने सिस्टम के व्यवहार का विश्लेषण करना चाहिए। हम लगातार लॉग एकत्रित करते हैं, उनमे समस्याएँ दिखाने वाले कीवर्ड्स को देखते हैं।

"लाइव" प्रणाली पर, यह 20-30 नियमित अभिव्यक्ति लिखने के लिए पर्याप्त है ताकि प्रत्येक विधानसभा के लिए आप इसके स्तर पर गिरावट का कारण बता सकें:

• गिट सर्वर दुर्घटना
• डिस्क स्थान वहाँ से बाहर चला गया है;
• डेवलपर की गलती के कारण त्रुटि का निर्माण;
• डॉकटर में ज्ञात बग।

अगर कुछ गिर गया है, लेकिन एक भी ज्ञात समस्या का पता नहीं चला है, तो यह मास्क के संग्रह को फिर से भरने का एक अवसर है।

फिर हम उपयोगकर्ता के पास जाते हैं और कहते हैं कि उसके पास एक बिल्ड है और इसे इस तरह से तय किया जा सकता है।

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

हम ध्यान से चुनते हैं कि विधानसभा किन प्रणालियों पर निर्भर करती है

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

असेंबली लाइन इंटरफ़ेस

कॉलिंग असेंबली के लिए एकल इंटरफ़ेस

हम किसी भी प्रणाली के साथ किसी भी तरह की असेंबली बनाते हैं। सभी स्तरों (L1, L2 +) की असेंबलियों को प्रोग्राम कोड द्वारा वर्णित किया जाता है और एक जेनकींस नौकरी के माध्यम से बुलाया जाता है।

हालांकि, यह दृष्टिकोण आदर्श नहीं है। जेनकिंस जॉब ऑटो-पीढ़ी तंत्र का उपयोग करना बेहतर है: उदाहरण के लिए, 1 नौकरी = 1 गिट रिपॉजिटरी या 1 नौकरी = 1 गिट शाखा। यह निम्नलिखित प्राप्त करेगा:

• विषम विधानसभाओं से लॉग जेनकींस नौकरी पृष्ठ पर एक कहानी में भ्रमित नहीं हैं;
• वास्तव में, आपको टीम के लिए या डेवलपर के लिए आरामदायक आवंटित नौकरियां मिलती हैं; कनिष्ठ, कोबेरटुरा, सोनार के परिणामों के चार्ट को समायोजित करके आराम की भावना को बढ़ाया जा सकता है।

प्रौद्योगिकी का चयन करने की स्वतंत्रता

बिल्ड शुरू करना बैश स्क्रिप्ट "./build.sh" के लिए एक कॉल है। और फिर - कोई भी असेंबली सिस्टम, प्रोग्रामिंग लैंग्वेज और बाकी सभी चीजें जो एक व्यावसायिक कार्य को पूरा करने के लिए आवश्यक होंगी। यह ब्लैक बॉक्स के रूप में असेंबली के लिए एक दृष्टिकोण प्रदान करता है।

स्मार्ट पोस्ट

असेंबली लाइन ब्लैक बॉक्स से प्रकाशनों को स्वीकार करती है और उन्हें पहले से ही कॉर्पोरेट भंडारण में डालती है। इसके लिए, डॉकिंग इमेज नाम तैयार करने और प्रकाशन के लिए सही रिपॉजिटरी चुनने जैसे उबाऊ मुद्दे स्वतः हल हो जाते हैं।

स्टेजिंग और रिलीज रिपॉजिटरी में हमेशा ऑर्डर होता है। विभिन्न प्रकार के प्रकाशनों की बारीकियों का समर्थन करना आवश्यक है: मावेन, एनपीएम, फ़ाइल, डॉकटर।

विधानसभा विवरणक

Build.sh बताता है कि कोड को कैसे संकलित किया जाए, लेकिन यह असेंबली कंटेनर के लिए पर्याप्त नहीं है।

आपको यह भी पता होना चाहिए:

1. क्या विधानसभा वातावरण का उपयोग करने के लिए;
2. build.sh में उपलब्ध पर्यावरण चर;
3. क्या प्रकाशन किया जाएगा;
4. अन्य विशिष्ट विकल्प।

हमने इस जानकारी का वर्णन करने के लिए एक सुविधाजनक तरीका चुना है जो दूरस्थ रूप से एक यम-फाइल के रूप में है। इसे .itlab-ci.yaml के नाम से जाना जाता है।

असेंबली पैरामीटर

असेंबली के प्रारंभ में git कमिट कमांड को निष्पादित किए बिना उपयोगकर्ता मनमाना मापदंडों को निर्दिष्ट कर सकता है।

हमने इसे जेनकिंस जॉब इंटरफेस से सीधे पर्यावरण चर को परिभाषित करके लागू किया है।

उदाहरण के लिए, हम निर्भर लाइब्रेरी के संस्करण को ऐसे असेंबली पैरामीटर में स्थानांतरित करते हैं और, कुछ मामलों में, इस संस्करण को कुछ प्रयोगात्मक के लिए फिर से परिभाषित करते हैं। इस तरह के तंत्र के बिना, उपयोगकर्ता को हर बार "गिट कमिट" कमांड को निष्पादित करना होगा।

सिस्टम पोर्टेबिलिटी

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

एक कलाकृतियों को विभिन्न नामों से प्रकाशित किया जा सकता है।

प्रकाशन के लिए दो विरोधी आवश्यकताएं हैं जो एक साथ उत्पन्न हो सकती हैं।

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

दूसरी ओर, कभी-कभी नवीनतम जैसे निश्चित नाम के साथ एक वास्तविक कलाकृतियों का होना सुविधाजनक होता है। उदाहरण के लिए, डेवलपर को हर बार निर्भरता के सटीक संस्करण को जानने की आवश्यकता नहीं है, आप बस नवीनतम के साथ काम कर सकते हैं।

इस मामले में कलाकृतियों को दो या अधिक नामों के तहत प्रकाशित किया जाता है, क्योंकि यह सभी के लिए उपयुक्त है।

उदाहरण के लिए:

1. समय टिकट या यूयूआईडी के साथ एक अद्वितीय नाम - उन लोगों के लिए जिन्हें सटीकता की आवश्यकता है;
2. नाम "नवीनतम" - उनके डेवलपर्स के लिए, जो हमेशा नवीनतम कोड उठाते हैं;
3. नाम "<प्रमुख संस्करण> .x-नवीनतम" एक पड़ोसी टीम के लिए है जो नवीनतम संस्करणों को लेने के लिए तैयार है, लेकिन केवल एक निश्चित प्रमुख के ढांचे के भीतर।

मावेन SNAPSHOT के लिए अपने दृष्टिकोण में कुछ ऐसा ही करता है।

कम सुरक्षा प्रतिबंध

हर कोई विधानसभा शुरू कर सकता है। यह किसी को नुकसान नहीं पहुंचाएगा, क्योंकि विधानसभा केवल कलाकृतियों का निर्माण करती है।

कानूनी अनुपालन

विधानसभा प्रक्रिया की बाहरी बातचीत का नियंत्रण

असेंबली अपने काम की प्रक्रिया में निषिद्ध कुछ भी उपयोग नहीं कर सकती है।

इसके लिए, नेटवर्क ट्रैफ़िक की रिकॉर्डिंग और फ़ाइल कैश तक पहुँच को लागू किया जाता है। हमें प्राप्त डेटा के sha256 हैश के साथ एक यूआरएल सूची के रूप में विधानसभा की नेटवर्क गतिविधि का लॉग मिलता है। इसके अलावा, प्रत्येक url को मान्य किया गया है:

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

प्रकाशित कलाकृतियों की पारदर्शी सामग्री

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

जारी स्रोत कोड को जीआईटी से हटाया नहीं जा सकता है

कभी-कभी आपको दो साल पहले संकलित बाइनरी कलाकृतियों को देखकर स्रोत कोड खोजने की आवश्यकता हो सकती है। ऐसा करने के लिए, बाहरी आउटपुट के साथ स्वचालित रूप से Git में टैग आवंटित करना आवश्यक है, साथ ही उनके निष्कासन को भी रोकना चाहिए।

रसद और लेखा

सभी विधानसभाओं को डेटाबेस में संग्रहीत किया जाता है।

हम इन उद्देश्यों के लिए Artifactory में फाइल रिपॉजिटरी का उपयोग करते हैं। इसमें सभी सहायक जानकारी शामिल है: किसने इसे लॉन्च किया, चेक के परिणाम क्या थे, कौन सी कलाकृतियों को प्रकाशित किया गया था, कौन से हैश का उपयोग किया गया था, आदि।

हम जानते हैं कि विधानसभा को यथासंभव सटीक रूप से कैसे पुन: पेश किया जाए

विधानसभा के परिणामों के अनुसार, हम निम्नलिखित जानकारी संग्रहीत करते हैं:

• जो कोड एकत्र किया गया था, उसकी सटीक स्थिति;
• प्रक्षेपण किन मापदंडों के साथ किया गया था;
• क्या आदेश कहा जाता था;
• बाहरी संसाधनों तक पहुँच क्या हुई;
• विधानसभा वातावरण का इस्तेमाल किया।

यदि आवश्यक हो, तो हम इस सवाल का सटीक उत्तर दे सकते हैं कि यह कैसे इकट्ठा किया गया था।

JIRA टिकट के साथ विधानसभा का दो तरफा संचार

निम्नलिखित समस्याओं को हल करने में सक्षम होना सुनिश्चित करें:

1. विधानसभा के लिए, इसमें शामिल JIRA टिकटों की एक सूची बनाएं;
2. JIRA टिकट में लिखें कि यह किस विधानसभा में शामिल है।

विधानसभा और गिट प्रतिबद्ध के बीच एक तंग दो-तरफ़ा संचार प्रदान किया जाता है। और फिर टिप्पणियों के पाठ से आप पहले से ही JIRA के सभी लिंक के बारे में पता लगा सकते हैं।

गति

विधानसभा प्रणाली कैश

मावेन कैश की अनुपस्थिति बिल्ड टाइम को एक घंटे तक बढ़ा सकती है।

कैश विधानसभा वातावरण के अलगाव और विधानसभा की सफाई का उल्लंघन करता है। प्रत्येक कैश्ड कलाकृतियों के लिए इसकी उत्पत्ति का निर्धारण करके इस समस्या को हल किया जा सकता है। हमारे पास https लिंक से जुड़ी प्रत्येक कैश फ़ाइल है जिसमें से इसे एक बार डाउनलोड किया गया था। इसके अलावा हम नेटवर्क एड्रेस के रूप में कैश को पढ़ने की प्रक्रिया करते हैं।

नेटवर्क संसाधन कैश

कंपनी की भौगोलिक वृद्धि से महाद्वीपों के बीच 300 एमबी की फ़ाइलों को स्थानांतरित करने की आवश्यकता होती है। बहुत समय व्यतीत होता है, खासकर यदि आपको अक्सर ऐसा करना पड़ता है।

Git repositories, असेंबली वातावरण की डॉकटर छवियां, फ़ाइल स्टोरेज - सब कुछ सावधानी से कैश करने की आवश्यकता है। ठीक है, निश्चित रूप से, समय-समय पर साफ।

विधानसभा - जितनी जल्दी हो सके, बाकी सब - फिर

पहला चरण: हम असेंबली करते हैं और तुरंत, अनावश्यक इशारों के बिना, हम परिणाम देते हैं।

दूसरा चरण: सत्यापन, विश्लेषण, लेखांकन और अन्य नौकरशाही। यह पहले से ही एक अलग जेनकींस नौकरी में और सख्त समय सीमा के बिना किया जा सकता है।

परिणाम क्या है?

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

और कुछ संख्या

1. . 15 Jenkins job build.sh. 15 docker-, , . . .
2. . . 2200 . — on-commit-.
3. 300 git-, .
4. 30 , (25 ) — docker.
5. , :
   
   1. glide, golang, promu;
   2. maven, gradle;
   3. python & pip;
   4. ruby;
   5. nodejs & npm;
   6. docker;
   7. rpm build tools & gcc;
   8. Android ADT;
   9. ;
   10. legacy-;
   11. .