DevOps के कार्यान्वयन के लिए ट्रम्प कार्ड के रूप में समय-समय पर बाजार

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

प्रस्तुत? यह काम किया? आपने सबसे अमीर कल्पना के लिए सफलतापूर्वक परीक्षा उत्तीर्ण की है!

वास्तव में, निश्चित रूप से, ऐसा नहीं है। सबसे अधिक, प्रबंधन हमारे आईटी सामान तक नहीं है। इसलिए, आपको विश्वास दिलाना होगा। लेकिन कैसे?

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

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

प्रक्रियाओं की भविष्यवाणी आमतौर पर ऐसा व्यक्तिपरक कारक है, जो वांग और नोस्ट्राडमस के बारे में चुटकुले को सही ठहराना और उनसे बचना काफी मुश्किल है।

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

बेशक, एक और विकल्प पर विचार किया जा सकता है जब कोई व्यक्ति DevOps में अनुभव के साथ कंपनी में आता है, स्पष्ट रूप से यह दर्शाता है कि समस्या क्या है और इसे कैसे हल किया जाना चाहिए। और जो नेतृत्व को अपनी राय देने में सक्षम है। हालांकि, चलो एक चमत्कार चाचा के लिए आशा नहीं है।

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

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

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

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

बिल्कुल परेतो कानून के अनुसार, हाँ।

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

लेकिन एक ही समय में, ऐसी स्थिति हमें एक शानदार और सबसे महत्वपूर्ण, त्वरित जीत का मौका देती है। जिसके बाद, सकारात्मक दृष्टिकोण और नेतृत्व का आशीर्वाद होने पर, आप पहले से ही धन और संसाधनों के लिए पूछ सकते हैं।

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

पहले आपको धुएं के परीक्षणों को स्वचालित करने की आवश्यकता है। लेकिन यह कैसे समझें कि स्वचालित क्या है? हां, पिछले छह महीनों में जब आप परिवर्तन पोस्ट करते हैं, तो बस उसे देखें।

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

एक सप्ताह, ठीक है, इस तरह के परीक्षण बनाने के लिए अधिकतम दो। परिणाम वैश्विक त्रुटियों के लिए एक बहुत तेज़ प्रतिक्रिया है।

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

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

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

ऐसी ठोस जीत के बाद, आप पहले से ही स्टैंड की तैनाती के स्वचालन के बारे में बात कर सकते हैं (कम से कम परीक्षण के लिए)। अगला, निगरानी और अन्य DevOps प्रसन्न के लिए धन के लिए पूछें। यह याद रखना चाहिए कि सिस्टम के शेष घटक अब व्यवसाय के लिए एक वाह प्रभाव नहीं डालेंगे।

स्टूडियो उदाहरण

पोस्ट के अंत में, मुझे लगता है कि DevOps के कार्यान्वयन के लिए एक सफलतापूर्वक पूरी हुई परियोजना का उदाहरण देना उचित होगा, जिसे हमारी कंपनी द्वारा लागू किया गया था।

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

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

रिटेलर के प्रतिनिधियों ने अनुभव को सफल पाया और इसे अन्य सॉफ्टवेयर उत्पादों पर लागू करने का फैसला किया।

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

ऐसा करने के लिए पर्याप्त महत्वपूर्ण है, है ना?

सर्गेई स्ट्रैमनोव, जेट इन्फोसिस्टम्स सॉफ्टवेयर सॉल्यूशंस सेंटर के अध्यक्ष वास्तुकार