डेवलपर्स के लिए सर्वोत्तम DevOps अभ्यास। एंटोन बॉयको (2017)

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

मुझे अपना परिचय दें, मैं पूरी तरह से स्वीकार करता हूं कि कमरे में ऐसे लोग हैं जो मुझे नहीं जानते हैं। मेरा नाम एंटोन बॉयको है, मैं एक Microsoft Azure MVP हूं। एमवीपी क्या है? यह मॉडल-व्यू-प्रस्तोता है। मॉडल-व्यू-प्रस्तोता बिल्कुल मैं ही हूं।

इसके अलावा, मैं वर्तमान में सिक्लम में समाधान वास्तुकार के पद पर हूं। और अभी हाल ही में मैंने अपने लिए इतना सुंदर डोमेन खरीदा है, और मैंने अपना ईमेल अपडेट किया है, जिसे मैं आमतौर पर प्रस्तुतियों में दिखाता हूं। आप मुझे यहां लिख सकते हैं: me [कुत्ता] byokoant.pro। आप मुझे प्रश्नों के साथ ईमेल कर सकते हैं. मैं आमतौर पर उन्हें जवाब देता हूं. एकमात्र बात यह है कि मैं ईमेल द्वारा ऐसे प्रश्न प्राप्त नहीं करना चाहूँगा जो दो विषयों से संबंधित हों: राजनीति और धर्म। आप बाकी सभी चीज़ों के बारे में मुझे ईमेल द्वारा लिख ​​सकते हैं। कुछ समय बीत जाएगा, मैं उत्तर दूंगा।

मेरे बारे में कुछ शब्द:

• मैं अब 10 वर्षों से इस क्षेत्र में हूं।
• मैंने माइक्रोसॉफ्ट में काम किया।
• मैं यूक्रेनी एज़्योर समुदाय का संस्थापक हूं, जिसकी स्थापना हमने 2014 में की थी। और यह अभी भी हमारे पास है और हम इसे विकसित कर रहे हैं।
• मैं एज़्योर सम्मेलन के संस्थापक का पिता भी हूं, जिसे हम यूक्रेन में आयोजित कर रहे हैं।
• मैं कीव में ग्लोबल एज़्योर बूटकैंप आयोजित करने में भी मदद करता हूँ।
• जैसा कि मैंने कहा, मैं एक Microsoft Azure MVP हूं।
• मैं अक्सर सम्मेलनों में बोलता हूं। मुझे सम्मेलनों में बोलना बहुत पसंद है। पिछले वर्ष में मैं लगभग 40 बार प्रदर्शन करने में सफल रहा। यदि आप यूक्रेन, बेलारूस, पोलैंड, बुल्गारिया, स्वीडन, डेनमार्क, नीदरलैंड, स्पेन से गुजरते हैं या यूरोप में किसी अन्य देश को देते या लेते हैं, तो यह बहुत संभव है कि जब आप किसी ऐसे सम्मेलन में जाते हैं जिसकी स्ट्रीम में क्लाउड थीम होती है, आप मुझे वक्ताओं की सूची में देख सकते हैं।
• मैं भी स्टार ट्रेक का प्रशंसक हूं।

चलिए एजेंडा के बारे में थोड़ी बात करते हैं। हमारा एजेंडा बहुत सरल है:

• हम बात करेंगे कि DevOps क्या है। आइए बात करें कि यह महत्वपूर्ण क्यों है। पहले, DevOps एक कीवर्ड था जिसे आप अपने बायोडाटा पर लिखते थे और तुरंत वेतन में +$500 प्राप्त करते थे। अब आपको अपने वेतन में +500 डॉलर पाने के लिए, उदाहरण के लिए, अपने बायोडाटा में ब्लॉकचेन लिखना होगा।
• और फिर, जब हम थोड़ा समझ जाएंगे कि यह क्या है, तो हम बात करेंगे कि DevOps प्रथाएं क्या हैं। लेकिन सामान्य तौर पर DevOps के संदर्भ में इतना नहीं, बल्कि उन DevOps प्रथाओं के बारे में जो डेवलपर्स के लिए रुचिकर हो सकती हैं। मैं आपको बताऊंगा कि उनमें आपकी रुचि क्यों हो सकती है। मैं आपको बताऊंगा कि आपको ऐसा क्यों करना चाहिए और यह आपको कम दर्द का अनुभव करने में कैसे मदद कर सकता है।

एक पारंपरिक तस्वीर जो कई लोग दिखाते हैं. कई परियोजनाओं में ऐसा ही होता है. ऐसा तब है जब हमारे पास विकास और संचालन विभाग हैं जो हमारे सॉफ़्टवेयर का समर्थन करते हैं। और ये विभाग एक दूसरे से संवाद नहीं करते.

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

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

यह ठीक यही दीवार है जिसे DevOps संस्कृति को नष्ट करने के लिए डिज़ाइन किया गया है, अर्थात। लोगों को एक-दूसरे के साथ संवाद करने के लिए बाध्य करें और कम से कम यह समझें कि परियोजना में विभिन्न लोग क्या करते हैं और उनका काम क्यों महत्वपूर्ण है।

और जब हम DevOps के बारे में बात करते हैं, तो कोई आपको बताएगा कि DevOps तब होता है जब प्रोजेक्ट में निरंतर एकीकरण होता है; कोई कहेगा कि यदि परियोजना "कोड के रूप में बुनियादी ढांचे" अभ्यास को लागू करती है तो DevOps है; कोई कहेगा कि DevOps की ओर पहला कदम फ़ीचर ब्रांचिंग, फ़ीचर फ़्लैग है।

मूलतः, यह सब अपने तरीके से सत्य है। लेकिन ये हमारी सर्वोत्तम प्रथाएं हैं। इन प्रथाओं पर आगे बढ़ने से पहले, मैं इस स्लाइड को देखने का सुझाव देता हूं, जो आपकी कंपनी में, आपके प्रोजेक्ट में डेव-ऑप्स पद्धति को लागू करने के 3 चरणों को दिखाती है।

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

जब आप DevOps संस्कृति को लागू करना शुरू करते हैं, तो यह बहुत महत्वपूर्ण है कि इसे निम्नलिखित क्रम में लागू किया जाए।

शुरुआत में आपको लोगों से बात करने की जरूरत है। और आपको लोगों को यह समझाने की ज़रूरत है कि यह क्या है और वे इससे कैसे लाभ प्राप्त कर सकते हैं।

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

हम लोगों के बारे में बात करेंगे, हम इस बारे में बात करेंगे कि डेवलपर्स हर दिन क्या करना चाहते हैं। वे सबसे ज़्यादा क्या चाहते हैं? वे कुछ नए कोड लिखना चाहते हैं, नए-नए ढाँचे का उपयोग करना चाहते हैं, नई सुविधाएँ बनाना चाहते हैं। डेवलपर्स कम से कम क्या चाहते हैं? पुराने बग ठीक करें. मुझे आशा है कि आप मुझसे सहमत होंगे. डेवलपर्स यही चाहते हैं. वे नई सुविधाएँ लिखना चाहते हैं, वे बग ठीक नहीं करना चाहते।

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

क्यूए सबसे अधिक क्या चाहते हैं? मुझे नहीं पता कि वे हॉल में हैं या नहीं। मेरे लिए यह कहना कठिन है कि मुझे QA चाहिए, क्योंकि मैं कभी QA नहीं रहा। और लोगों के लिए कोई अपराध नहीं, यह कहा जाएगा कि मुझे आशा है कि मैं कभी ऐसा नहीं करूंगा। लेकिन इसलिए नहीं कि मैं उनके काम को निरर्थक और बेकार मानता हूं, बल्कि इसलिए कि मैं खुद को ऐसा इंसान नहीं मानता जो यह काम कुशलता से कर सके, इसलिए मैं इसे करने की कोशिश भी नहीं करूंगा. लेकिन जहां तक ​​मैं समझता हूं, क्यूए को जो चीज सबसे ज्यादा पसंद नहीं है, वह है सुबह काम करना, लगातार कुछ प्रकार के प्रतिगमन परीक्षण चलाना, उन्हीं बगों पर कदम रखना, जिनके बारे में उन्होंने 3 स्प्रिंट पहले डेवलपर्स को रिपोर्ट किया था और कह रहे थे: "आप कब काम करेंगे , महाशय डी 'आर्टगनन, इस बग को ठीक करें।' और महाशय डी'आर्टगनन ने उसे उत्तर दिया: "हाँ, हाँ, हाँ, मैंने इसे पहले ही ठीक कर दिया है।" और ऐसा कैसे हुआ कि मैंने एक बग ठीक किया और रास्ते में 5 बना दिए।

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

और जब आप लोगों को समझाते हैं कि उनका उद्देश्य उन्हीं समस्याओं को हल करना है, तो आप प्रक्रियाओं को औपचारिक बनाने की ओर आगे बढ़ सकते हैं। बहुत जरुरी है। क्यों? क्योंकि जब हम "औपचारिकीकरण" कहते हैं, तो आपके लिए यह वर्णन करना महत्वपूर्ण है कि आपकी प्रक्रियाएँ कम से कम किसी नैपकिन पर कैसे घटित होती हैं। आपको यह समझने की आवश्यकता है कि यदि आप, उदाहरण के लिए, QA वातावरण या उत्पादन वातावरण में तैनात हैं, तो यह हमेशा इसी क्रम में होता है; इन चरणों में हम चलते हैं, उदाहरण के लिए, स्वचालित इकाई परीक्षण और यूआई परीक्षण। तैनाती के बाद, हम जांचते हैं कि तैनाती अच्छी हुई या खराब। लेकिन आपके पास पहले से ही कार्यों की एक स्पष्ट सूची है जिसे उत्पादन पर तैनात करते समय बार-बार दोहराया जाना चाहिए।

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

दुर्भाग्य से, मैं अक्सर इसे उलटा होता हुआ देखता हूँ। जैसे ही कोई "DevOps" शब्द सुनता है, वे तुरंत जेनकिंस इंस्टॉल करने का सुझाव देते हैं, क्योंकि उनका मानना ​​है कि जैसे ही वे जेनकिंस इंस्टॉल करेंगे, उनके पास DevOps होंगे। उन्होंने जेनकींस स्थापित किया, जेनकींस वेबसाइट पर "कैसे करें" लेख पढ़े, इन कैसे करें लेखों में प्रक्रियाओं को भरने की कोशिश की, और फिर लोगों के पास आए और लोगों को यह कहते हुए झुकाया कि किताब कहती है कि आपको इसे इस तरह से करने की ज़रूरत है, तो हम इसे इस तरह से करते हैं।

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

आइए सामान्यतः DevOps प्रथाओं के बारे में बात करें। क्या रहे हैं? क्या अंतर है? उन पर कैसे प्रयास करें? वे महत्वपूर्ण क्यों हैं?

पहला अभ्यास जिसके बारे में आपने सुना होगा उसे सतत एकीकरण कहा जाता है। शायद प्रोजेक्ट पर किसी के पास सतत एकीकरण (सीआई) है।

सबसे बड़ी समस्या यह है कि अक्सर जब मैं किसी व्यक्ति से पूछता हूं: "क्या आपके पास प्रोजेक्ट पर सीआई है?" और वह कहता है: "हां," फिर जब मैं पूछता हूं कि वह क्या करता है, तो वह मुझे पूरी स्वचालन प्रक्रिया का वर्णन करता है। यह पूरी तरह से सच नहीं है।

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

सीआई के साथ, आम तौर पर रास्ते में अन्य प्रथाएं भी होती हैं - जैसे सतत तैनाती, रिलीज प्रबंधन, लेकिन हम इसके बारे में बाद में बात करेंगे।

सीआई स्वयं हमें बताता है कि अलग-अलग लोग कोड लिखते हैं और इस कोड को लगातार एक ही कोड बेस में एकीकृत किया जाना चाहिए।

यह हमें क्या देता है और यह महत्वपूर्ण क्यों है? यदि हमारे पास DotNet है, तो यह अच्छा है, यह एक संकलित भाषा है, हम अपने एप्लिकेशन को संकलित कर सकते हैं। यदि यह संकलित होता है, तो यह पहले से ही एक अच्छा संकेत है। इसका अभी तक कोई मतलब नहीं है, लेकिन यह पहला अच्छा संकेत है जिसे हम कम से कम संकलित कर सकते हैं।

फिर हम कुछ परीक्षण चला सकते हैं, जो एक अलग अभ्यास भी है। सभी परीक्षण हरे हैं - यह दूसरा अच्छा संकेत है। लेकिन फिर, इसका कोई मतलब नहीं है।

लेकिन आप ऐसा क्यों करेंगे? आज मैं जिन प्रथाओं के बारे में बात करूंगा, उनका मूल्य लगभग समान है, यानी लगभग समान लाभ हैं और उन्हें भी लगभग उसी तरह से मापा जाता है।

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

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

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

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

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

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

हम इस अभ्यास की सफलता या विफलता को कैसे माप सकते हैं? यदि आप बिग बॉस को रिपोर्ट करते हैं कि हमने सीआई परियोजना पर क्या लागू किया है, तो वह ब्ला ब्ला ब्ला सुनता है। हमने इसे लागू किया, ठीक है, लेकिन क्यों, यह हमारे लिए क्या लेकर आया, हम इसे कैसे मापते हैं, हम इसे कितना सही या गलत तरीके से लागू कर रहे हैं?

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

हमारे पास एक और अभ्यास है ऑटोमेशन परीक्षण अभ्यास, जो अक्सर सीआई अभ्यास के साथ आता है। वे साथ-साथ चलते हैं।

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

हमारे पास एकीकरण परीक्षण भी हैं जो हमें यह समझने की अनुमति देते हैं कि विभिन्न मॉड्यूल एक-दूसरे के साथ कैसे एकीकृत होते हैं। यह अच्छा भी है.

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

आपके द्वारा चलाए जाने वाले विशिष्ट परीक्षण इस बात को प्रभावित कर सकते हैं कि आप उन्हें कितनी बार चलाते हैं। यूनिट परीक्षण आमतौर पर छोटे और छोटे लिखे जाते हैं। और इन्हें नियमित रूप से लॉन्च किया जा सकता है.

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

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

और हमने उनसे कहा कि यदि आप अधिक उत्पादक बनना चाहते हैं, तो स्वचालित परीक्षण प्रथाओं को लागू करना आपके लिए उचित है, क्योंकि यही आपको यहीं, अभी नुकसान पहुंचाता है।

सतत परिनियोजन का अभ्यास करें. बढ़िया, आपने निर्माण कर लिया है। यह पहले से ही अच्छा है. आपका कोड संकलित हो गया है. अब इस बिल्ड को किसी परिवेश पर तैनात करना अच्छा होगा। आइए डेवलपर्स के लिए एक वातावरण में कहें।

यह महत्वपूर्ण क्यों है? सबसे पहले, आप यह देख सकते हैं कि आप परिनियोजन प्रक्रिया में कितने सफल हैं। मैं इस तरह की परियोजनाओं से मिला हूं, जब मैं पूछता हूं: "आप एप्लिकेशन का नया संस्करण कैसे तैनात करते हैं?", तो लोग मुझसे कहते हैं: "हम इसे इकट्ठा करते हैं और इसे एक ज़िप संग्रह में पैक करते हैं। हम इसे व्यवस्थापक को मेल द्वारा भेजते हैं। व्यवस्थापक इस संग्रह को डाउनलोड और विस्तारित करता है। और पूरा कार्यालय प्रार्थना करने लगता है कि सर्वर नया संस्करण ले लेगा।''

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

इसके अलावा, जब आप एक दूसरे के बीच कोड को एकीकृत करते हैं, यानी। कमांड के बीच, यह आपको यह भी देखने की अनुमति देता है कि यह यूआई पर कैसा दिखता है।

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

अगला अभ्यास जो हमारे पास है वह स्वचालित पुनर्स्थापना का अभ्यास है, अर्थात् एप्लिकेशन के पिछले संस्करण पर वापस जाना।

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

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

लेकिन, यदि आपने कैलेंडर नहीं देखा है, तो 90 का दशक लगभग 30 साल पहले था। अब सब कुछ थोड़ा अलग ढंग से हो रहा है. और उस त्रासदी के पैमाने की कल्पना करने की कोशिश करें जब वे आपसे कहते हैं: “हमने उत्पादन शुरू किया, लेकिन वहां कुछ गलत हो गया। यहां आपका एफ़टीपी लॉगिन और पासवर्ड है, उत्पादन से कनेक्ट करें और इसे तुरंत वहां ठीक करें।" यदि आप चक नॉरिस हैं, तो यह काम करेगा। यदि नहीं, तो आप जोखिम उठाते हैं कि यदि आप एक बग ठीक करते हैं, तो आप 10 और बग बना देंगे। यही कारण है कि पिछले संस्करण पर वापस जाने का यह अभ्यास आपको बहुत कुछ हासिल करने की अनुमति देता है।

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

आइए अब किसी तरह पिछली दो प्रथाओं को एक साथ मिलाने का प्रयास करें। हमें रिलीज़ प्रबंधन नामक एक तीसरा मिलेगा।

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

इसके अलावा एक और दुख है. जब आप निर्माण करते हैं, भले ही एक ही मशीन पर, आप समान स्रोतों का निर्माण करेंगे, तब भी आपको कोई गारंटी नहीं है कि यह मशीन उसी स्थिति में है जैसी कि पिछले निर्माण के दौरान थी।

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

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

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

फिर हम इसे लेते हैं और स्वचालित रूप से इसे देव वातावरण में तैनात करते हैं। हम वहां दौड़ लगाते हैं, और अगर सब कुछ अच्छा रहा, तो हम मंच पर तैनात हो जाते हैं। यदि सब कुछ ठीक है, तो हम उसी संग्रह को उत्पादन में तैनात करते हैं, वही बायनेरिज़, बिल्कुल एक बार संकलित।

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

एक और बढ़िया प्रथा है. आप और मैं सभी समझते हैं कि जब हम अपने एप्लिकेशन को पिछले संस्करण में वापस लाते हैं, तो इसका मतलब यह हो सकता है कि हमें पिछले संस्करण के बुनियादी ढांचे की भी आवश्यकता है।

जब हम वर्चुअल इन्फ्रास्ट्रक्चर के बारे में बात करते हैं, तो बहुत से लोग सोचते हैं कि यह कुछ ऐसा है जिसे व्यवस्थापक स्थापित करते हैं। और यदि आपको, मान लीजिए, एक नया सर्वर प्राप्त करने की आवश्यकता है, जिस पर आप अपने एप्लिकेशन के नए संस्करण का परीक्षण करना चाहते हैं, तो आपको व्यवस्थापकों या डेवॉप्स को एक टिकट लिखना होगा। इसके लिए डेवोप्स को 3 सप्ताह का समय लगेगा। और 3 सप्ताह के बाद वे आपको बताएंगे कि हमने आपके लिए एक वर्चुअल मशीन स्थापित की है, जिसमें एक कोर, दो गीगाबाइट रैम और डॉटनेट के बिना एक विंडोज सर्वर है। आप कहते हैं: "लेकिन मुझे डॉटनेट चाहिए था।" वे: "ठीक है, 3 सप्ताह में वापस आएँ।"

विचार यह है कि इन्फ्रास्ट्रक्चर को कोड प्रथाओं के रूप में उपयोग करके, आप अपने वर्चुअल इन्फ्रास्ट्रक्चर को सिर्फ एक अन्य संसाधन के रूप में मान सकते हैं।

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

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

अगला अभ्यास, जो मौजूद भी है और महत्वपूर्ण भी है, लेकिन जिसका उपयोग बहुत कम लोग करते हैं, वह है एप्लिकेशन प्रदर्शन मॉनिटरिंग।

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

अच्छे तरीके से, लगभग हर बिल्ड पर एप्लिकेशन प्रदर्शन मॉनिटरिंग करना अच्छा होगा, हालाँकि, जैसा कि आप समझते हैं, यह हमेशा संभव नहीं होता है। लेकिन, कम से कम, इसे प्रत्येक रिलीज़ के लिए लागू करने की आवश्यकता है।

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

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

हमारा अगला अभ्यास कॉन्फ़िगरेशन प्रबंधन अभ्यास है। बहुत कम लोग हैं जो इसे गंभीरता से लेते हैं. लेकिन यकीन मानिए, यह वास्तव में बहुत गंभीर बात है।

हाल ही में एक मजेदार किस्सा हुआ. लोग मेरे पास आए और कहा: "हमारे एप्लिकेशन का सुरक्षा ऑडिट करने में हमारी सहायता करें।" हमने बहुत देर तक एक साथ कोड देखा, उन्होंने मुझे एप्लिकेशन के बारे में बताया, चित्र बनाए। और प्लस या माइनस सब कुछ तार्किक, समझने योग्य, सुरक्षित था, लेकिन एक था लेकिन! उनके स्रोत नियंत्रण में कॉन्फ़िगरेशन फ़ाइलें थीं, जिनमें आईपी डेटाबेस के साथ उत्पादन, इन डेटाबेस से कनेक्ट करने के लिए लॉगिन और पासवर्ड आदि शामिल थे।

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

विन्यास प्रबंधन। अलग-अलग वातावरण में हमारे पास अलग-अलग कॉन्फ़िगरेशन हो सकते हैं। उदाहरण के लिए, हमारे पास QA, डेमो, उत्पादन वातावरण आदि के लिए डेटाबेस के लिए अलग-अलग लॉगिन और पासवर्ड हो सकते हैं।

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

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

और आखिरी अभ्यास जिसके बारे में मैं बात करना चाहूंगा वह एक ऐसा अभ्यास है जो बादलों से बहुत-बहुत संबंधित है। और यदि आप क्लाउड में काम करते हैं तो यह अधिकतम प्रभाव लाता है। यह आपके परिवेश का स्वचालित निष्कासन है.

मैं जानता हूं कि इस सम्मेलन में जिन टीमों के साथ मैं काम करता हूं उनमें से कई लोग हैं। और जिन सभी टीमों के साथ मैं काम करता हूं, हम इस अभ्यास का उपयोग करते हैं।

क्यों? बेशक, यह बहुत अच्छा होगा यदि प्रत्येक डेवलपर के पास एक वर्चुअल मशीन हो जो 24/7 काम करेगी। लेकिन शायद यह आपके लिए खबर है, शायद आपने ध्यान नहीं दिया, लेकिन डेवलपर खुद 24/7 काम नहीं करता है। एक डेवलपर आमतौर पर प्रतिदिन 8 घंटे काम करता है। यहां तक ​​कि अगर वह काम पर जल्दी आते हैं, तो उनके पास एक बड़ा लंच होता है, जिसके दौरान वह जिम जाते हैं। इसे प्रतिदिन 12 घंटे होने दें जब डेवलपर वास्तव में इन संसाधनों का उपयोग करता है। हमारे विधान के अनुसार, सप्ताह में 5 में से 7 दिन कार्य दिवस माने जाते हैं।

तदनुसार, सप्ताह के दिनों में यह मशीन 24 घंटे नहीं, बल्कि केवल 12 घंटे काम करनी चाहिए, और सप्ताहांत पर यह मशीन बिल्कुल भी काम नहीं करनी चाहिए। ऐसा लगेगा कि सब कुछ बहुत सरल है, लेकिन यहां क्या कहना महत्वपूर्ण है? इस मूल अनुसूची पर इस सरल अभ्यास को लागू करने से, यह आपको इन वातावरणों को बनाए रखने की लागत को 70% तक कम करने की अनुमति देता है, यानी आपने अपने विकास, क्यूए, डेमो, पर्यावरण की कीमत ली और इसे 3 से विभाजित किया।

सवाल यह है कि बाकी पैसों का क्या करें? उदाहरण के लिए, डेवलपर्स को ReSharper खरीदना चाहिए यदि उन्होंने पहले से नहीं खरीदा है। या कॉकटेल पार्टी करें. यदि आपके पास पहले एक ऐसा वातावरण था जिसमें देव और क्यूए दोनों चरते थे, और बस इतना ही, अब आप 3 अलग-अलग वातावरण बना सकते हैं जो अलग-थलग होंगे, और लोग एक-दूसरे के साथ हस्तक्षेप नहीं करेंगे।

निरंतर प्रदर्शन माप के साथ स्लाइड के संबंध में, हम प्रदर्शन की तुलना कैसे कर सकते हैं यदि हमारे पास प्रोजेक्ट में डेटाबेस में 1 रिकॉर्ड थे, दो महीने बाद दस लाख हैं? कैसे समझें कि प्रदर्शन को मापने का मतलब क्यों और क्या है?

यह एक अच्छा प्रश्न है, क्योंकि आपको हमेशा समान संसाधनों पर प्रदर्शन को मापना चाहिए। यानी, आप नया कोड जारी करते हैं, आप नए कोड पर प्रदर्शन मापते हैं। उदाहरण के लिए, आपको विभिन्न प्रदर्शन परिदृश्यों का परीक्षण करने की आवश्यकता है, मान लें कि आप यह परीक्षण करना चाहते हैं कि एप्लिकेशन हल्के लोड पर कैसा प्रदर्शन करता है, जहां 1 उपयोगकर्ता हैं और डेटाबेस का आकार 000 गीगाबाइट है। आपने इसे मापा और संख्याएँ प्राप्त कीं। आगे हम एक और परिदृश्य लेते हैं। उदाहरण के लिए, 5 उपयोगकर्ता, डेटाबेस का आकार 5 टेराबाइट। हमने परिणाम प्राप्त किये और उन्हें याद रखा।

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

क्या हम एक विशेष परीक्षण वातावरण में प्रदर्शन को मापने के बारे में बात कर रहे हैं? यानी यह उत्पादन नहीं है?

हां, यह उत्पादन नहीं है, यह एक परीक्षण वातावरण है, जो हमेशा समान होता है ताकि आप इसकी तुलना पिछले मापों से कर सकें।

मिल गया, धन्यवाद!

यदि कोई प्रश्न न हो, तो मुझे लगता है कि हम समाप्त कर सकते हैं। धन्यवाद!

स्रोत: www.habr.com