हम एक स्क्रिप्ट (वास्तव में नहीं) के साथ devops को बदलना चाहते हैं: डेवलपर्स, आपको अपनी राय चाहिए

हम विकास के लिए एक क्लाउड प्रोजेक्ट बना रहे हैं - एक ऐसा प्लेटफॉर्म जो विकास की प्रक्रिया में शामिल देवों, डेवलपर्स, परीक्षकों, टीम लीडरों और अन्य विशेषज्ञों के लिए जीवन को सरल बना सकता है। यह उत्पाद अभी के लिए नहीं है और कल के लिए नहीं है, और इसके लिए आवश्यकता अभी बनाई जा रही है।

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

ऐसी विकृति कहाँ से आती है? हम एक स्पष्ट प्रवृत्ति देखते हैं कि अब नई परियोजनाओं की तैनाती की गति बाजार को प्रभावित करती है। कॉमर्स इस बात पर निर्भर करता है कि रिलीज कितनी जल्दी डिलीवर होती है। कितनी जल्दी कीड़े तय हो जाएंगे, कितनी जल्दी नए निचे लगे होंगे। 2018 की शुरुआत में, वैश्विक कंपनी "451 रिसर्च" ने एक सर्वेक्षण किया कि कौन सी तकनीकें विकास के लिए प्राथमिकता होगी। शीर्ष दस में कंटेनर निर्माण और प्रबंधन प्रौद्योगिकियां, साथ ही सर्वर रहित एप्लिकेशन आर्किटेक्चर और माइक्रोसर्विसेज शामिल हैं, यहां तक ​​कि ब्लॉकचेन जैसे प्रचार विषय को भी पीछे छोड़ दिया है।

और अब हमारे पास आपके लिए कुछ सवाल हैं।

सर्वेक्षण से चार्ट:

क्या यह आवश्यक है?

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

कंटेनरों का उपयोग करने के कई फायदे हैं:

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

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

कंटेनरों के लाभ इतने आश्वस्त हैं कि आने वाले लंबे समय तक निश्चित रूप से उनका उपयोग किया जाएगा।

बादल का विकास से क्या लेना-देना है?

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

हमारे पास इस तरह से था: कार्यों और एक स्रोत के साथ एक Gitlabchik है। जब आपको कुछ इकट्ठा करने की आवश्यकता होती है - GitLab Runner। हम अलग-अलग शाखाओं पर Git Flow, सभी सुविधाओं पर काम करते हैं। जब एक शाखा रिपॉजिटरी में प्रवेश करती है, तो इस कोड पर परीक्षण गीतालाब में लॉन्च किए जाते हैं। यदि परीक्षण पास हो गए, तो इस थ्रेड के डेवलपर एक मर्ज अनुरोध कर सकते हैं, वास्तव में एक कोड समीक्षा के लिए एक अनुरोध। समीक्षा के बाद, शाखा को स्वीकार किया जाता है, देव-शाखा में विलय कर दिया जाता है, परीक्षण फिर से गुजरता है। तैनात करते समय, गिटलैब रनर डॉकटर कंटेनर को इकट्ठा करता है और इसे स्टेजिंग सर्वर पर ले जाता है, जहां इसे क्लिक किया जा सकता है और आनन्दित किया जा सकता है। और यहां पहला गैग है - हम कार्यात्मक के अनुपालन के लिए अपने हाथों से कोड के माध्यम से देखते हैं और यह पहली चीज है जिसे हम ठीक करते हैं। उसके बाद, हम कोड को रिलीज शाखा में इंजेक्ट करते हैं। और उसके लिए, हम अपने समाधान का एक अलग पूर्व-उत्पादक संस्करण तैयार कर रहे हैं, जिसे हमारे व्यापारिक ग्राहक देख रहे हैं। संस्करण पूर्व-ठेस पर पूर्व-स्थापित होने के बाद, हम इसे उत्पादन में रोल करते हैं और यह उत्पाद नोड्स में रोल करता है। ऑटो-जनरेटेड रिलीज़ नोट्स और बग रिपोर्ट हैं। विधानसभा की गति 30 मिनट से अधिक थी, अब यह कम परिमाण का एक क्रम है। हमने अपने लिए उपकरणों का एक सेट चुना है और अब उसी तैयार सास को बनाने के बारे में सोच रहे हैं।

हमारे लिए, रिलीज़ के लिए विशिष्ट रिलीज़ प्रक्रिया निम्नानुसार है:

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

यहां हमारी प्रक्रिया के विवरण के साथ एक आरेख है:




दरअसल, पहला सवाल - कृपया हमें बताएं कि आप कहां रेक करते हैं और यह स्कीम कितनी सार्वभौमिक है या नहीं। यदि आप एक वर्कफ़्लो का उपयोग करते हैं जो इससे बहुत अलग है, तो कुछ शब्द जोड़ें, ऐसा क्यों, कृपया।

हम किस तरह के उत्पाद की योजना बना रहे हैं?

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

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

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

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

तो यह क्या होगा?

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

• विकास पर्यावरण (विन्यास प्रबंधन प्रणाली, कार्य सेटिंग प्रणाली, भंडारण कोड और कलाकृतियों के लिए भंडार, टास्क ट्रैकर)
• CI - निरंतर एकीकरण (विधानसभा, बुनियादी ढांचे और आर्केस्ट्रा)
• क्यूए - गुणवत्ता आश्वासन (परीक्षण, निगरानी और लॉगिंग)
• मंचन - एकीकरण पर्यावरण / Prerelease लूप
• उत्पादन - उत्पादक सर्किट

उपकरण चुनना, हमने बाजार में सर्वश्रेष्ठ अभ्यास पर ध्यान केंद्रित किया।



हम समानांतर फीचर डस्टिंग के साथ डॉकटर और कुबेरनेट्स का उपयोग करके स्टेज और प्रोडक्शन के साथ बुनियादी ढांचे का निर्माण करेंगे।

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

हम विकास प्रक्रिया की निगरानी और निरंतर वितरण के लिए सेवा पर विशेष ध्यान देने की योजना भी बनाते हैं। हमें इस सेवा से क्या मतलब है? यह संकेतक के साथ एक श्रेणीबद्ध KPI मॉडल बनाने का अवसर है जैसे कि यूनिट परीक्षणों द्वारा% कवरेज, किसी घटना या दोष को खत्म करने का औसत समय, कमिटमेंट से डिलीवरी तक का औसत समय आदि।

विभिन्न प्रणालियों से स्रोत डेटा का संग्रह - परीक्षण प्रबंधन प्रणाली, कार्य प्रबंधन, सीआई / सीडी घटक, इंफ्रा मॉनिटरिंग टूल, आदि।

और सबसे महत्वपूर्ण बात यह है कि त्वरित विश्लेषण के लिए उपलब्ध एक पर्याप्त रूप में दिखाना है - ड्रिलडाउन की संभावना के साथ डैशबोर्ड, संकेतकों का तुलनात्मक विश्लेषण।

हम क्या करना चाहते हैं

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

• इन्फ्रास्ट्रक्चर और ऑर्केस्ट्रेशन - डोकर और कुबेरनेट्स
• टास्क सेटिंग, कोड और विरूपण साक्ष्य संग्रहण, टास्क-ट्रैकर - गिटलैब, रेडमाइन, S3
• उत्पादन और विकास - बावर्ची / Ansible
• विधानसभा - जेनकिंस
• परीक्षण - सेलेनियम, लोडरनर
• निगरानी और लॉगिंग - प्रोमेथियस और ईएलके
• वैसे, आप यह कैसे देखते हैं कि यदि प्लेटफ़ॉर्म के भीतर कोई विकल्प होगा - यदि आप चाहते थे, जेनकिंस को चुना है, तो क्या - गिटलैब रनर नहीं चाहिए?
• या क्या यह मायने नहीं रखता कि अंदर क्या है, मुख्य बात यह है कि सब कुछ ठीक से बनाया, परीक्षण और तैनात किया गया है?

कोई कैसे मदद कर सकता है?

उत्पाद को घरेलू डेवलपर्स के लिए विकसित किया जाएगा। यदि आप अब हमें बताते हैं कि यह कैसे करना है, तो संभावना है कि इसे रिलीज में शामिल किया जाएगा।

कृपया मुझे बताएं कि आप अभी कौन से स्टैक का उपयोग कर रहे हैं। आप कर सकते हैं - टिप्पणियों में या team@ts-cloud.ru पर ईमेल द्वारा।
UPD: सुविधा के लिए, हमने Google फॉर्म में एक संक्षिप्त प्रश्नावली बनाई - यहाँ ।

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