विकासकर्ताहरूको लागि उत्तम DevOps अभ्यासहरू। एन्टोन बोयको (२०१७)

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

मलाई आफ्नो परिचय दिनुहोस्, म पूर्ण रूपमा स्वीकार गर्छु कि कोठामा त्यहाँ मानिसहरू छन् जसले मलाई चिन्दैनन्। मेरो नाम एन्टोन बोयको हो, म एक Microsoft Azure MVP हुँ। MVP भनेको के हो? यो मोडेल-दृश्य-प्रस्तुतकर्ता हो। मोडल-दृश्य-प्रस्तुतकर्ता ठ्याक्कै म हुँ।

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

मेरो बारेमा केहि शब्दहरू:

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

एजेन्डाको बारेमा थोरै कुरा गरौं। हाम्रो एजेन्डा धेरै सरल छ:

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

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

हुनसक्छ, यदि तपाईंले DevOps र सञ्चालन विभागहरूमा यसलाई स्पष्ट रूपमा महसुस गर्न सक्नुभएन भने, तपाईंले Dev र QA विभागहरूसँग समानता बनाउन सक्नुहुन्छ। त्यहाँ सफ्टवेयर विकास गर्ने व्यक्तिहरू छन् र त्यहाँ QA व्यक्तिहरू छन् जो विकासकर्ताहरूको दृष्टिकोणबाट खराब छन्। उदाहरणका लागि, म मेरो अद्भुत कोड भण्डारमा पठाउँछु, र त्यहाँ केही बदमाश बसेका छन् जसले मलाई यो कोड फर्काउँछ र भन्छ कि तपाईंको कोड खराब छ।

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

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

र जब हामी DevOps को बारेमा कुरा गर्छौं, कसैले तपाईंलाई DevOps त्यो हो जब परियोजनाको निरन्तर एकीकरण हुन्छ; यदि परियोजनाले "कोडको रूपमा पूर्वाधार" अभ्यास लागू गर्दछ भने, कसैले DevOps भन्नेछ। कसैले भन्नेछ कि DevOps को पहिलो चरण सुविधा शाखा, सुविधा झण्डा हो।

मूलतः, यो सबै आफ्नै तरिकामा सत्य हो। तर यी हामीसँग भएका अन्तिम अभ्यासहरू मात्र हुन्। यी अभ्यासहरूमा जानु अघि, म यो स्लाइड हेर्न सुझाव दिन्छु, जसले तपाईंको कम्पनीमा, तपाईंको परियोजनामा ​​Dev-Ops पद्धति लागू गर्ने 3 चरणहरू देखाउँछ।

यो स्लाइडको दोस्रो अनौपचारिक नाम पनि छ। तपाईं DevOps को 3 Musketeers के हो पत्ता लगाउन अनलाइन खोजी गर्न सक्नुहुन्छ। यो सम्भव छ कि तपाईंले यो लेख पाउनुहुनेछ। किन 3 Musketeers? तल यसले भन्छ: मानिसहरू, प्रक्रियाहरू र उत्पादनहरू, अर्थात्। PPP - पोर्थोस, पोर्थोस र पोर्थोस। यहाँ DevOps को 3 Musketeers छन्। यस लेखले यो किन महत्त्वपूर्ण छ र यसले के समावेश गर्दछ भनेर थप विवरणमा वर्णन गर्दछ।

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

सुरुमा मानिसहरूसँग कुरा गर्नुपर्छ। र तपाईंले मानिसहरूलाई यो के हो र तिनीहरूले यसबाट केही फाइदाहरू कसरी प्राप्त गर्न सक्छन् भनेर व्याख्या गर्न आवश्यक छ।

हाम्रो सम्मेलनलाई DotNet Fest भनिन्छ। र आयोजकहरूले मलाई भनेजस्तै, हामीले मुख्यतया यहाँ विकासकर्ताहरूको दर्शकहरूलाई आमन्त्रित गर्यौं, त्यसैले मलाई आशा छ कि हलका अधिकांश मानिसहरू विकासमा संलग्न छन्।

हामी मानिसहरूको बारेमा कुरा गर्नेछौं, हामी विकासकर्ताहरूले हरेक दिन के गर्न चाहन्छन् भन्ने कुरा गर्नेछौं। तिनीहरू सबैभन्दा के चाहन्छन्? तिनीहरू केही नयाँ कोड लेख्न, नयाँ फ्याङ्गल्ड फ्रेमवर्कहरू प्रयोग गर्न, नयाँ सुविधाहरू सिर्जना गर्न चाहन्छन्। विकासकर्ताहरू कम्तीमा के चाहन्छन्? पुराना बगहरू ठीक गर्नुहोस्। म आशा गर्छु कि तपाईं मसँग सहमत हुनुहुन्छ। विकासकर्ताहरूले चाहेको यही हो। तिनीहरू नयाँ सुविधाहरू लेख्न चाहन्छन्, तिनीहरू बगहरू ठीक गर्न चाहँदैनन्।

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

QAs ले सबैभन्दा धेरै के चाहन्छ? मलाई थाहा छैन उनीहरू हलमा छन् कि छैनन्। म QA चाहन्छु भन्नु मेरो लागि गाह्रो छ, किनकि म कहिल्यै एक भएको छैन। र केटाहरूलाई कुनै अपमान छैन, यो भनिन्छ कि मलाई आशा छ कि म कहिल्यै गर्नेछैन। तर म उनीहरुको कामलाई अर्थहीन र व्यर्थ ठान्छु भन्ने कारणले होइन, तर म आफूलाई यो काम कुशलतापूर्वक गर्न सक्ने व्यक्ति ठान्दिनँ, त्यसैले म त्यो काम गर्ने प्रयास पनि गर्दिनँ । तर मैले बुझेको कुराबाट, QA ले धेरैलाई मन नपर्ने कुरा बिहान काम गर्न जाँदैछ, निरन्तर केही प्रकारको रिग्रेसन परीक्षणहरू चलाउँदै, उही बगहरूमा स्टेप गर्दै जुन उनीहरूले 3 स्प्रिन्ट अघि विकासकर्ताहरूलाई रिपोर्ट गरेका थिए र यसो भने: “तिमी कहिले? , Monsieur D 'Artagnan, यो बग समाधान गर्नुहोस्।' र Monsieur D'Artagnan उसलाई जवाफ दिनुहुन्छ: "हो, हो, हो, मैले पहिले नै ठीक गरिसकेको छु।" र यो कसरी हुन्छ कि मैले एउटा बग फिक्स गरें र बाटोमा 5 बनाएँ।

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

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

र केवल जब तपाइँका प्रक्रियाहरू औपचारिक हुन्छन्, तपाइँ उत्पादनहरू चयन गर्न सुरु गर्नुहुन्छ जसले तपाइँलाई यी प्रक्रियाहरू स्वचालित गर्न मद्दत गर्दछ।

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

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

सामान्यतया DevOps अभ्यासहरूको बारेमा कुरा गरौं। तिनीहरू के हुन? के फरक छ? तिनीहरूलाई कसरी प्रयास गर्ने? तिनीहरू किन महत्त्वपूर्ण छन्?

तपाईंले सुन्नु भएको पहिलो अभ्यासलाई निरन्तर एकीकरण भनिन्छ। हुनसक्छ परियोजनामा ​​​​कसैसँग निरन्तर एकीकरण (CI) छ।

सबैभन्दा ठूलो समस्या यो हो कि प्रायः जब म एक व्यक्तिलाई सोध्छु: "के तपाइँसँग परियोजनामा ​​CI छ?" र उसले भन्यो: "हो," तब जब मैले उसले के गर्छ भनेर सोध्छु, उसले मलाई सम्पूर्ण स्वचालन प्रक्रियाको वर्णन गर्छ। यो पूरै सत्य होइन।

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

CI को साथमा, त्यहाँ सामान्यतया अन्य अभ्यासहरू छन् - जस्तै निरन्तर तैनाती, रिलीज व्यवस्थापन, तर हामी यसको बारेमा पछि कुरा गर्नेछौं।

CI आफैले हामीलाई बताउँछ कि विभिन्न व्यक्तिहरूले कोड लेख्छन् र यो कोड लगातार एकल कोड आधारमा एकीकृत हुनुपर्छ।

यसले हामीलाई के दिन्छ र यो किन महत्त्वपूर्ण छ? यदि हामीसँग DotNet छ भने, त्यो राम्रो छ, यो एक संकलित भाषा हो, हामी हाम्रो अनुप्रयोग कम्पाइल गर्न सक्छौं। यदि यो कम्पाइल हुन्छ भने, यो पहिले नै राम्रो संकेत हो। यो अझै केहि मतलब छैन, तर यो पहिलो राम्रो संकेत हो कि हामी कम्तिमा कम्पाइल गर्न सक्छौं।

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

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

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

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

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

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

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

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

हामीले यस अभ्यासको सफलता वा असफलता कसरी नाप्न सक्छौं? हामीले CI परियोजनामा ​​के लागू गर्‍यौं भनेर तपाईंले ठूला मालिकलाई रिपोर्ट गर्नुभयो भने, उहाँले ब्ला ब्ला ब्ला सुन्नुहुन्छ। हामीले यसलाई कार्यान्वयन गर्‍यौं, ठीक छ, तर किन, यसले हामीलाई के ल्यायो, हामी यसलाई कसरी मापन गर्छौं, हामी यसलाई कत्तिको सही वा गलत रूपमा कार्यान्वयन गर्दैछौं?

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

हामीसँग भएको अर्को अभ्यास भनेको स्वचालन परीक्षण अभ्यास हो, जुन प्रायः CI अभ्याससँग आउँछ। हात मिलाएर जान्छन् ।

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

हामीसँग एकीकरण परीक्षणहरू पनि छन् जसले हामीलाई विभिन्न मोड्युलहरू कसरी एकअर्कासँग एकीकृत हुन्छन् भनेर बुझ्न अनुमति दिन्छ। यो पनि राम्रो छ।

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

तपाइँले चलाउनुहुने विशिष्ट परीक्षणहरूले तपाइँ कति पटक चलाउनुहुने प्रभाव पार्न सक्छ। एकाइ परीक्षण सामान्यतया छोटो र सानो लेखिएको छ। र तिनीहरू नियमित रूपमा सुरू गर्न सकिन्छ।

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

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

र हामीले उनीहरूलाई भन्यौं कि यदि तपाईं थप उत्पादक बन्न चाहनुहुन्छ भने, स्वचालित परीक्षण अभ्यासहरू लागू गर्नु तपाईंको लागि अर्थपूर्ण छ, किनकि यही कुराले तपाईंलाई अहिले नै दुख दिन्छ।

निरन्तर परिनियोजन अभ्यास गर्नुहोस्। राम्रो, तपाईंले निर्माण गर्नुभयो। यो पहिले नै राम्रो छ। तपाईंको कोड कम्पाइल गरिएको छ। अब यो केहि वातावरण मा यो निर्माण तैनात गर्न राम्रो हुनेछ। विकासकर्ताहरूको लागि वातावरणमा भनौं।

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

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

साथै, जब तपाइँ एक अर्का बीच कोड एकीकृत गर्नुहुन्छ, i.e. आदेश बीच, यसले तपाईंलाई यो UI मा कस्तो देखिन्छ भनेर हेर्न अनुमति दिन्छ।

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

हामीसँग भएको अर्को अभ्यास भनेको स्वचालित पुनर्स्थापनाको अभ्यास हो, अर्थात् एप्लिकेसनको अघिल्लो संस्करणमा फिर्ता गर्ने।

विकासकर्ताहरूको लागि यो किन महत्त्वपूर्ण छ? त्यहाँ अझै पनि छन् जसले टाढा, टाढाको 90 को दशक सम्झन्छ, जब कम्प्युटरहरू ठूला थिए र प्रोग्रामहरू साना थिए। र वेब विकासको एक मात्र तरिका PHP मार्फत थियो। यो होइन कि PHP खराब भाषा हो, यद्यपि यो हो।

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

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

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

अब कुनै न कुनै रूपमा दुई अघिल्लो अभ्यासहरू संयोजन गर्ने प्रयास गरौं। हामी रिलीज व्यवस्थापन भनिने तेस्रो प्राप्त गर्नेछौं।

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

यसबाहेक, अर्को दुःख छ। जब तपाइँ निर्माण गर्नुहुन्छ, एउटै मेसिनमा पनि, तपाइँ उही स्रोतहरू निर्माण गर्नुहुनेछ, तपाइँसँग अझै पनि यो मेसिन उही अवस्थामा छ भन्ने कुनै ग्यारेन्टी छैन जुन यो पछिल्लो निर्माणको समयमा थियो।

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

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

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

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

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

त्यहाँ अर्को ठूलो अभ्यास छ। तपाईं र म सबै बुझ्छौं कि जब हामी हाम्रा एप्लिकेसनहरू अघिल्लो संस्करणमा रोल ब्याक गर्छौं, यसको मतलब यो हुन सक्छ कि हामीलाई अघिल्लो संस्करणको पूर्वाधार पनि चाहिन्छ।

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

विचार भनेको पूर्वाधारलाई कोड अभ्यासको रूपमा प्रयोग गरेर, तपाईंले आफ्नो भर्चुअल पूर्वाधारलाई अर्को स्रोतको रूपमा व्यवहार गर्न सक्नुहुन्छ।

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

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

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

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

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

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

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

हामीसँग अर्को अभ्यास कन्फिगरेसन व्यवस्थापन अभ्यास हो। यसलाई गम्भीरतापूर्वक लिनेहरू थोरै छन्। तर मलाई विश्वास गर्नुहोस्, यो वास्तवमा धेरै गम्भीर कुरा हो।

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

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

कन्फिगरेसन व्यवस्थापन। हामीसँग फरक वातावरणमा फरक कन्फिगरेसन हुन सक्छ। उदाहरणका लागि, हामीसँग QA, डेमो, उत्पादन वातावरण, आदिका लागि डाटाबेसहरूका लागि फरक-फरक लगइनहरू र पासवर्डहरू हुन सक्छन्।

यो कन्फिगरेसन पनि स्वचालित हुन सक्छ। यो सँधै अनुप्रयोगबाट अलग हुनुपर्छ। किन? किनभने तपाईंले एक पटक एप्लिकेसन बनाउनुभयो, र त्यसपछि एप्लिकेसनले वास्ता गर्दैन कि तपाईं SQL सर्भरमा यस्तो र त्यस्तो IP वा यस्तो र त्यस्तो IP मार्फत जडान गर्नुहुन्छ, यसले समान काम गर्नुपर्छ। तसर्थ, यदि तपाईं मध्ये एक जनाले कोडमा जडान स्ट्रिङलाई हार्डकोड गरिरहनुभएको छ भने, तब सम्झनुहोस् कि म तपाईंलाई फेला पार्नेछु र सजाय दिनेछु यदि तपाईं मसँग एउटै परियोजनामा ​​हुनुहुन्छ भने। यो सधैं एक अलग कन्फिगरेसन मा राखिएको छ, उदाहरण को लागी, web.config मा।

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

र अन्तिम अभ्यास जसको बारेमा म कुरा गर्न चाहन्छु त्यो अभ्यास हो जुन धेरै, धेरै बादलहरूसँग सम्बन्धित छ। र यदि तपाइँ क्लाउडमा काम गर्नुहुन्छ भने यसले अधिकतम प्रभाव ल्याउँछ। यो तपाइँको वातावरण को स्वचालित हटाउने छ।

मलाई थाहा छ यस सम्मेलनमा मैले काम गर्ने टोलीहरूबाट धेरै व्यक्तिहरू छन्। र मैले काम गर्ने सबै टोलीहरूसँग, हामी यो अभ्यास प्रयोग गर्छौं।

किन? अवश्य पनि, यदि प्रत्येक विकासकर्तासँग 24/7 काम गर्ने भर्चुअल मेसिन छ भने यो राम्रो हुनेछ। तर सायद यो तपाईलाई खबर हो, सायद तपाईले ध्यान दिनुभएन, तर विकासकर्ता आफैले 24/7 काम गर्दैन। एक विकासकर्ता सामान्यतया दिनको 8 घण्टा काम गर्दछ। यदि उहाँ चाँडै काम गर्न आउनुभयो भने, उहाँ एक ठूलो खाजा गर्नुहुन्छ जुन समयमा उहाँ जिम जानुहुन्छ। विकासकर्ताले वास्तवमा यी स्रोतहरू प्रयोग गर्दा दिनको १२ घण्टा हुन दिनुहोस्। हाम्रो कानून अनुसार, हामीसँग हप्ताको 12 मध्ये 5 दिनहरू छन् जुन कामका दिनहरू मानिन्छ।

तदनुसार, हप्ताको दिनमा यो मेसिनले 24 घण्टा काम गर्नु हुँदैन, तर 12 मात्र, र सप्ताहन्तमा यो मेसिनले काम गर्नु हुँदैन। यो सबै धेरै सरल छ जस्तो देखिन्छ, तर यहाँ के भन्न महत्त्वपूर्ण छ? यस आधारभूत तालिकामा यो सरल अभ्यास लागू गरेर, यसले तपाईंलाई यी वातावरणहरू कायम राख्ने लागतलाई ७०% कम गर्न अनुमति दिन्छ, अर्थात् तपाईंले आफ्नो dev, QA, डेमो, वातावरणको मूल्य लिनुभयो र यसलाई 70 ले विभाजित गर्नुभयो।

प्रश्न उठ्छ, बाँकी रकम के गर्ने ? उदाहरणका लागि, विकासकर्ताहरूले ReSharper किन्नु पर्छ यदि तिनीहरूसँग पहिले नै छैन। वा ककटेल पार्टी गर्नुहोस्। यदि तपाईंसँग पहिले एउटै वातावरण थियो जसमा dev र QA दुबै चर्छन्, र त्यो हो, अब तपाईंले 3 फरक बनाउन सक्नुहुन्छ जुन अलग हुनेछ, र मानिसहरूले एकअर्कासँग हस्तक्षेप गर्दैनन्।

निरन्तर कार्यसम्पादन मापनको साथ स्लाइडको सन्दर्भमा, यदि हामीसँग परियोजनाको डाटाबेसमा 1 रेकर्डहरू थिए भने, दुई महिना पछि त्यहाँ एक लाख छन् भने हामी कसरी प्रदर्शन तुलना गर्न सक्छौं? कार्यसम्पादन नाप्ने बिन्दु किन र के हो भनेर कसरी बुझ्ने?

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

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

के हामी एक विशेष परीक्षण वातावरण मा प्रदर्शन मापन को बारे मा कुरा गर्दै हुनुहुन्छ? अर्थात् यो उत्पादन होइन ?

हो, यो उत्पादन होइन, यो एक परीक्षण वातावरण हो, जुन सधैं उस्तै हुन्छ ताकि तपाईं यसलाई अघिल्लो मापनसँग तुलना गर्न सक्नुहुन्छ।

बुझियो धन्यवाद!

यदि कुनै प्रश्नहरू छैनन् भने, मलाई लाग्छ कि हामी समाप्त गर्न सक्छौं। धन्यवाद!

स्रोत: www.habr.com