DevOps LEGO: हामीले पाइपलाइनलाई क्यूबमा कसरी राख्यौं

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

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

अब तपाईलाई थप विस्तारमा बताउनुहोस्। एउटा ऊर्जा कम्पनीले १० वटा ठूला सुविधाहरूमा प्राविधिक कागजात व्यवस्थापन प्रणाली तैनाथ गरिरहेको छ। DevOps बिना यो स्केलका परियोजनाहरू नेभिगेट गर्न सजिलो छैन, किनभने म्यानुअल श्रमको ठूलो हिस्साले काममा धेरै ढिलाइ गर्छ र गुणस्तर पनि घटाउँछ - सबै म्यानुअल काम त्रुटिहरूले भरिएको छ। अर्कोतर्फ, त्यहाँ परियोजनाहरू छन् जहाँ त्यहाँ एक मात्र स्थापना छ, तर सबै चीजहरू स्वचालित रूपमा काम गर्न आवश्यक छ, लगातार र असफलता बिना - उदाहरणका लागि, ठूला मोनोलिथिक संगठनहरूमा एउटै कागजात प्रवाह प्रणालीहरू। अन्यथा, कसैले सेटिङ्हरू म्यानुअल रूपमा बनाउनेछ, डिप्लोइमेन्ट निर्देशनहरू बिर्सनेछ - र नतिजाको रूपमा, उत्पादनमा सेटिङहरू हराउनेछन् र सबै कुरा पतन हुनेछ।

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

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

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

त्यसोभए, हामीसँग एकातिर समस्याहरूको सेट छ, हामीसँग अर्कोतर्फ DevOps ज्ञान, अभ्यासहरू र उपकरणहरू छन्। किन सबैसँग अनुभव साझा नगर्ने?

DevOps कन्स्ट्रक्टर सिर्जना गर्दै

फुर्तिलोको आफ्नै घोषणापत्र छ। ITIL को आफ्नै पद्धति छ। DevOps कम भाग्यशाली छ - यसले अझै टेम्प्लेट र मापदण्डहरू प्राप्त गरेको छैन। यद्यपि केहि प्रयास गरिरहेका छन् तिनीहरूको विकास र परिचालन अभ्यासहरूको मूल्याङ्कनको आधारमा कम्पनीहरूको परिपक्वता निर्धारण गर्नुहोस्।

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

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

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

कुख्यात EDMS परियोजनामा, प्राविधिक कागजात व्यवस्थापन प्रणाली प्रत्येक 10 वस्तुहरूमा एउटै योजना अनुसार तैनात गरिएको थियो। स्थापनाले 4 सर्भरहरू समावेश गर्दछ: डाटाबेस सर्भर, अनुप्रयोग सर्भर, पूर्ण-पाठ अनुक्रमणिका र सामग्री व्यवस्थापन। स्थापनामा, तिनीहरू एकल नोड भित्र काम गर्छन् र सुविधाहरूमा डाटा केन्द्रमा अवस्थित छन्। सबै वस्तुहरू पूर्वाधारमा थोरै फरक हुन्छन्, तर यसले विश्वव्यापी अन्तरक्रियामा हस्तक्षेप गर्दैन।

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

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

संस्कृति

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

अब अन्तरक्रिया को संस्कृति को बारे मा। पहिले, त्यहाँ दुई विरोधी पक्षहरू थिए - इन्जिनियर र विकासकर्ता। विकासकर्ताहरूले भने: "हामीलाई यो कसरी सुरु हुन्छ वास्ता गर्दैनौं। तपाईं इन्जिनियर हुनुहुन्छ, तपाईं स्मार्ट हुनुहुन्छ, निश्चित गर्नुहोस् कि यो असफलता बिना सञ्चालन हुन्छ।"। इन्जिनियरहरूले जवाफ दिए: "तपाईं विकासकर्ताहरू धेरै लापरवाह हुनुहुन्छ। अझ सावधानी अपनाऔं, र हामी तपाइँका विमोचनहरू कम पटक प्ले गर्ने छौँ। किनकी प्रत्येक चोटि तपाईले हामीलाई चुहावट कोड दिनुहुन्छ, कसरी अन्तरक्रिया गर्ने भन्ने कुरा हामीलाई स्पष्ट छैन। ”। यो एक सांस्कृतिक अन्तरक्रिया मुद्दा हो जुन DevOps परिप्रेक्ष्यबाट फरक संरचित छ। यहाँ, दुवै इन्जिनियरहरू र विकासकर्ताहरू एकल टोलीको भाग हुन् जुन निरन्तर परिवर्तनमा केन्द्रित छ, तर एकै समयमा भरपर्दो सफ्टवेयर।

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

मान्छे

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

प्रविधिको

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

कोडको रूपमा पूर्वाधार

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

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

पूर्वाधार स्क्रिप्ट र पाइपलाइनहरूको अतिरिक्त, एक कोड दृष्टिकोणको रूपमा दस्तावेजीकरण पनि कागजातको लागि प्रयोग गरिन्छ। यसका लागि धन्यवाद, नयाँ व्यक्तिहरूलाई परियोजनामा ​​​​जोड्न सजिलो छ, वर्णन गरिएका कार्यहरूमा आधारित प्रणालीमा परिचय गराउन, उदाहरणका लागि, परीक्षण योजनामा, र परीक्षण केसहरू पुन: प्रयोग गर्नुहोस्।

निरन्तर वितरण र अनुगमन

पछिल्लो लेखमा DevOps को बारेमा, हामीले निरन्तर डेलिभरी र अनुगमन लागू गर्नका लागि उपकरणहरू कसरी चयन गर्यौं भन्ने कुरा गर्यौं। प्रायः त्यहाँ केहि पनि पुन: लेख्न आवश्यक छैन - यो पहिले लेखिएका स्क्रिप्टहरू प्रयोग गर्न, कम्पोनेन्टहरू बीचको एकीकरण सही रूपमा निर्माण गर्न र साझा व्यवस्थापन कन्सोल सिर्जना गर्न पर्याप्त छ। र सबै प्रक्रियाहरू एक बटन वा तालिका प्रयोग गरेर सुरू गर्न सकिन्छ।

अंग्रेजीमा विभिन्न अवधारणाहरू छन्, निरन्तर वितरण र निरन्तर तैनाती। दुबैलाई "निरन्तर डेलिभरी" को रूपमा अनुवाद गर्न सकिन्छ, तर वास्तवमा तिनीहरू बीचमा अलिकति भिन्नता छ। हाम्रो परियोजनामा ​​वितरित ऊर्जा कम्पनीको प्राविधिक कागजात प्रवाहको लागि, बरु, डेलिभरी प्रयोग गरिन्छ - जब उत्पादनको लागि स्थापना आदेशमा हुन्छ। डिप्लोयमा, स्थापना स्वतः हुन्छ। यस परियोजनामा ​​निरन्तर डेलिभरी सामान्यतया भएको छ DevOps को केन्द्रीय भाग.

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

कसलाई हाम्रो चाहिन्छ DevOps डिजाइनर?

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

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

सायद तपाईको विकास पहिले नै उच्च स्तरमा सरेको छ र हाम्रो उपकरण धेरै "कप्तानको" देखिनेछ। तर हामी यसलाई आफ्नै लागि उपयोगी पाउँछौं र आशा गर्दछौं कि यो केहि पाठकहरूको लागि उपयोगी हुनेछ। हामी तपाईंलाई सम्झाउँछौं लिङ्क डिजाइनरलाई - यदि केहि छ भने, तपाइँ प्रारम्भिक डाटा प्रविष्ट गरेपछि तुरुन्तै रेखाचित्र प्राप्त गर्नुहुन्छ। हामी तपाईंको प्रतिक्रिया र थपको लागि आभारी हुनेछौं।

स्रोत: www.habr.com