डेवऑप्स लेगो: हमने पाइपलाइन को क्यूब्स में कैसे बिछाया

हमने एक बार एक सुविधा में एक ग्राहक को इलेक्ट्रॉनिक दस्तावेज़ प्रबंधन प्रणाली की आपूर्ति की थी। और फिर किसी अन्य वस्तु पर. एक और। और चौथे पर, और पांचवें पर. हम इतने बहक गए कि हम 10 वितरित वस्तुओं तक पहुँच गए। यह प्रभावशाली ढंग से हुआ...खासकर तब जब हमें बदलाव लाने थे। उत्पादन सर्किट में डिलीवरी के हिस्से के रूप में, परीक्षण प्रणाली के 5 परिदृश्यों में अंततः 10 घंटे और 6-7 कर्मचारियों की आवश्यकता होती है। ऐसी लागतों ने हमें यथासंभव कम डिलीवरी करने के लिए मजबूर किया। तीन साल के ऑपरेशन के बाद, हम इसे बर्दाश्त नहीं कर सके और एक चुटकी DevOps के साथ प्रोजेक्ट को और बेहतर बनाने का फैसला किया।

अब सभी परीक्षण 3 घंटे में होते हैं, और 3 लोग इसमें भाग लेते हैं: एक इंजीनियर और दो परीक्षक। सुधार स्पष्ट रूप से संख्याओं में व्यक्त किए गए हैं और इससे बहुचर्चित टीटीएम में कमी आई है। हमारे अनुभव में, ऐसे कई ग्राहक हैं जो DevOps से लाभ उठा सकते हैं, उन लोगों की तुलना में जो इसके बारे में जानते भी हैं। इसलिए, DevOps को लोगों के करीब लाने के लिए, हमने एक सरल कंस्ट्रक्टर विकसित किया है, जिसके बारे में हम इस पोस्ट में अधिक विस्तार से बात करेंगे।

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

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

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

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

तो, एक ओर हमारे पास समस्याओं का एक सेट है, दूसरी ओर हमारे पास DevOps ज्ञान, अभ्यास और उपकरण हैं। अनुभव सबके साथ क्यों न बाँटा जाए?

एक DevOps कंस्ट्रक्टर बनाना

एजाइल का अपना घोषणापत्र है। ITIL की अपनी कार्यप्रणाली है. DevOps कम भाग्यशाली है - इसने अभी तक टेम्पलेट और मानक हासिल नहीं किए हैं। हालांकि कुछ प्रयत्न कंपनियों की परिपक्वता उनके विकास और परिचालन प्रथाओं के आकलन के आधार पर निर्धारित करें।

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

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

Процессы

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

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

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

संस्कृति

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

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

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

लोग

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

प्रौद्योगिकी

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

कोड के रूप में अवसंरचना

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

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

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

निरंतर वितरण और निगरानी

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

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

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

हमारी जरूरत किसे होगी DevOps डिज़ाइनर?

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

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

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

स्रोत: www.habr.com