एक अभ्यास के रूप में सतत एकीकरण, जेनकींस नहीं। एंड्री अलेक्जेंड्रोव

आइए चर्चा करें कि सीआई उपकरण और सीआई पूरी तरह से अलग चीजें क्यों हैं।

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

सतत एकीकरण के बारे में एक रिपोर्ट बनाने का विचार एक साल पहले आया, जब मैं साक्षात्कार के लिए जा रहा था और नौकरी की तलाश कर रहा था। मैंने 10-15 कंपनियों से बात की, उनमें से केवल एक ही स्पष्ट रूप से उत्तर देने में सक्षम थी कि सीआई क्या है और यह बताएं कि उन्हें कैसे एहसास हुआ कि उनके पास यह नहीं है। बाकी लोग जेनकींस के बारे में अस्पष्ट बकवास कर रहे थे :) ठीक है, हमारे पास जेनकींस है, यह बनाता है, सीआई! रिपोर्ट के दौरान, मैं यह समझाने की कोशिश करूंगा कि वास्तव में सतत एकीकरण क्या है और जेनकिंस और इसी तरह के उपकरणों का इसके साथ बहुत कमजोर संबंध क्यों है।

तो, जब आप सीआई शब्द सुनते हैं तो आमतौर पर आपके दिमाग में क्या आता है? अधिकांश लोग जेनकिंस, गिटलैब सीआई, ट्रैविस आदि के बारे में सोचेंगे।

अगर हम इसे गूगल भी करें तो यह हमें ये टूल देगा।

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

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

इससे पहले कि हम यह समझें कि एक पूर्ण सीआई कैसा दिखता है, आइए पहले उन लोगों के संदर्भ में उतरें जो इसे लेकर आए थे और उस दर्द को महसूस करें जिसे वे हल करने की कोशिश कर रहे थे।

और उन्होंने एक टीम के रूप में मिलकर काम करने की समस्या का समाधान कर लिया!

आइए टीमों में विकास करते समय डेवलपर्स द्वारा सामना की जाने वाली कठिनाइयों के उदाहरण देखें। यहां हमारे पास एक प्रोजेक्ट, गिट में एक मास्टर शाखा और दो डेवलपर्स हैं।

और वे काम पर चले गये जैसा कि हर कोई लंबे समय से आदी था। हमने चीजों की भव्य योजना में एक कार्य लिया, एक फीचर शाखा बनाई और कोड लिखा।

एक ने फीचर को तेजी से पूरा किया और इसे मास्टर में मर्ज कर दिया।

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

अपने फीचर को एक सामान्य मास्टर के साथ जोड़ना जितना कठिन होता है, उतना ही अधिक समय हम इस पर खर्च करते हैं। और मैंने इसे काफी सरल उदाहरण के साथ दिखाया। यह एक उदाहरण है जहां केवल 2 डेवलपर हैं। कल्पना कीजिए कि किसी कंपनी में 10 या 15 या 100 लोग एक रिपॉजिटरी को लिखते हैं। आप इन सभी झगड़ों को सुलझाने के लिए पागल हो जाएंगे।

थोड़ा अलग मामला है. हमारे पास एक मास्टर और कुछ डेवलपर हैं जो कुछ कर रहे हैं।

उन्होंने एक टहनी बनाई.

एक की मृत्यु हो गई, सब कुछ ठीक था, उसने कार्य पूरा कर लिया।

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

इस दौरान दूसरे डेवलपर ने कुछ और किया.

पहले वाले ने तीसरा कार्य पूरा किया।

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

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

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

एक साथ कुछ करना दर्दनाक है! हम हमेशा एक-दूसरे के रास्ते में आते हैं।

यह समस्या 20 साल से भी पहले देखी गई थी। मुझे एक्सट्रीम प्रोग्रामिंग में सतत एकीकरण के अभ्यास का पहला उल्लेख मिला।

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

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

और इसीलिए मैं अब आपको एक्सट्रीम प्रोग्रामिंग से उद्धरण दे रहा हूं। और हम दोनों शब्दों का अलग-अलग विश्लेषण करेंगे।

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

एकीकरण तब होता है जब हम अपनी शाखा लेते हैं और इसे मास्टर के साथ एकीकृत करते हैं, हम इसे विलय करते हैं। जब हम एक ट्रांसबेस डेवलपर होते हैं तो एक अंतिम विकल्प होता है, जहां हम यह सुनिश्चित करने का प्रयास करते हैं कि हम बिना किसी अतिरिक्त शाखा के तुरंत मास्टर को लिखें।

सामान्य तौर पर, एकीकरण का अर्थ है आपका कोड लेना और उसे मास्टर में खींचना।

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

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

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

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

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

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

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

लेकिन क्या अभी हमारे पास कोई प्रासंगिक सबूत है जो हमें बताता है कि इस अभ्यास में निवेश करना उचित है?

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

और उनके 2018 के अध्ययन ने उन कंपनियों के बीच एक सहसंबंध दिखाया जो अल्पकालिक शाखाओं का उपयोग करने की कोशिश करते हैं जो जल्दी से एकीकृत होती हैं, बार-बार एकीकृत होती हैं, और बेहतर आईटी प्रदर्शन संकेतक रखती हैं।

ये संकेतक क्या हैं? ये 4 मेट्रिक्स हैं जो वे अपनी प्रश्नावली में सभी कंपनियों से लेते हैं: तैनाती आवृत्ति, परिवर्तन के लिए लीड समय, सेवा बहाल करने का समय, परिवर्तन विफलता दर।

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

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

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

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

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

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

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

ऐसा लगता है कि हम पहले से ही कुछ कर रहे हैं, ऐसा लगता है कि हम पहले से ही विलय कर रहे हैं, लेकिन हम यह कैसे समझ सकते हैं कि हमारे पास अभी भी सतत एकीकरण है, कि हम अक्सर विलय कर रहे हैं?

जेज़ हम्बल हैंडबुक, एक्सीलरेट, कंटीन्यूअस डिलीवरी वेबसाइट और पुस्तक कंटीन्यूअस डिलीवरी के लेखक हैं। वह यह परीक्षण प्रदान करता है:

• इंजीनियर का कोड हर दिन मास्टर के पास पहुँचता है।
• प्रत्येक प्रतिबद्धता के लिए आप इकाई परीक्षण चलाते हैं।
• मास्टर में बिल्डिंग गिरी, करीब 10 मिनट में ठीक किया गया।

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

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

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

यूनिट परीक्षण केवल एक सहायक है जो आपको यह समझने में मदद करता है कि क्या आपका एकीकरण सफल रहा था और क्या कुछ भी टूटा नहीं था। मेरी राय में, यह भी पूरी तरह से अनिवार्य नहीं है, क्योंकि यह अभ्यास का विषय नहीं है।

यह सतत एकीकरण का संक्षिप्त परिचय है। इस अभ्यास में बस इतना ही है। मैं सवालों के लिए तैयार हूं.

मैं फिर से संक्षेप में संक्षेप में बताऊंगा:

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

सवाल

गैर-विघटित कार्यों का क्या करें?

विघटित करना। समस्या क्या है? क्या आप कोई उदाहरण दे सकते हैं कि कोई कार्य है और वह विघटित नहीं हुआ है?

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

अगर मैं आपकी बात ठीक से समझूं तो कोई बड़ा और जटिल काम है, जिसका नतीजा एक महीने में ही दिखने लगेगा?

हाँ यह सही है। हां, परिणाम का मूल्यांकन एक महीने से पहले नहीं करना संभव होगा।

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

अच्छा। तो फिर बात क्या है?

हर दिन छोटी-छोटी चीज़ों को मारने का क्या मतलब है?

हां.

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

धन्यवाद, मुद्दा बंद हो गया है!

(ओलेग सोरोका) क्या मैं जोड़ सकता हूँ? आपने सब कुछ सही कहा, मैं बस एक वाक्यांश जोड़ना चाहता हूं।

Так।

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

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

क्या मैंने आपको सही ढंग से समझा है कि आप सोचते हैं कि सामान्य तौर पर इंजीनियरिंग प्रथाओं में निवेश करने का कोई मतलब नहीं है यदि किसी कार्य को पूरा करने में एक महीने का समय लगता है?

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

और आपके पास क्या विकल्प है? यदि आप कोड को वापस रोल करते हैं, तो यह अब इस अद्यतन डेटाबेस के साथ काम नहीं कर सकता है।

आधार ही आगे बढ़ता है, हाँ।

जिन लोगों की इंजीनियरिंग प्रैक्टिस खराब है, उन्होंने संभवतः इसके बारे में मोटी किताब नहीं पढ़ी है... बैकअप के साथ क्या करें? यदि आप बैकअप से पुनर्स्थापित करते हैं, तो इसका मतलब है कि आप उस पल के दौरान जमा किया गया डेटा खो देते हैं। उदाहरण के लिए, हमने डेटाबेस के नए संस्करण, वहां पंजीकृत उपयोगकर्ताओं के साथ तीन घंटे तक काम किया। आप पुराने बैकअप को अस्वीकार कर देते हैं क्योंकि योजना नए संस्करण के साथ काम नहीं करती है, इसलिए आपने इन उपयोगकर्ताओं को खो दिया है। और वे असंतुष्ट हैं, कसम खाते हैं।

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

ऐसी सैकड़ों प्रथाएँ हैं। मैं ट्रांसबेस विकास से शुरुआत करने का सुझाव दूंगा। वह सतत एकीकरण पर 100% नहीं है, लेकिन प्रथाएं समान हैं, एक के बिना दूसरे का जीवन ठीक से नहीं चल सकता।

क्या आपने ट्रांसबेस विकास को एक उदाहरण के रूप में दिया जहां आप प्रथाओं को देख सकते हैं या क्या आप सुझाव देते हैं कि लोग ट्रांसबेस डेबेलोपमेंट का उपयोग शुरू करें?

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

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

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

चैट से एक प्रश्न है: "यदि समीक्षा अनिवार्य है और इसमें लंबा समय लगता है, शायद एक दिन या अधिक?"

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

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

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

(दिमित्री) मैं इस बारे में आपके साथ चर्चा करने के लिए तैयार हूं। संख्याएँ और मेट्रिक्स सभी बढ़िया हैं, प्रथाएँ बढ़िया हैं। लेकिन आपको यह समझने की जरूरत है कि क्या व्यवसाय को इसकी आवश्यकता है। ऐसे व्यवसाय हैं जिन्हें परिवर्तन की उस प्रकार की गति की आवश्यकता नहीं है। मैं ऐसी कंपनियों को जानता हूं जहां हर 15 मिनट में बदलाव नहीं किया जा सकता। और इसलिए नहीं कि वे बहुत बुरे हैं. यह एक ऐसा जीवन चक्र है. और शाखाओं की सुविधा, टॉगल सुविधा बनाने के लिए, आपको गहन ज्ञान की आवश्यकता है।

यह जटिल है। यदि आप टॉगल सुविधा के बारे में कहानी अधिक विस्तार से पढ़ना चाहते हैं, तो मैं इसकी अत्यधिक अनुशंसा करता हूं https://trunkbaseddevelopment.com/. और टॉगल सुविधाओं के बारे में मार्टिन फाउलर का एक अद्भुत लेख है: ये कितने प्रकार के होते हैं, जीवन चक्र आदि। टॉगल सुविधा जटिल है।

और आपने अभी भी इस प्रश्न का उत्तर नहीं दिया है: "क्या जेनकिंस की आवश्यकता है या नहीं?"

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

अर्थात्, यदि आपके पास अभ्यास हैं, तो क्या इसका मतलब यह है कि आपको इसकी आवश्यकता नहीं है?

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

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

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

रोकें, रोकें, एक बैश स्क्रिप्ट भी कोड है। मेरे पुराने प्यार को मत छुओ.

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

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

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

यदि किसी और के पास प्रश्न हों?

मेरा एक सवाल है। मैं ओलेग के साथ चर्चा जारी रखना चाहता हूं। सामान्य तौर पर, मुझे लगता है कि आप सही हैं, कि यदि किसी कार्य को पूरा होने में एक महीना लगता है, तो आपको वास्तुकला में समस्या है, आपको विश्लेषण, अपघटन, योजना आदि में समस्या है, लेकिन मुझे लगता है कि यदि आप शुरू करते हैं सतत एकीकरण के अनुसार जीने का प्रयास करें, तो आप योजना बनाकर दर्द को ठीक करना शुरू कर देंगे, क्योंकि आप इससे कहीं और दूर नहीं होंगे।

(ओलेग) हाँ, यह सही है। यह अभ्यास किसी भी अन्य गंभीर संस्कृति-परिवर्तन अभ्यास के प्रयास में तुलनीय है। आदतों पर काबू पाना सबसे कठिन चीज़ है, विशेषकर बुरी आदतों पर। और यदि इस अभ्यास को लागू करने के लिए, आपके आस-पास के लोगों की आदतों में गंभीर बदलाव की आवश्यकता है: डेवलपर्स, प्रबंधन, उत्पादन प्रबंधक, तो आश्चर्य आपका इंतजार कर रहा है।

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

यदि आप दिन में 10 बार निरंतर एकीकरण करते हैं, तो 10 बार को 30 मिनट से गुणा करना होगा। और यह इस रिलीज़ प्रबंधक के कार्य समय की मात्रा से अधिक है। वह ऐसा करते-करते थक जाता है। कुछ प्रथाओं के लिए निश्चित लागतें हैं। बस इतना ही।

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

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

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

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

यहां आप इस निष्कर्ष पर पहुंचते हैं कि सबसे पहले आपको यह समझना होगा कि आपको क्या करने की आवश्यकता है। संसार आदर्श नहीं है, और उत्पाद भी आदर्श नहीं है।

हाँ, ये चीज़ें आपस में जुड़ी हुई हैं।

व्यवसाय भी हमेशा यह नहीं समझते कि उन्हें इस तरह जाने की आवश्यकता है।

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

(दिमित्री) मैं चैट से एक स्पष्टीकरण पढ़ूंगा: “लेकिन हमें विभिन्न स्तरों पर बहुत अधिक परीक्षण कवरेज की आवश्यकता है। परीक्षणों के लिए कितना समय आवंटित किया गया है? यह थोड़ा महंगा है और इसमें काफी समय लगता है।”

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

यहाँ आप, निश्चित रूप से, अलंकृत हैं।

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

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

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

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

आइए सतत एकीकरण पर थोड़ा पीछे चलते हैं। हम थोड़े अलग जटिल अभ्यास में भाग गए।

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

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

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

(दिमित्री) यहां बहुत से लोग, जब एमवीपी को कॉल करते हैं, तो लोग कुछ सामान्य लिखने में बहुत आलसी होते हैं। और ये अभी भी अलग चीजें हैं. एमवीपी को किसी ऐसी ख़राब चीज़ में बदलने की ज़रूरत नहीं है जो काम नहीं करती।

हाँ, हाँ, आप सही हैं।

और फिर अचानक उत्पादन में एम.वी.पी.

हमेशा के लिए।

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

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

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

ये प्रथाएं लंबे समय से ज्ञात हैं। हमने लगभग 4 साल पहले इस पर चर्चा की थी। लेकिन 4 वर्षों में व्यावहारिक रूप से कुछ भी नहीं बदला है।

लेकिन इस नोट पर, मैं आधिकारिक चर्चा को समाप्त करने का प्रस्ताव करता हूं।

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

https://youtu.be/zZ3qXVN3Oic

स्रोत: www.habr.com