किसी तरह हम ग्राहक को एक वस्तु इलेक्ट्रॉनिक दस्तावेज़ प्रबंधन प्रणाली पर रखते हैं। और फिर दूसरी वस्तु को। और एक और। और चौथे और पांचवें पर। उन्हें इतना दूर ले जाया गया कि वे 10 वितरित वस्तुओं तक पहुंच गए। शक्तिशाली हुआ ... खासकर जब हम बदलाव की डिलीवरी के लिए पहुंचे। 5 परीक्षण प्रणाली परिदृश्यों के लिए उत्पादक सर्किट को आपूर्ति के हिस्से के रूप में, इसके परिणामस्वरूप 10 घंटे और 6-7 कर्मचारी लगे। इस तरह की लागत ने हमें जितना संभव हो उतना कम वितरित करने के लिए मजबूर किया। तीन साल के ऑपरेशन के बाद, हम इसे बर्दाश्त नहीं कर सके और इस परियोजना को देवओप्स के एक चुटकी के साथ सीज़न करने का फैसला किया।
अब सभी परीक्षण 3 घंटे में पास हो जाते हैं, और 3 लोग इसमें भाग लेते हैं: एक इंजीनियर और दो परीक्षक। सुधार स्पष्ट रूप से संख्याओं में व्यक्त किए जाते हैं और प्यारे TTM में कमी लाते हैं। हमारे अनुभव में, अब और भी कई ग्राहक हैं जो DevOps उन लोगों की मदद कर सकते हैं जो इसके बारे में जानते हैं। इसलिए, DevOps को लोगों के करीब लाने के लिए, हमने एक साधारण कंस्ट्रक्टर विकसित किया है, जिसके बारे में हम इस पोस्ट में अधिक विस्तार से बात करेंगे।
अब हम और विस्तार से बताएंगे। 10 बड़ी सुविधाओं में एक ऊर्जा कंपनी में, एक तकनीकी दस्तावेज प्रबंधन प्रणाली तैनात की जा रही है। बिना DevOps के इस पैमाने की परियोजनाओं में आना आसान नहीं है, क्योंकि मैन्युअल श्रम का एक बड़ा हिस्सा काम में देरी करता है और गुणवत्ता को भी कम करता है - सभी मैनुअल काम त्रुटियों से भरा होता है। दूसरी ओर, ऐसी परियोजनाएं हैं जहां स्थापना एक है, लेकिन यह आवश्यक है कि सब कुछ स्वचालित रूप से, लगातार और बिना असफल काम करता है - उदाहरण के लिए, बड़े अखंड संगठनों में समान दस्तावेज़ प्रबंधन प्रणाली। अन्यथा, कोई व्यक्ति मैन्युअल रूप से सेटिंग करेगा, परिनियोजन निर्देशों के बारे में भूल जाएगा - और परिणामस्वरूप, सेटिंग्स को ठिकाने पर खो दिया जाएगा और सब कुछ दुर्घटनाग्रस्त हो जाएगा।
आमतौर पर हम एक अनुबंध के माध्यम से ग्राहक के साथ काम करते हैं, जिस स्थिति में हमारे हित थोड़ा प्रभावित होते हैं। ग्राहक बजट और टीके के भीतर परियोजना को सख्ती से देखता है। यह स्पष्ट करना मुश्किल हो सकता है कि विभिन्न DevOps प्रथाओं के लाभ जो TK का हिस्सा नहीं हैं। और अगर वह ऑटोमेशन पाइपलाइन बनाने में, व्यापार के लिए अतिरिक्त मूल्य के साथ त्वरित रिलीज में दिलचस्पी रखता है?
काश, पूर्व-स्वीकृत मूल्य के साथ काम करने में यह ब्याज हमेशा खोजना संभव नहीं होता। हमारे व्यवहार में, एक ऐसा मामला था जब हमें एक बेईमान और गलत ठेकेदार के विकास को उठाना पड़ा। यह एक डरावना था: कोई वास्तविक स्रोत कोड नहीं हैं, अलग-अलग प्रतिष्ठानों पर एक ही सिस्टम का कोड आधार अलग है, प्रलेखन आंशिक रूप से गायब था, आंशिक रूप से भयानक गुणवत्ता का था। बेशक, ग्राहक के पास स्रोत नियंत्रण, विधानसभा, रिलीज़ आदि नहीं थे।
अब तक, हर कोई DevOps के बारे में नहीं जानता है, लेकिन इसके फायदे के बारे में बात करने लायक है, संसाधनों की वास्तविक बचत के बारे में, सभी ग्राहकों के लिए आँखों की रोशनी। इसलिए समय के साथ DevOps से अधिक से अधिक अनुरोध शामिल हैं। यहां, ग्राहकों के साथ समान भाषा को आसानी से बोलने के लिए, हमें व्यावसायिक समस्याओं और DevOps प्रथाओं को जल्दी से जोड़ने की आवश्यकता है, जो एक उपयुक्त विकास पाइपलाइन बनाने में मदद करेंगे।
तो, हमारे पास एक तरफ समस्याओं का एक सेट है, दूसरी तरफ ज्ञान, अभ्यास और DevOps उपकरण हैं। सभी के साथ अनुभव साझा क्यों नहीं करते?
एक DevOps कंस्ट्रक्टर बनाएँ
एजाइल का अपना घोषणापत्र है। ITIL की अपनी कार्यप्रणाली है। DevOps कम भाग्यशाली है - यह अभी तक टेम्पलेट्स और मानकों का अधिग्रहण नहीं किया है। हालांकि
कुछ अपने विकास और संचालन के तरीकों के आकलन के आधार पर कंपनियों की परिपक्वता की डिग्री निर्धारित
करने की कोशिश कर रहे हैं ।
सौभाग्य से, 2014 में कुख्यात गार्टनर कंपनी ने प्रमुख DevOps प्रथाओं और उनके बीच संबंधों का विश्लेषण किया। इसके आधार पर, मैंने इन्फोग्राफिक जारी किया:
हमने इसे अपने
कंस्ट्रक्टर के आधार के रूप में लिया। चार क्षेत्रों में से प्रत्येक में उपकरणों का एक सेट है - हमने उन्हें डेटाबेस में एकत्र किया, सबसे लोकप्रिय, पहचाने गए एकीकरण अंक और उपयुक्त अनुकूलन तंत्र की पहचान की। कुल मिलाकर,
36 प्रथाएं और 115 उपकरण निकले, जिनमें से एक चौथाई खुले या मुफ्त सॉफ्टवेयर हैं। आगे, हम इस बारे में बात करेंगे कि हमने प्रत्येक क्षेत्र में क्या किया है और उदाहरण के लिए, यह परियोजना में कैसे लागू किया गया था एक तकनीकी वर्कफ़्लो बनाने के लिए जिसमें से हमने पोस्ट शुरू किया था।
प्रक्रियाओं
कुख्यात EDMS परियोजना में, तकनीकी प्रलेखन प्रबंधन प्रणाली को प्रत्येक 10 सुविधाओं में एक ही योजना के अनुसार तैनात किया गया था। स्थापना में 4 सर्वर शामिल हैं: एक डेटाबेस सर्वर, एक एप्लिकेशन सर्वर, पूर्ण-पाठ अनुक्रमण और सामग्री प्रबंधन। स्थापना में, वे एक नोड के भीतर काम करते हैं, सुविधाओं में डेटा सेंटर में स्थित हैं। सभी ऑब्जेक्ट बुनियादी ढांचे में थोड़ा भिन्न होते हैं, लेकिन यह वैश्विक बातचीत में हस्तक्षेप नहीं करता है।
पहले, DevOps प्रथाओं के अनुसार, हमने स्थानीय रूप से इन्फ्रास्ट्रक्चर को स्वचालित किया, फिर हम डिलीवरी को परीक्षण सर्किट में लाए, और फिर ग्राहक की उत्पादकता के लिए। प्रत्येक प्रक्रिया ने कदम दर कदम काम किया। स्रोत कोड सिस्टम में पर्यावरण सेटिंग्स तय की जाती हैं, यह ध्यान में रखते हुए कि वितरण स्वचालित अपडेट के लिए एकत्र किया गया है। कॉन्फ़िगरेशन में परिवर्तन के मामले में, इंजीनियरों को बस संस्करण नियंत्रण प्रणाली में उचित बदलाव करने की आवश्यकता है - और फिर स्वत: अद्यतन बिना समस्याओं के पास हो जाएगा।
इस दृष्टिकोण के लिए धन्यवाद, परीक्षण प्रक्रिया को बहुत सरल किया गया है। पहले, प्रोजेक्ट में परीक्षक थे जिन्होंने केवल वही किया था जो मैन्युअल रूप से स्टैंड को अपडेट करता था। अब वे बस आते हैं, देखते हैं कि सब कुछ काम कर गया है और अधिक उपयोगी चीजों में लगे हुए हैं। प्रत्येक अद्यतन को स्वचालित रूप से परीक्षण किया जाता है - सतह स्तर से व्यावसायिक परिदृश्य के स्वचालन तक। टेस्टरेल में परिणाम अलग रिपोर्ट के रूप में निर्धारित किए गए हैं।
संस्कृति
परीक्षण डिजाइन द्वारा निरंतर प्रयोग को सबसे अच्छा समझाया गया है। एक प्रणाली का परीक्षण करना जो अभी तक मौजूद नहीं है, रचनात्मक कार्य है। परीक्षण योजना लिखते समय, आपको यह समझने की आवश्यकता है कि सही तरीके से परीक्षण कैसे किया जाए, किन शाखाओं से गुजरना है। और चेकों की इष्टतम संख्या निर्धारित करने के लिए समय और बजट के बीच एक संतुलन भी खोजें। वास्तव में आवश्यक परीक्षणों को चुनना महत्वपूर्ण है, विचार करें कि उपयोगकर्ता सिस्टम के साथ कैसे बातचीत करेगा, पर्यावरण और संभव बाहरी कारकों को ध्यान में रखेगा। आप निरंतर प्रयोग के बिना नहीं कर सकते।
अब बातचीत की संस्कृति के बारे में। वहाँ दो युद्धरत दल हुआ करते थे - इंजीनियर और डेवलपर्स। डेवलपर्स ने कहा:
"हमें परवाह नहीं है कि यह कैसे शुरू होता है। आप इंजीनियर हैं, आप स्मार्ट हैं, इसे बिना किसी रुकावट के संचालित करें ।
” इंजीनियरों ने जवाब दिया:
“आप डेवलपर्स बहुत लापरवाह हैं। आइए हम अधिक सावधान रहें, और हम आपकी रिलीज़ कम बार करेंगे। क्योंकि हर बार आपने हमें एक छिद्रपूर्ण कोड दिया है, और हम कैसे बातचीत करते हैं, यह स्पष्ट नहीं है ।
” यह एक सांस्कृतिक बातचीत का मुद्दा है, जो कि DevOps के दृष्टिकोण से, अलग ढंग से संरचित है। यहां आपके पास इंजीनियर और डेवलपर दोनों हैं जो एक ही टीम का हिस्सा हैं जिसका उद्देश्य लगातार बदलते रहना है, लेकिन एक ही समय में विश्वसनीय सॉफ्टवेयर।
एक टीम के पैमाने पर, विशेषज्ञ एक-दूसरे की मदद करने के लिए तैयार हैं। यह पहले कैसे था? उदाहरण के लिए, किसी प्रकार की मोटी तैनाती नियमावली तैयार की जा रही थी, पृष्ठों को 50 पर। इंजीनियर ने इसे पढ़ा, कुछ समझ में नहीं आया, कसम खाई और डेवलपर को सुबह तीन बजे टिप्पणी करने के लिए कहा। डेवलपर ने टिप्पणी की और शपथ भी ली - अंत में, कोई भी खुश नहीं था। इसके अलावा, स्वाभाविक रूप से, कुछ त्रुटियां थीं, क्योंकि आपको निर्देशों में सब कुछ याद नहीं होगा। और अब इंजीनियर, डेवलपर के साथ मिलकर, एप्लिकेशन सॉफ़्टवेयर इन्फ्रास्ट्रक्चर की स्वचालित तैनाती के लिए एक स्क्रिप्ट लिख रहा है। और वे एक-दूसरे के साथ लगभग एक ही भाषा में बात करते हैं।
लोग
टीम का आकार अद्यतन की सीमा से निर्धारित होता है। आपूर्ति के गठन के दौरान टीम की भर्ती की जाती है, इसमें वे लोग शामिल होते हैं जो सामान्य परियोजना टीम से चाहते हैं। फिर, एक अद्यतन योजना प्रत्येक चरण के लिए जिम्मेदारी के साथ लिखी जाती है, जैसा कि टीम निष्पादित करती है, यह रिपोर्ट करती है। सभी टीम के सदस्य विनिमेय हैं। टीम के हिस्से के रूप में, हमारे पास एक सुरक्षा डेवलपर भी है, लेकिन उसे लगभग कभी भी कनेक्ट नहीं करना पड़ता है।
प्रौद्योगिकी के
प्रौद्योगिकी के लिए योजना में, कुछ बिंदुओं पर प्रकाश डाला गया है, लेकिन उनके तहत प्रौद्योगिकियों का एक समूह है - उनके विवरणों के साथ आप एक पूरी पुस्तक जारी कर सकते हैं। इसलिए हम सबसे दिलचस्प पर प्रकाश डालेंगे।
कोड के रूप में अवसंरचना
अब, शायद, आप इस अवधारणा से किसी को आश्चर्यचकित नहीं करेंगे, लेकिन इससे पहले कि बुनियादी ढांचे के विवरण से वांछित होने के लिए बहुत कुछ बचा हो।
निर्देश पर इंजीनियरों ने आतंक के साथ देखा , परीक्षण का वातावरण अद्वितीय था, उनकी देखभाल की गई और उन्हें पोषित किया गया, धूल के कण उड़ा दिए गए।
अब कोई भी प्रयोग करने से डरता है। आभासी मशीनों की बुनियादी छवियां हैं, पर्यावरण को तैनात करने के लिए तैयार परिदृश्य हैं। सभी टेम्प्लेट और स्क्रिप्ट संस्करण नियंत्रण प्रणाली में संग्रहीत किए जाते हैं और जल्दी से अपडेट किए जाते हैं। पहले, जब पैकेज को स्टैंड पर पहुंचाना आवश्यक था, तो कॉन्फ़िगरेशन गैप दिखाई दिया। अब आपको स्रोत कोड में एक पंक्ति जोड़ने की आवश्यकता है।
इन्फ्रास्ट्रक्चर परिदृश्यों और पाइपलाइनों के अलावा, प्रलेखन के लिए एक कोड दृष्टिकोण के रूप में प्रलेखन का भी उपयोग किया जाता है। इसके लिए धन्यवाद, नए लोगों को परियोजना से जोड़ना आसान है, उन्हें वर्णित कार्यों द्वारा सिस्टम से परिचित कराएं, उदाहरण के लिए, परीक्षण योजना में, और परीक्षण मामलों का पुन: उपयोग भी करें।
सतत वितरण और निगरानी
DevOps के बारे
में अपने आखिरी लेख में, हमने इस बारे में बात की कि हमने निरंतर वितरण और निगरानी को लागू करने के लिए उपकरणों को कैसे चुना। अक्सर किसी भी चीज़ को फिर से लिखने की आवश्यकता नहीं होती है - यह पहले से लिखी गई लिपियों का उपयोग करने के लिए पर्याप्त है, घटकों के बीच एकीकरण का सही ढंग से निर्माण करें और एक सामान्य प्रबंधन कंसोल बनाएं। और सभी प्रक्रियाओं को एक बटन या अनुसूची के साथ शुरू किया जा सकता है।
अंग्रेजी में विभिन्न अवधारणाएँ हैं, सतत वितरण और निरंतर तैनाती। दोनों का अनुवाद "निरंतर वितरण" के रूप में किया जा सकता है, लेकिन वास्तव में उनके बीच थोड़ा अंतर है। एक वितरित ऊर्जा कंपनी के तकनीकी दस्तावेज प्रबंधन के लिए हमारी परियोजना में, वितरण का उपयोग किया जाता है, बल्कि, जब बिक्री के लिए स्थापना आदेश पर की जाती है। परिनियोजन में, स्थापना स्वचालित है। इस परियोजना में निरंतर वितरण आम तौर पर
DevOps का एक
केंद्रीय हिस्सा बन गया है।
सामान्य तौर पर, कुछ मापदंडों को इकट्ठा करके, आप स्पष्ट रूप से समझ सकते हैं कि देवओप्स अभ्यास क्यों उपयोगी हैं। और इसे नेतृत्व तक पहुंचाने के लिए, जिसे संख्याओं का बहुत शौक है। लॉन्च की कुल संख्या, स्क्रिप्ट के चरणों का निष्पादन समय, सफल लॉन्च का हिस्सा - यह सब सीधे बाजार के लिए सभी के पसंदीदा समय को प्रभावित करता है, अर्थात, संस्करण नियंत्रण प्रणाली के लिए प्रतिबद्ध होने से उत्पादक वातावरण पर संस्करण की रिलीज तक का समय। आवश्यक उपकरणों की शुरूआत के साथ, इंजीनियरों को मेल द्वारा मूल्यवान संकेतक प्राप्त होते हैं, और परियोजना प्रबंधक उन्हें डैशबोर्ड पर देखता है। तो आप तुरंत नए उपकरणों के लाभों की सराहना कर सकते हैं। और आप DevOps कंस्ट्रक्टर का उपयोग करके उन्हें अपने बुनियादी ढांचे पर आज़मा सकते हैं।
हम धोखा नहीं देंगे: शुरुआत के लिए, वह हमारे लिए उपयोगी बन गया। जैसा कि हमने पहले ही कहा था, ग्राहक को एक ही भाषा बोलने की आवश्यकता है, और DevOps कंस्ट्रक्टर की मदद से हम इस तरह की बातचीत के लिए आधार को जल्दी से रेखांकित कर सकते हैं। व्यावसायिक पेशेवर खुद का मूल्यांकन करने में सक्षम होंगे कि उन्हें क्या चाहिए, और इस प्रकार तेजी से विकास होगा। हमने कंस्ट्रक्टर को जितना संभव हो उतना विस्तृत बनाने की कोशिश की, विवरणों का एक गुच्छा जोड़ा, ताकि कोई भी उपयोगकर्ता समझता है कि वह क्या चुनता है।
डिजाइनर का प्रारूप आपको निर्माण प्रक्रियाओं और स्वचालन में कंपनी के मौजूदा अनुभव को ध्यान में रखने की अनुमति देता है। आपको हर चीज को तोड़ना होगा और पुनर्निर्माण करना होगा यदि आप केवल उन समाधानों का चयन कर सकते हैं जो आम तौर पर मौजूदा प्रक्रियाओं में एकीकृत होते हैं जो केवल अंतराल में भर सकते हैं।
शायद आपका विकास पहले ही उच्च स्तर पर चला गया है और हमारा उपकरण "कप्तान" भी प्रतीत होगा। लेकिन हम इसे अपने लिए उपयोगी पाते हैं और आशा करते हैं कि यह कुछ पाठकों के लिए उपयोगी हो। हम आपको निर्माता को
लिंक याद दिलाते हैं - यदि कुछ भी हो, तो आपको स्रोत डेटा दर्ज करने के तुरंत बाद सर्किट मिलता है। हम प्रतिक्रिया और परिवर्धन के लिए आभारी होंगे।