अभ्यासको रूपमा निरन्तर एकीकरण, जेनकिन्स होइन। Andrey Alexandrov

किन CI उपकरणहरू र CI पूर्ण रूपमा फरक चीजहरू छन् छलफल गरौं।

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

निरन्तर एकीकरणको बारेमा रिपोर्ट बनाउने विचार एक वर्ष पहिले देखा पर्‍यो, जब म अन्तर्वार्ताका लागि जाँदै थिएँ र जागिर खोज्दै थिएँ। मैले 10-15 कम्पनीहरूसँग कुरा गरें, तिनीहरूमध्ये एउटाले मात्र CI के हो भनेर स्पष्ट रूपमा जवाफ दिन र उनीहरूसँग यो नभएको महसुस कसरी भयो भनेर व्याख्या गर्न सक्षम थिए। बाँकी जेन्किन्सको बारेमा बुझ्न नसकिने बकवास कुरा गरिरहेका थिए :) खैर, हामीसँग जेनकिन्स छ, यसले निर्माण गर्छ, CI! रिपोर्टको बखत, म निरन्तर एकीकरण वास्तवमा के हो र किन जेन्किन्स र समान उपकरणहरूसँग यससँग धेरै कमजोर सम्बन्ध छ भनेर व्याख्या गर्ने प्रयास गर्नेछु।

त्यसोभए, तपाईले CI शब्द सुन्नुभयो भने सामान्यतया के दिमागमा आउँछ? धेरै मानिसहरू जेनकिन्स, Gitlab CI, Travis, आदि बारे सोच्नेछन्।

हामीले यसलाई गुगल गरे पनि, यसले हामीलाई यी उपकरणहरू दिनेछ।

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

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

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

र तिनीहरूले एक टोलीको रूपमा सँगै काम गर्ने पीडा समाधान गरे!

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

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

एकले सुविधा छिटो समाप्त गर्यो र यसलाई मास्टरमा मर्ज गर्यो।

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

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

त्यहाँ अलि फरक मामला छ। हामीसँग एक मास्टर र केहि विकासकर्ताहरू छन्।

तिनीहरूले एउटा टुक्रा बनाए।

एक मरे, सबै ठीक थियो, उसले काम पास गर्यो।

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

यस समयमा, दोस्रो विकासकर्ताले अरू केहि गरे।

पहिलोले तेस्रो कार्य पूरा गर्यो।

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

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

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

सँगै केहि गर्नु पीडादायी छ! हामी सधैं एकअर्काको बाटोमा आउँछौं।

यो समस्या 20 वर्ष भन्दा बढी पहिले देखाइएको थियो। मैले चरम प्रोग्रामिङमा निरन्तर एकीकरणको अभ्यासको पहिलो उल्लेख फेला पारे।

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

अब हामी "निरन्तर एकीकरण" वाक्यांशलाई व्यक्तिगत रूपमा विश्लेषण गर्नेछौं। यदि हामीले यसलाई सीधा अनुवाद गर्छौं भने, हामी निरन्तर एकीकरण पाउँछौं। तर यो कत्तिको निरन्तर छ भन्ने स्पष्ट छैन; यो धेरै विरामी छ। तर यसमा कति एकीकरण छ भन्ने पनि स्पष्ट छैन।

र यसैले म तपाईलाई अहिले चरम प्रोग्रामिङबाट उद्धरणहरू दिँदैछु। र हामी दुबै शब्दहरू अलग-अलग विश्लेषण गर्नेछौं।

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

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

सामान्यतया, एकीकरण भनेको तपाईको कोड लिनु र यसलाई मास्टरमा तान्नु हो।

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

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

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

तपाईं तिनीहरूलाई बिना गर्न सक्नुहुन्छ। यसले तपाईंलाई कत्ति पनि हानि गर्दैन। किनभने अभ्यासको लक्ष्य भनेको सकेसम्म प्रायः मापन गर्नु हो, ताकि भविष्यमा कुनै पनि द्वन्द्वहरूमा ठूलो मात्रामा समय बर्बाद नगर्नुहोस्।

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

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

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

तर के हामीसँग अहिले कुनै सान्दर्भिक प्रमाणहरू छन् जसले हामीलाई यस अभ्यासमा लगानी गर्नु अर्थपूर्ण छ भनेर बताउँछ?

मेरो दिमागमा आएको पहिलो कुरा DevOps को राज्य थियो। यो एक अध्ययन हो जुन केटाहरूले 7 वर्षदेखि सञ्चालन गर्दै आएका छन्। अब तिनीहरूले यसलाई एक स्वतन्त्र संस्थाको रूपमा गर्छन्, तर Google अन्तर्गत।

र तिनीहरूको 2018 अध्ययनले छोटो अवधिका शाखाहरू प्रयोग गर्ने प्रयास गर्ने कम्पनीहरू बीचको सम्बन्ध देखाएको छ जुन द्रुत रूपमा एकीकृत हुन्छ, बारम्बार एकीकृत हुन्छ, र राम्रो IT प्रदर्शन सूचकहरू छन्।

यी सूचकहरू के हुन्? यी 4 मेट्रिक्स हुन् जुन तिनीहरूले आफ्नो प्रश्नावलीमा सबै कम्पनीहरूबाट लिन्छन्: परिनियोजन फ्रिक्वेन्सी, परिवर्तनहरूको लागि नेतृत्व समय, सेवा पुनर्स्थापना गर्न समय, परिवर्तन असफलता दर।

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

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

यदि तपाइँको शाखा धेरै लामो समय सम्म रह्यो भने, यो अड्किन्छ, कुहिन्छ, र हामी यसलाई केहि प्रकारको परिवर्तन गर्न को लागी अधिक समय खर्च गर्न थाल्छौं।

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

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

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

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

यस्तो देखिन्छ कि हामी पहिले नै केहि गर्दैछौं, हामी पहिले नै मर्ज गर्दैछौं जस्तो देखिन्छ, तर हामी कसरी बुझ्न सक्छौं कि हामीसँग अझै पनि निरन्तर एकीकरण छ, हामी धेरै पटक मर्ज गर्दैछौं?

Jez Humble ह्यान्डबुक, Accelerate, Continuous Delivery वेबसाइट, र Continuous Delivery पुस्तकका लेखक हुन्। उहाँले यो परीक्षण प्रस्ताव:

• इन्जिनियरको कोड हरेक दिन मास्टरमा पुग्छ।
• प्रत्येक प्रतिबद्धताको लागि तपाईले एकाइ परीक्षण चलाउनुहुन्छ।
• मास्टर मा बिल्ड खस्यो, यो लगभग 10 मिनेट मा तय भयो।

उसले तपाइँसँग पर्याप्त अभ्यास छ भनेर सुनिश्चित गर्न यो जस्तै परीक्षण प्रयोग गर्न सुझाव दिन्छ।

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

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

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

यो निरन्तर एकीकरणको संक्षिप्त परिचय हो। यो अभ्यासमा यति मात्र छ। म प्रश्नहरूको लागि तयार छु।

म फेरि संक्षेपमा संक्षेप गर्नेछु:

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

तपाईंका प्रश्नहरू

गैर-विघटित कार्यहरू के गर्ने?

विघटन। समस्या के हो? एउटा कार्य छ र त्यो विघटित छैन भन्ने उदाहरण दिन सक्नुहुन्छ?

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

मैले तिमीलाई सहि बुझें भने केही ठूला र जटिल कार्य छन्, जसको नतिजा एक महिनामा मात्रै देखिने ?

हो त्यो सहि हो। हो, यो एक महिना भन्दा पहिले परिणाम मूल्याङ्कन गर्न सम्भव हुनेछ।

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

राम्रो। त्यसो भए के कुरा ?

हरेक दिन साना साना कुराहरू मार्नुको अर्थ के हो?

हो।

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

धन्यवाद, मुद्दा बन्द छ!

(ओलेग सोरोका) म थप्न सक्छु? तपाईंले सबै कुरा सहि भन्नुभयो, म केवल एउटा वाक्यांश थप्न चाहन्छु।

So.

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

हामीले 4 मेट्रिक्सको बारेमा कुरा गर्यौं जसले सफल कम्पनीहरूलाई पछि परेका कम्पनीहरूलाई छुट्याउन सक्छ। हामीले अझै पनि यी 4 मेट्रिक्स हेर्न बाँच्नु पर्छ। यदि तपाईंको औसत कार्य पूरा हुन एक महिना लाग्छ भने, त्यसपछि म पहिले यो मेट्रिकमा ध्यान केन्द्रित गर्नेछु। म यसलाई पहिले 3 दिनमा घटाउँछु। र त्यसपछि मैले निरन्तरको बारेमा सोच्न थाले।

कुनै पनि काम पूरा हुन एक महिना लाग्छ भने इन्जिनियरिङ अभ्यासमा लगानी गर्नुको कुनै अर्थ छैन भनी तपाईले सोच्नुहुन्छ भनेर के मैले तपाईलाई सही रूपमा बुझेको छु?

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

अनि तपाईसँग के विकल्प छ ? यदि तपाईंले कोड फिर्ता गर्नुभयो भने, त्यसपछि यो अद्यावधिक डाटाबेस संग काम गर्न सक्दैन।

आधार मात्र अगाडि बढ्छ, हो।

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

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

यस्ता सयौं अभ्यास छन् । म ट्रान्सबेस विकासको साथ सुरू गर्न सुझाव दिन्छु। उनी निरन्तर एकीकरणमा 100% छैनन्, तर अभ्यासहरू समान छन्, एक अर्को बिना राम्रोसँग बाँच्न सक्दैन।

के तपाईंले ट्रान्सबेस विकासलाई उदाहरणको रूपमा दिनुभयो जहाँ तपाईं अभ्यासहरू देख्न सक्नुहुन्छ वा मानिसहरूलाई ट्रान्सबेस डेभलपमेन्ट प्रयोग गर्न सुरु गर्न सुझाव दिनुहुन्छ?

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

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

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

च्याटबाट एउटा प्रश्न छ: "यदि समीक्षा अनिवार्य छ र लामो समय लाग्छ, सायद एक दिन वा बढी?"

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

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

4 मेट्रिक्सको सन्दर्भमा, म अझै पनि तिनीहरूलाई हटाउन सिफारिस गर्छु कि यसले के निम्त्याउँछ। नम्बरहरू हेर्नुहोस्, चित्र हेर्नुहोस्, सबै कति खराब छ।

(दिमित्री) म तपाईंसँग यस बारे छलफल गर्न तयार छु। संख्या र मेट्रिक्स सबै महान छन्, अभ्यास महान छन्। तर तपाईले बुझ्नु आवश्यक छ कि व्यवसायलाई यसको आवश्यकता छ कि छैन। त्यहाँ व्यवसायहरू छन् जुन परिवर्तनको त्यस प्रकारको गति आवश्यक पर्दैन। मलाई ती कम्पनीहरू थाहा छ जहाँ हरेक १५ मिनेटमा परिवर्तन गर्न सकिँदैन। र होइन किनभने तिनीहरू धेरै खराब छन्। यो यस्तो जीवन चक्र हो। र शाखाहरू सुविधा, टगल सुविधा बनाउन, तपाईंलाई गहिरो ज्ञान चाहिन्छ।

यो जटिल छ। यदि तपाइँ थप विवरणमा टगल सुविधाको बारेमा कथा पढ्न चाहनुहुन्छ भने, म यसलाई सिफारिस गर्दछु https://trunkbaseddevelopment.com/। र त्यहाँ टगल सुविधाहरूको बारेमा मार्टिन फाउलरको एक अद्भुत लेख छ: त्यहाँ के प्रकारहरू छन्, जीवन चक्र, आदि। टगल सुविधा जटिल छ।

र तपाईंले अझै पनि प्रश्नको जवाफ दिनुभएन: "जेनकिन्स आवश्यक छ वा छैन?"

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

त्यो हो, यदि तपाइँसँग अभ्यासहरू छन् भने, यसको मतलब तपाइँलाई यसको आवश्यकता छैन?

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

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

त्यो हुनुपर्ने होइन, यो राम्रो हुनेछ किनभने यसले जीवनलाई उस्तै सजिलो बनाउँछ। हामीले कोडसँग काम गर्ने बित्तिकै, bash स्क्रिप्टहरूसँग होइन, तर हामीसँग सामान्य कोड छ।

रोक्नुहोस्, रोक्नुहोस्, ब्यास स्क्रिप्ट पनि कोड हो। मेरो पुरानो मायालाई नछुनुहोस्।

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

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

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

यदि कसैलाई प्रश्न छ?

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

(ओलेग) हो, त्यो सहि हो। यो अभ्यास कुनै पनि अन्य गम्भीर संस्कृति-परिवर्तन अभ्यासको प्रयासमा तुलनात्मक छ। परास्त गर्न सबैभन्दा गाह्रो कुरा बानीहरू हुन्, विशेष गरी खराब बानीहरू। र यदि यो अभ्यास लागू गर्न, तपाईं वरपरका बानीहरूमा गम्भीर परिवर्तन आवश्यक छ: विकासकर्ताहरू, व्यवस्थापन, उत्पादन प्रबन्धक, त्यसपछि आश्चर्यहरू तपाईंलाई पर्खिरहेका छन्।

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

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

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

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

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

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

यहाँ तपाईं निष्कर्षमा पुग्नुहुन्छ कि तपाईंले पहिले के गर्न आवश्यक छ भनेर बुझ्नुपर्छ। संसार आदर्श छैन, र उत्पादन पनि आदर्श छैन।

हो, यी कुराहरू अन्तरसम्बन्धित छन्।

व्यवसायहरूले पनि सधैं बुझ्दैनन् कि उनीहरूले यस बाटो जान आवश्यक छ।

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

(दिमित्री) म च्याटबाट स्पष्टीकरण पढ्छु: "तर हामीलाई विभिन्न स्तरहरूमा धेरै परीक्षण कभरेज चाहिन्छ। परीक्षणका लागि कति समय छुट्याइएको छ? यो थोरै महँगो छ र धेरै समय लाग्छ।"

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

यहाँ तपाईं, अवश्य पनि, सुशोभित।

(दिमित्री) म यहाँ सहमत छैन। त्यहाँ एक अभ्यास छ - परीक्षण-संचालित विकास, जसले तपाईंलाई यसबाट बचाउनेछ।

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

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

र यसैले, तपाईले यो अवस्था कसरी प्राप्त गर्नुहुनेछ जब तपाई शुक्रबार साँझ तयार हुनुहुन्छ र घर जानुहुन्छ अर्को प्रश्न हो। सायद तपाईं केवल एक साहसी बदमाश हुनुहुन्छ।

निरन्तर एकीकरणमा अलिकति फर्कौं। हामी अलि फरक जटिल अभ्यासमा भाग्यौं।

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

त्यसैले यी भ्रमहरूबाट मुक्त हुन त्यति सजिलो छैन। MVP र परीक्षणहरू एकअर्काको विरोध गर्दैनन्। पनि, बरु, यसको विपरित, यदि तपाइँ TDD अभ्यास प्रयोग गरेर MVP गर्नुहुन्छ भने, तपाइँ यसलाई अभ्यास बिना नै, तर बलमा गर्नु भन्दा राम्रो र छिटो गर्नुहुनेछ।

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

(दिमित्री) यहाँ धेरै मानिसहरू, जब उनीहरूले MVP कल गर्छन्, मानिसहरू सामान्य कुरा लेख्न धेरै अल्छी हुन्छन्। र यी अझै पनि फरक चीजहरू छन्। MVP लाई केहि नराम्रो चीजमा परिणत गर्न आवश्यक छैन जुन काम गर्दैन।

हो, हो, तपाईं सहि हुनुहुन्छ।

र त्यसपछि अचानक MVP उत्पादनमा।

सँधै

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

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

(दिमित्री) हामी यस विचारलाई पूर्वाधार सञ्चालनको दृष्टिकोणबाट विस्तार गर्न सक्छौं। हामीले कुनै पनि नयाँ सुरुवात गर्नु अघि, हामी अनुगमन गर्छौं र त्यसपछि सुरु गर्छौं। यस अवस्थामा, अनुगमन हाम्रो लागि सामान्य परीक्षण हुन्छ। र अनुगमनबाट विकास हुन्छ । तर लगभग सबैले भन्छन् कि यो लामो छ, म अल्छी छु, मैले अस्थायी मस्यौदा बनाएको छु। यदि हामीले सामान्य अनुगमन गरेका छौं भने, हामी CI प्रणालीको अवस्था बुझ्छौं। र CI प्रणालीमा धेरै निगरानी छ। हामी प्रणालीको अवस्था बुझ्छौं, हामी भित्र के छ भनेर बुझ्छौं। र विकासको क्रममा, हामीले प्रणालीलाई इच्छित अवस्थामा पुग्ने गरी बनाइरहेका छौं।

यी अभ्यासहरू लामो समयदेखि ज्ञात छन्। हामीले करिब ४ वर्षअघि यस विषयमा छलफल गरेका थियौँ । तर 4 वर्षमा व्यावहारिक रूपमा केहि परिवर्तन भएको छैन।

तर यस नोटमा, म आधिकारिक छलफल समाप्त गर्न प्रस्ताव गर्दछु।

भिडियो (मिडिया तत्वको रूपमा सम्मिलित, तर केही कारणले काम गर्दैन):

https://youtu.be/zZ3qXVN3Oic

स्रोत: www.habr.com