सराव म्हणून सतत एकत्रीकरण, जेनकिन्स नाही. आंद्रे अलेक्झांड्रोव्ह

सीआय टूल्स आणि सीआय पूर्णपणे भिन्न गोष्टी का आहेत यावर चर्चा करूया.

CI कोणत्या वेदनांचे निराकरण करण्याचा हेतू आहे, कल्पना कोठून आली, ते कार्य करते याची नवीनतम पुष्टीकरणे काय आहेत, हे कसे समजून घ्यावे की आपल्याकडे एक सराव आहे आणि फक्त जेनकिन्स स्थापित केलेला नाही.

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

तर, जेव्हा तुम्ही CI हा शब्द ऐकता तेव्हा सहसा काय मनात येते? बहुतेक लोक जेनकिन्स, गिटलॅब सीआय, ट्रॅव्हिस इत्यादींचा विचार करतील.

जरी आपण ते गुगल केले तरी ते आपल्याला ही साधने देईल.

जर तुम्ही विचारण्यास परिचित असाल, तर टूल्सची यादी केल्यानंतर लगेच, ते तुम्हाला सांगतील की जेव्हा तुम्ही पुल रिक्वेस्ट फॉर कमिटमध्ये चाचण्या तयार करता आणि चालवता तेव्हा ते CI असते.

सतत एकत्रीकरण हे साधनांबद्दल नाही, शाखेतील चाचण्यांसह असेंब्लीबद्दल नाही! सतत एकत्रीकरण म्हणजे नवीन कोडचे वारंवार एकत्रीकरण करण्याचा सराव आणि त्याचा वापर करण्यासाठी जेनकिन्स, गिटलॅब इ.

पूर्ण वाढ झालेला CI कसा दिसतो हे समजून घेण्याआधी, प्रथम ज्या लोकांच्या संदर्भात ते आले त्यांच्या संदर्भात डोकावून पाहू आणि ते सोडवण्याचा प्रयत्न करत असलेल्या वेदना जाणवू या.

आणि त्यांनी एक संघ म्हणून एकत्र काम करण्याचे दुःख सोडवले!

संघांमध्ये विकास करताना विकसकांना कोणत्या अडचणी येतात याची उदाहरणे पाहू या. येथे आमच्याकडे एक प्रकल्प आहे, git मध्ये एक मास्टर शाखा आणि दोन विकासक आहेत.

आणि ते कामावर गेले कारण प्रत्येकाला खूप पूर्वीपासून सवय झाली होती. आम्ही गोष्टींच्या भव्य योजनेत एक कार्य घेतले, एक वैशिष्ट्य शाखा तयार केली आणि कोड लिहिला.

एकाने वैशिष्ट्य जलद पूर्ण केले आणि ते मास्टरमध्ये विलीन केले.

दुसऱ्याला आणखी वेळ हवा होता, तो नंतर विलीन झाला आणि संघर्षाने संपला. आता, व्यवसायाला आवश्यक असलेली वैशिष्ट्ये लिहिण्याऐवजी, विकासक आपला वेळ आणि शक्ती संघर्षांचे निराकरण करण्यात खर्च करतो.

सामान्य मास्टरसह आपले वैशिष्ट्य एकत्र करणे जितके कठीण आहे, तितका जास्त वेळ आपण त्यावर घालवतो. आणि मी हे अगदी साध्या उदाहरणाने दाखवले. हे एक उदाहरण आहे जिथे फक्त 2 विकासक आहेत. कल्पना करा की एका कंपनीतील 10 किंवा 15 किंवा 100 लोक एका भांडारात लिहितात. हे सर्व संघर्ष सोडवण्यासाठी तुम्ही वेडे व्हाल.

थोडे वेगळे प्रकरण आहे. आमच्याकडे एक मास्टर आणि काही विकासक काहीतरी करत आहेत.

त्यांनी एक डहाळी तयार केली.

एक मरण पावला, सर्व काही ठीक आहे, त्याने कार्य पार केले.

दरम्यान, दुसऱ्या विकसकाने त्याचे कार्य सोपवले. समजा त्याने ते पुनरावलोकनासाठी पाठवले आहे. अनेक कंपन्यांमध्ये रिव्ह्यू नावाचा सराव असतो. एकीकडे, ही सराव चांगली आणि उपयुक्त आहे, तर दुसरीकडे, ती आपल्याला अनेक प्रकारे कमी करते. आम्ही त्यामध्ये जाणार नाही, परंतु खराब पुनरावलोकन कथेमुळे काय होऊ शकते याचे एक उत्तम उदाहरण येथे आहे. तुम्ही पुनरावलोकनासाठी पुल विनंती सबमिट केली आहे. डेव्हलपरला करण्यासारखे आणखी काही नाही. तो काय करायला लागतो? तो इतर कामे करू लागतो.

या वेळी, दुसऱ्या विकासकाने काहीतरी वेगळे केले.

पहिल्याने तिसरे काम पूर्ण केले.

आणि काही काळानंतर, त्याच्या पुनरावलोकनाची चाचणी घेण्यात आली आणि तो अटींवर येण्याचा प्रयत्न करीत आहे. मग काय चालले आहे? यात मोठ्या प्रमाणात संघर्ष होतो. का? कारण रिव्ह्यूमध्ये त्याची पुल रिक्वेस्ट लटकत असताना, कोडमध्ये आधीच बऱ्याच गोष्टी बदलल्या होत्या.

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

असे दिसून येते की जर आपण एक संघ म्हणून काम केले, म्हणजे, भांडारात एक व्यक्ती नाही तर 5-10 लोक फिरत असतील, तर आपण जितका वेळ आपला कोड मास्टरमध्ये जोडत नाही तितकाच आपल्याला त्रास होतो कारण शेवटी आपल्याला गरज असते. काहीतरी नंतर ते विलीन करा. आणि आमच्यात जितके विरोधाभास आहेत, आणि आम्ही जितक्या जुन्या आवृत्तीसह कार्य करतो, तितक्या अधिक समस्या आम्हाला आहेत.

एकत्र काहीतरी करणे वेदनादायक आहे! आम्ही नेहमी एकमेकांच्या मार्गाने जातो.

ही समस्या 20 वर्षांपूर्वी लक्षात आली होती. मला एक्सट्रीम प्रोग्रामिंगमधील सतत एकात्मतेच्या सरावाचा पहिला उल्लेख आढळला.

एक्स्ट्रीम प्रोग्रामिंग हे पहिले चपळ फ्रेमवर्क आहे. पृष्ठ 96 मध्ये दिसू लागले. आणि काही प्रकारच्या प्रोग्रामिंग पद्धती, नियोजन आणि इतर गोष्टी वापरण्याची कल्पना होती, जेणेकरून विकास शक्य तितका लवचिक असेल, जेणेकरून आम्ही आमच्या क्लायंटच्या कोणत्याही बदलांना किंवा आवश्यकतांना त्वरित प्रतिसाद देऊ शकू. आणि त्यांनी 24 वर्षांपूर्वी या गोष्टीचा सामना करण्यास सुरुवात केली, की जर तुम्ही खूप वेळ आणि बाजूला राहून एखादी गोष्ट केली, तर तुम्ही त्यात जास्त वेळ घालवता कारण तुमच्यात मतभेद आहेत.

आता आपण "सतत एकीकरण" या वाक्यांशाचे वैयक्तिकरित्या विश्लेषण करू. जर आपण त्याचे थेट भाषांतर केले तर आपल्याला सतत एकीकरण मिळते. परंतु ते किती सतत आहे हे फार स्पष्ट नाही; ते खूप खंडित आहे. पण त्यात किती एकात्मता आहे हेही फारसे स्पष्ट नाही.

आणि म्हणूनच मी तुम्हाला आता एक्स्ट्रीम प्रोग्रामिंगचे कोट्स देत आहे. आणि आम्ही दोन्ही शब्दांचे स्वतंत्रपणे विश्लेषण करू.

एकत्रीकरण - मी आधीच म्हटल्याप्रमाणे, प्रत्येक अभियंता कोडच्या सर्वात वर्तमान आवृत्तीसह कार्य करतो याची खात्री करण्यासाठी आम्ही प्रयत्न करतो, जेणेकरून तो शक्य तितक्या वेळा सामान्य शाखेत कोड जोडण्याचा प्रयत्न करतो, जेणेकरून या लहान शाखा असतील. कारण ते मोठे असतील तर आठवडाभर विलीनीकरणाच्या संघर्षात आपण सहज अडकू शकतो. आमच्याकडे धबधब्यासारखे दीर्घ विकास चक्र असल्यास हे विशेषतः खरे आहे, जिथे विकसक काही मोठे वैशिष्ट्य कापण्यासाठी एका महिन्यासाठी निघून गेला. आणि तो एकीकरणाच्या टप्प्यावर बराच काळ अडकलेला असेल.

इंटिग्रेशन म्हणजे जेव्हा आपण आपली शाखा घेतो आणि ती मास्टरशी समाकलित करतो, तेव्हा आपण ती विलीन करतो. जेव्हा आम्ही ट्रान्सबेस डेव्हलपर असतो तेव्हा एक अंतिम पर्याय असतो, जिथे आम्ही कोणत्याही अतिरिक्त शाखांशिवाय मास्टरला ताबडतोब पत्र लिहू याची खात्री करण्यासाठी आम्ही प्रयत्न करतो.

सर्वसाधारणपणे, इंटिग्रेशन म्हणजे तुमचा कोड घेणे आणि मास्टरमध्ये ड्रॅग करणे.

येथे “अखंड” या शब्दाचा अर्थ काय आहे, सातत्य कशाला म्हणतात? सराव सूचित करतो की विकसक त्याचा कोड शक्य तितक्या लवकर समाकलित करण्याचा प्रयत्न करतो. कोणतेही कार्य करताना हे त्याचे ध्येय असते - त्याचा कोड शक्य तितक्या लवकर मास्टरमध्ये मिळवणे. आदर्श जगात, विकासक हे दर काही तासांनी करतात. म्हणजेच, आपण एक लहान समस्या घ्या आणि ती मास्टरमध्ये विलीन करा. सर्व काही छान आहे. यासाठी तुम्ही प्रयत्नशील आहात. आणि हे सतत केले पाहिजे. एखादी गोष्ट केली की लगेचच मास्टरमध्ये टाकतो.

आणि विकासक जो काहीतरी बनवतो त्याने ते कार्य करण्यासाठी आणि काहीही खंडित न होण्यासाठी काय केले याची जबाबदारी आहे. येथेच चाचणी कथा सहसा बाहेर येते. ते कार्य करत आहे याची खात्री करण्यासाठी आम्हाला आमच्या कमिटवर, आमच्या विलीनीकरणावर काही चाचण्या करायच्या आहेत. आणि इथेच जेनकिन्स तुम्हाला मदत करू शकतात.

परंतु कथांसह: चला बदल लहान करूया, कार्ये लहान होऊ द्या, एक समस्या निर्माण करूया आणि ताबडतोब ते कसे तरी मास्टरमध्ये एम्बेड करण्याचा प्रयत्न करूया - येथे कोणतेही जेनकिन्स मदत करणार नाहीत. कारण जेनकिन्स तुम्हाला फक्त चाचण्या चालवण्यास मदत करेल.

आपण त्यांच्याशिवाय करू शकता. यामुळे तुम्हाला अजिबात त्रास होणार नाही. कारण सरावाचे उद्दिष्ट हे शक्य तितक्या वेळा मोजमाप करणे आहे, जेणेकरून भविष्यात कोणत्याही संघर्षात बराच वेळ वाया जाऊ नये.

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

आधुनिक जगात कोणता पुरावा आहे की ऊर्जा खर्च करणे योग्य आहे? कारण सर्वसाधारणपणे ते अवघड आहे. अशा प्रकारे काम करण्याचा प्रयत्न केल्यास, आता काही नियोजनावर परिणाम होईल, हे तुम्हाला समजेल, तुम्हाला विघटित कामांसाठी अधिक वेळ द्यावा लागेल. कारण जर तुम्ही मनुष्य..., तर तुम्ही त्वरीत अटींवर येऊ शकणार नाही आणि त्यानुसार अडचणीत याल. तुम्हाला यापुढे सराव नसेल.

आणि ते महाग होईल. कंटिन्युअस इंटिग्रेशन वापरून उद्यापासून लगेच काम करणे शक्य होणार नाही. तुम्हाला याची सवय होण्यासाठी खूप वेळ लागेल, विघटित कामांची सवय होण्यासाठी तुम्हाला खूप वेळ लागेल, पुनरावलोकन सराव पुन्हा करण्याची सवय होण्यासाठी खूप वेळ लागेल, जर तुमच्याकडे असेल तर . कारण आज ते वितळणे हे आमचे ध्येय आहे. आणि जर तुम्ही तीन दिवसात पुनरावलोकन केले तर तुम्हाला समस्या आहेत आणि सतत एकत्रीकरण तुमच्यासाठी काम करत नाही.

पण या सरावात गुंतवणूक करणे अर्थपूर्ण आहे असे सांगणारा कोणताही संबंधित पुरावा आमच्याकडे सध्या आहे का?

माझ्या मनात आलेली पहिली गोष्ट म्हणजे DevOps स्टेट. हा एक अभ्यास आहे जो मुले 7 वर्षांपासून करत आहेत. आता ते स्वतंत्र संस्था म्हणून करतात, परंतु Google अंतर्गत.

आणि त्यांच्या 2018 च्या अभ्यासाने त्वरीत समाकलित होणाऱ्या, वारंवार समाकलित होणाऱ्या आणि आयटी कामगिरीचे चांगले निर्देशक असलेल्या अल्पायुषी शाखा वापरण्याचा प्रयत्न करणाऱ्या कंपन्यांमधील परस्परसंबंध दर्शविला.

हे संकेतक काय आहेत? हे 4 मेट्रिक्स आहेत जे ते त्यांच्या प्रश्नावलीमध्ये सर्व कंपन्यांकडून घेतात: उपयोजन वारंवारता, बदलांसाठी लीड वेळ, सेवा पुनर्संचयित करण्यासाठी वेळ, अयशस्वी दर बदलणे.

आणि, सर्वप्रथम, हा परस्परसंबंध आहे, आम्हाला माहित आहे की ज्या कंपन्या वारंवार मोजमाप करतात त्यांच्याकडे बरेच चांगले मेट्रिक्स आहेत. आणि त्यांच्याकडे अनेक श्रेणींमध्ये कंपन्यांची विभागणी आहे: या संथ कंपन्या आहेत ज्या हळूहळू काहीतरी तयार करतात, मध्यम कलाकार, उच्च कामगिरी करणारे आणि उच्चभ्रू. उच्चभ्रू म्हणजे Netflix, Amazon, जे सुपर फास्ट आहेत, सर्वकाही जलद, सुंदर आणि कार्यक्षमतेने करतात.

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

जर तुमची शाखा फार काळ जगली तर ती अडकते, कुजते आणि आम्ही त्यात काही प्रकारचे बदल करण्याच्या प्रयत्नात जास्त वेळ घालवतो.

आणि अलीकडेच गिटफ्लोच्या लेखकाने म्हटले आहे की जर तुमचे ध्येय सतत एकात्मता असेल, जर तुमचे ध्येय तुम्हाला शक्य तितक्या वेळा रोल करायचे असेल, तर गिटफ्लो ही वाईट कल्पना आहे. त्याने स्वतंत्रपणे लेखात जोडले की जर तुमच्याकडे बॅकएंड असेल जिथे तुम्ही यासाठी प्रयत्न करू शकता, तर गिटफ्लो तुमच्यासाठी अनावश्यक आहे, कारण गिटफ्लो तुमची गती कमी करेल, गिटफ्लो तुमच्यासाठी एकत्रीकरणासह समस्या निर्माण करेल.

याचा अर्थ असा नाही की गिटफ्लो खराब आहे आणि वापरला जाऊ नये. ते इतर प्रसंगांसाठी आहे. उदाहरणार्थ, जेव्हा तुम्हाला एखाद्या सेवेच्या किंवा अनुप्रयोगाच्या अनेक आवृत्त्यांचे समर्थन करण्याची आवश्यकता असते, म्हणजे जिथे तुम्हाला दीर्घ कालावधीसाठी समर्थनाची आवश्यकता असते.

परंतु जर तुम्ही अशा सेवांना समर्थन देणाऱ्या लोकांशी बोललात तर तुम्हाला खूप वेदना ऐकायला मिळतील की ही आवृत्ती 3.2 होती, जी 4 महिन्यांपूर्वी होती, परंतु हे निराकरण त्यात समाविष्ट नव्हते आणि आता ते बनवण्यासाठी, तुम्हाला अनेक बदल करावे लागतील. आणि आता ते पुन्हा अडकले आहेत, आणि आता ते काही नवीन वैशिष्ट्य लागू करण्याचा प्रयत्न करत आठवडाभर फिरत आहेत.

अलेक्झांडर कोवालेव्हने चॅटमध्ये अचूकपणे नमूद केल्याप्रमाणे, सहसंबंध हे कारणासारखे नाही. हे खरं आहे. म्हणजेच, तुमच्याकडे सतत एकात्मता असल्यास, सर्व मेट्रिक्स उत्कृष्ट असतील असा थेट संबंध नाही. परंतु एक सकारात्मक सहसंबंध आहे की जर एक असेल तर बहुधा दुसरा देखील आहे. तथ्य नाही, परंतु बहुधा. तो फक्त एक सहसंबंध आहे.

असे दिसते की आपण आधीच काहीतरी करत आहोत, असे दिसते की आपण आधीच विलीन होत आहोत, परंतु आपण हे कसे समजू शकतो की आपल्याकडे अद्याप सतत एकत्रीकरण आहे, आपण बरेचदा विलीन होत आहोत?

जेझ नम्र हे हँडबुक, एक्सीलरेट, कंटिन्युअस डिलिव्हरी वेबसाइट आणि कंटिन्युअस डिलिव्हरी या पुस्तकाचे लेखक आहेत. तो ही चाचणी ऑफर करतो:

• इंजिनीअरचा कोड रोज मास्तरांना मिळतो.
• प्रत्येक कमिटसाठी तुम्ही युनिट चाचण्या चालवता.
• मास्टरमधील बिल्ड पडले, ते सुमारे 10 मिनिटांत निश्चित केले गेले.

तुमच्याकडे पुरेसा सराव आहे याची खात्री करण्यासाठी तो अशा चाचणीचा वापर सुचवतो.

मला नंतरचे थोडे विवादास्पद वाटते. म्हणजेच, जर तुम्ही ते 10 मिनिटांत दुरुस्त करू शकत असाल, तर तुमच्याकडे सतत एकीकरण आहे, माझ्या मते ते थोडे विचित्र वाटते, परंतु ते अर्थपूर्ण आहे. का? कारण जर तुम्ही वारंवार गोठत असाल तर याचा अर्थ तुमचे बदल लहान आहेत. जर लहान बदल म्हणजे तुमची मास्टर बिल्ड तुटलेली असेल, तर बदल लहान असल्यामुळे तुम्ही एक उदाहरण पटकन शोधू शकता. येथे आपल्याकडे एक लहान विलीनीकरण होते, त्यातील 20-30 ओळी बदलल्या. आणि, त्यानुसार, आपण त्वरीत कारण काय होते ते समजू शकता, कारण बदल लहान आहेत, समस्या शोधण्यासाठी आपल्याकडे खूप लहान क्षेत्र आहे.

आणि रिलीझ झाल्यानंतर जरी आमची उत्पादनं तुटली तरी, जर आम्हाला सतत एकात्मतेचा सराव असेल, तर आम्हाला कार्य करणे खूप सोपे आहे, कारण बदल लहान आहेत. होय, याचा नियोजनावर परिणाम होईल. यामुळे दुखापत होईल. आणि, कदाचित, या सरावातील सर्वात कठीण गोष्ट म्हणजे कार्ये तोडण्याची सवय लावणे, म्हणजे, ते कसे करावे जेणेकरून आपण काहीतरी घेऊ शकाल आणि काही तासांत ते करू शकाल आणि त्याच वेळी पुनरावलोकन पास करा. तुमच्याकडे एक आहे. समीक्षा एक वेगळी वेदना आहे.

युनिट चाचण्या फक्त एक सहाय्यक आहेत जे तुम्हाला हे समजण्यास मदत करतात की तुमचे एकत्रीकरण यशस्वी झाले की नाही आणि काहीही खंडित झाले नाही. माझ्या मते, हे देखील पूर्णपणे अनिवार्य नाही, कारण हा सरावाचा मुद्दा नाही.

सतत एकात्मतेचा हा संक्षिप्त परिचय आहे. या सरावात एवढेच आहे. मी प्रश्नांसाठी तयार आहे.

मी पुन्हा थोडक्यात सारांश देईन:

• सतत एकत्रीकरण जेनकिन्स नाही, ते गिटलॅब नाही.
• हे एक साधन नाही, ही एक सराव आहे की आम्ही आमचा कोड शक्य तितक्या वेळा मास्टरमध्ये विलीन करतो.
• भविष्यात विलीन झाल्यामुळे उद्भवणाऱ्या प्रचंड वेदना टाळण्यासाठी आम्ही हे करतो, म्हणजेच भविष्यात अधिक अनुभव येऊ नये म्हणून आम्हाला आता थोडेसे दुखणे जाणवते. हा संपूर्ण मुद्दा आहे.
• बाजूला कोडद्वारे संप्रेषण आहे, परंतु मी हे फार क्वचितच पाहतो, परंतु ते यासाठी डिझाइन केले गेले होते.

प्रश्न

विघटित नसलेल्या कामांचे काय करायचे?

कुजणे. काय अडचण आहे? एखादे कार्य आहे आणि ते विघटित नाही असे उदाहरण देऊ शकाल का?

अशी कार्ये आहेत जी "पूर्णपणे" या शब्दापासून विघटित केली जाऊ शकत नाहीत, उदाहरणार्थ, ज्यांना खूप सखोल कौशल्य आवश्यक आहे आणि जे काही पचण्याजोगे परिणाम मिळविण्यासाठी एका महिन्याच्या कालावधीत सोडवले जाऊ शकतात.

जर मी तुम्हाला बरोबर समजले तर काही मोठे आणि गुंतागुंतीचे काम आहे, ज्याचा परिणाम फक्त एका महिन्यातच दिसेल?

होय ते खरंय. होय, एका महिन्यापूर्वी निकालाचे मूल्यांकन करणे शक्य होईल.

ठीक आहे. सर्वसाधारणपणे ही समस्या नाही. का? कारण या प्रकरणात, जेव्हा आपण डहाळ्यांबद्दल बोलतो, तेव्हा आपण वैशिष्ट्य असलेल्या डहाळीबद्दल बोलत नाही. वैशिष्ट्ये मोठी आणि जटिल असू शकतात. ते मोठ्या संख्येने घटकांवर परिणाम करू शकतात. आणि कदाचित आम्ही ते एका शाखेत पूर्णपणे करू शकत नाही. हे ठीक आहे. आपण फक्त ही कथा खंडित करणे आवश्यक आहे. एखादे वैशिष्ट्य पूर्णपणे तयार नसल्यास, याचा अर्थ असा नाही की त्याच्या कोडचे काही भाग विलीन केले जाऊ शकत नाहीत. तुम्ही जोडले, म्हणा, स्थलांतर आणि वैशिष्ट्यामध्ये काही टप्पे आहेत. समजा तुमच्याकडे एक स्टेज आहे - एक स्थलांतर करा, एक नवीन पद्धत जोडा. आणि आपण दररोज या गोष्टी आधीच मोजू शकता.

ठीक आहे. मग मुद्दा काय आहे?

रोज छोट्या छोट्या गोष्टी मारण्यात काय अर्थ आहे?

होय

जर त्यांनी काही तोडले तर तुम्हाला ते लगेच दिसेल. तुमच्याकडे एक छोटा तुकडा आहे ज्यामध्ये काहीतरी तुटले आहे, ते दुरुस्त करणे तुमच्यासाठी सोपे आहे. मुद्दा असा आहे की आता एक लहान तुकडा विलीन करणे काही आठवड्यांत काहीतरी मोठे विलीन करण्यापेक्षा खूप सोपे आहे. आणि तिसरा मुद्दा असा आहे की इतर अभियंते कोडच्या वर्तमान आवृत्तीसह कार्य करतील. ते पाहतील की येथे काही स्थलांतरे जोडली गेली आहेत आणि नंतर काही पद्धत दिसली आहे जी त्यांना देखील वापरायची आहे. तुमच्या कोडमध्ये काय चालले आहे ते प्रत्येकाला दिसेल. या तीन गोष्टींसाठीच सराव केला जातो.

धन्यवाद, अंक बंद आहे!

(ओलेग सोरोका) मी जोडू शकतो का? आपण सर्वकाही योग्यरित्या सांगितले आहे, मला फक्त एक वाक्यांश जोडायचा आहे.

तर.

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

आम्ही 4 मेट्रिक्सबद्दल बोललो जे यशस्वी कंपन्यांना मागे पडलेल्या कंपन्यांपासून वेगळे करतात. हे 4 मेट्रिक्स पाहण्यासाठी आम्हाला अजूनही जगावे लागेल. तुमचे सरासरी कार्य पूर्ण होण्यास एक महिना लागल्यास, मी प्रथम या मेट्रिकवर लक्ष केंद्रित करेन. मी प्रथम ते 3 दिवसांपर्यंत कमी करेन. आणि त्यानंतर मी Continuous चा विचार करू लागलो.

मी तुम्हाला बरोबर समजले आहे का की तुम्हाला असे वाटते की सर्वसाधारणपणे कोणतेही काम पूर्ण होण्यास एक महिना लागला तर अभियांत्रिकी पद्धतींमध्ये गुंतवणूक करण्यात काही अर्थ नाही?

तुमच्याकडे सतत एकात्मता आहे. आणि असा एक विषय आहे की 10 मिनिटांत आपण एकतर निराकरण करू शकता किंवा ते परत करू शकता. कल्पना करा की तुम्ही ते रोल आउट केले आहे. शिवाय, तुमच्याकडे सतत उपयोजन देखील आहे, तुम्ही ते उत्पादनावर आणले आणि तेव्हाच लक्षात आले की काहीतरी चूक झाली आहे. आणि तुम्हाला ते परत रोल करणे आवश्यक आहे, परंतु तुम्ही आधीच तुमचा डेटाबेस स्थलांतरित केला आहे. आपल्याकडे आधीपासूनच पुढील आवृत्तीचा डेटाबेस स्कीमा आहे, शिवाय, आपल्याकडे काही प्रकारचे बॅकअप देखील आहे आणि डेटा देखील तेथे लिहिला गेला आहे.

आणि तुमच्याकडे कोणता पर्याय आहे? जर तुम्ही कोड परत आणला, तर तो या अपडेट केलेल्या डेटाबेससह कार्य करू शकणार नाही.

आधार फक्त पुढे सरकतो, होय.

ज्या लोकांचे अभियांत्रिकी सराव कमी आहेत त्यांनी बहुधा... याविषयीचे जाडजूड पुस्तकही वाचले नाही. बॅकअपचे काय करायचे? आपण बॅकअपमधून पुनर्संचयित केल्यास, याचा अर्थ असा आहे की आपण त्या क्षणी जमा केलेला डेटा गमावला आहे. उदाहरणार्थ, आम्ही डेटाबेसच्या नवीन आवृत्तीसह तीन तास काम केले, तेथे नोंदणीकृत वापरकर्ते. तुम्ही जुन्या बॅकअपला नकार दिला कारण योजना नवीन आवृत्तीसह कार्य करत नाही, त्यामुळे तुम्ही हे वापरकर्ते गमावले आहेत. आणि ते असमाधानी आहेत, ते शपथ घेतात.

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

अशा शेकडो प्रथा आहेत. मी ट्रान्सबेस डेव्हलपमेंटसह प्रारंभ करण्यास सुचवितो. ती सतत एकात्मतेवर 100% नाही, परंतु पद्धती समान आहेत, एक दुसऱ्याशिवाय चांगले जगू शकत नाही.

तुम्ही ट्रान्सबेस डेव्हलपमेंटचे उदाहरण दिले आहे का जेथे तुम्ही सराव पाहू शकता किंवा तुम्ही लोकांना ट्रान्सबेस डेबलोपमेंट वापरण्यास सुचवता?

पहा, कारण ते ते वापरू शकणार नाहीत. त्यांचा वापर करण्यासाठी, आपल्याला खूप वाचण्याची आवश्यकता आहे. आणि जेव्हा एखादी व्यक्ती विचारते: "एक महिना लागणाऱ्या वैशिष्ट्याचे काय करावे, याचा अर्थ असा की त्याने ट्रान्सबेस विकासाबद्दल वाचले नाही." मी अजून शिफारस करणार नाही. मोठ्या कार्यांना लहान कार्यांमध्ये योग्यरित्या कसे विभाजित करावे या विषयावर मी पूर्णपणे लक्ष केंद्रित करण्याचा सल्ला देईन. हे विघटनाचे सार आहे.

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

तुम्हाला काही आकृतीवर अनेक बाण आणि चौरस काढावे लागतील. तुम्ही असे म्हणू शकत नाही की आता मी नवीन अॅप्लिकेशनचे आर्किटेक्चरल डायग्राम दाखवेन आणि एक स्क्वेअर दाखवेन, ज्यामध्ये अॅप्लिकेशनसाठी हिरवे बटण आहे. कोणत्याही परिस्थितीत, अधिक चौरस आणि बाण असतील. मी पाहिलेल्या प्रत्येक आकृतीत एकापेक्षा जास्त होते. आणि विघटन, अगदी ग्राफिकल प्रतिनिधित्वाच्या पातळीवरही, आधीच होत आहे. त्यामुळे चौकोन स्वतंत्र करता येतात. नाही तर वास्तुविशारदाला मोठे प्रश्न आहेत.

चॅटमधून एक प्रश्न आहे: "जर पुनरावलोकन अनिवार्य असेल आणि त्याला बराच वेळ लागतो, कदाचित एक दिवस किंवा अधिक?"

तुम्हाला सरावात समस्या आहेत. पुनरावलोकन एक किंवा अधिक दिवस टिकू नये. मागील प्रश्नाची हीच कथा आहे, फक्त थोडीशी मऊ. जर पुनरावलोकन एक दिवस चालले तर बहुधा हे पुनरावलोकन काही फार मोठे बदल होत आहे. याचा अर्थ ते लहान करणे आवश्यक आहे. ओलेगने शिफारस केलेल्या ट्रान्सबेस डेव्हलपमेंटमध्ये, सतत पुनरावलोकन नावाची एक कथा आहे. तिची कल्पना अशी आहे की आम्ही हेतुपुरस्सर अशी छोटीशी विनंती करतो, कारण आम्ही एका वेळी सतत आणि थोडे विलीन होण्याचा प्रयत्न करतो. आणि म्हणून पुल विनंती एक अमूर्त किंवा 10 ओळी बदलते. या पुनरावलोकनाबद्दल धन्यवाद, आम्हाला काही मिनिटे लागतात.

पुनरावलोकनास एक किंवा अधिक दिवस लागल्यास, काहीतरी चूक आहे. प्रथम, तुम्हाला आर्किटेक्चरमध्ये काही समस्या असू शकतात. किंवा हा कोडचा एक मोठा तुकडा आहे, 1 ओळी, उदाहरणार्थ. किंवा तुमचे आर्किटेक्चर इतके क्लिष्ट आहे की माणसाला ते समजू शकत नाही. ही थोडीशी बाजूची समस्या आहे, परंतु ती देखील सोडवावी लागेल. कदाचित पुनरावलोकनाची अजिबात गरज नाही. याचाही विचार करायला हवा. पुनरावलोकन ही अशी गोष्ट आहे जी तुम्हाला कमी करते. त्याचे सर्वसाधारणपणे फायदे आहेत, परंतु आपण ते का करत आहात हे समजून घेणे आवश्यक आहे. तुमच्यासाठी माहिती पटकन पोहोचवण्याचा हा एक मार्ग आहे का, तुमच्यासाठी अंतर्गत काही मानके सेट करण्याचा हा मार्ग आहे की काय? तुम्हाला याची गरज का आहे? कारण पुनरावलोकन एकतर खूप लवकर केले जाणे किंवा पूर्णपणे रद्द करणे आवश्यक आहे. हे ट्रान्सबेस डेव्हलपमेंट सारखे आहे - कथा खूप सुंदर आहे, परंतु केवळ प्रौढ मुलांसाठी.

4 मेट्रिक्सच्या संदर्भात, यामुळे काय होते हे समजून घेण्यासाठी मी तरीही त्यांना काढून टाकण्याची शिफारस करतो. संख्या पहा, चित्र पहा, सर्वकाही किती वाईट आहे.

(दिमित्री) मी तुमच्याशी याबद्दल चर्चा करण्यास तयार आहे. संख्या आणि मेट्रिक्स सर्व उत्तम आहेत, सराव उत्तम आहेत. परंतु व्यवसायाला त्याची गरज आहे की नाही हे समजून घेणे आवश्यक आहे. असे व्यवसाय आहेत ज्यांना अशा प्रकारच्या बदलाची आवश्यकता नाही. मला अशा कंपन्यांची माहिती आहे जिथे दर 15 मिनिटांनी बदल करता येत नाहीत. आणि ते खूप वाईट आहेत म्हणून नाही. हे असे जीवनचक्र आहे. आणि शाखा वैशिष्ट्य, टॉगल वैशिष्ट्य करण्यासाठी, आपल्याला सखोल ज्ञान आवश्यक आहे.

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

आणि आपण अद्याप या प्रश्नाचे उत्तर दिले नाही: "जेनकिन्सची गरज आहे की नाही?"

जेनकिन्स खरोखर कोणत्याही परिस्थितीत आवश्यक नाही. गंभीरपणे, साधने: जेनकिन्स, गिटलॅब तुम्हाला सुविधा देईल. असेंब्ली असेंबल झाली आहे की नाही हे तुम्हाला दिसेल. ते तुम्हाला मदत करू शकतात, परंतु ते तुम्हाला सराव देणार नाहीत. ते तुम्हाला फक्त एक मंडळ देऊ शकतात - ओके, ओके नाही. आणि मग, जर तुम्ही चाचण्या देखील लिहा, कारण जर काही चाचण्या नसतील तर ते जवळजवळ निरर्थक आहे. म्हणून, ते आवश्यक आहे कारण ते अधिक सोयीस्कर आहे, परंतु सर्वसाधारणपणे आपण त्याशिवाय जगू शकता, आपण जास्त गमावणार नाही.

म्हणजेच, जर तुमच्याकडे सराव असेल तर याचा अर्थ तुम्हाला त्याची गरज नाही का?

ते बरोबर आहे. मी जेझ नम्र चाचणीची शिफारस करतो. तिथे शेवटच्या मुद्द्याबद्दल माझी द्विधा मनस्थिती आहे. परंतु सर्वसाधारणपणे, जर तुमच्याकडे तीन गोष्टी असतील, तर तुम्ही सतत विलीन व्हाल, तुम्ही मास्टरमधील कमिटवर चाचण्या चालवता, तुम्ही मास्टरमध्ये बिल्ड त्वरीत दुरुस्त करता, मग कदाचित तुम्हाला इतर कशाचीही गरज नाही.

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

असे असले पाहिजे असे नाही, ते खूप चांगले होईल कारण ते त्याच प्रकारे जीवन सोपे करेल. जसे आपण कोडसह कार्य करतो, बॅश स्क्रिप्टसह नाही, परंतु आपल्याकडे सामान्य कोड असतो.

थांबा, थांबा, बॅश स्क्रिप्ट देखील कोड आहे. माझ्या जुन्या प्रेमाला स्पर्श करू नका.

ठीक आहे, मी तुझ्या आठवणी तुडवणार नाही. बाशबद्दल मला वैयक्तिक नापसंती आहे. हे सर्व वेळ कुरूप आणि धडकी भरवणारा तोडतो. आणि ते अनेकदा अप्रत्याशितपणे खंडित होते, म्हणूनच मला ते आवडत नाही. पण ठीक आहे, समजा तुमच्याकडे बॅश कोड आहे. कदाचित मला खरोखर समजले नाही आणि तेथे सामान्य चाचणी फ्रेमवर्क आहेत. मला फक्त माहिती नाही. आणि आम्हाला समान फायदे मिळतात.

आम्ही कोड म्हणून पायाभूत सुविधांसह काम केल्यावर, आम्हाला विकासकांसारख्याच समस्या येतात. काही महिन्यांपूर्वी, मला अशी परिस्थिती आली होती जिथे एका सहकाऱ्याने मला 1 ओळींच्या बॅशसाठी पुल विनंती पाठवली. आणि तुम्ही 000 तास पुनरावलोकनासाठी हँग आउट करता. त्याच समस्या उद्भवतात. तो अजूनही कोड आहे. आणि तो अजूनही सहयोग आहे. आम्ही पुल विनंतीसह अडकतो आणि आम्ही या वस्तुस्थितीसह अडकतो की आम्ही त्याच बॅशमध्ये समान मर्ज विवादांचे निराकरण करत आहोत, उदाहरणार्थ.

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

इतर कोणाला प्रश्न असल्यास?

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

(ओलेग) होय, ते बरोबर आहे. ही प्रथा इतर कोणत्याही गंभीर संस्कृती बदलणाऱ्या प्रथेशी तुलना करता येते. सर्वात कठीण गोष्ट म्हणजे सवयी, विशेषतः वाईट सवयी. आणि जर ही प्रथा अंमलात आणण्यासाठी, आपल्या सभोवतालच्या लोकांच्या सवयींमध्ये गंभीर बदल आवश्यक आहे: विकसक, व्यवस्थापन, उत्पादन व्यवस्थापक, तर आश्चर्यचकित तुमची वाट पाहत आहेत.

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

जर तुम्ही दिवसातून 10 वेळा सतत एकत्रीकरण केले तर 10 वेळा 30 मिनिटांनी गुणाकार करणे आवश्यक आहे. आणि हे या प्रकाशन व्यवस्थापकाच्या कामाच्या वेळेपेक्षा जास्त आहे. तो फक्त ते करून थकतो. काही सरावांसाठी निश्चित खर्च आहेत. इतकंच.

आणि तुम्हाला एकतर हा नियम रद्द करणे आवश्यक आहे जेणेकरुन तुम्ही यापुढे असा कचरा करणार नाही, म्हणजे तुम्ही एखाद्या गोष्टीशी संबंधित होण्यासाठी व्यक्तिचलितपणे पदवी नियुक्त करत नाही. तुम्ही पूर्णतः काही स्वयंचलित तयारी चाचण्यांवर अवलंबून आहात.

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

जेव्हा एखादी व्यक्ती आपले नेहमीचे काम करते तेव्हा तो जवळजवळ विचार न करता करतो. तिचा संज्ञानात्मक भार शून्य आहे. तो फक्त त्याच्याशी खेळतो, त्याच्या डोक्यात आधीच एक चेकलिस्ट आहे, त्याने ते हजार वेळा केले आहे. आणि लगेच तुम्ही येऊन त्याला सांगा: "चला ही प्रथा रद्द करू आणि सोमवारपासून नवीन प्रथा सादर करू," त्याच्यासाठी तो एक शक्तिशाली संज्ञानात्मक भार बनतो. आणि ते एकाच वेळी सर्वांना येते.

म्हणूनच, सर्वात सोपी गोष्ट, जरी प्रत्येकाला ही लक्झरी परवडत नाही, परंतु मी नेहमीच हेच करतो, हे खालीलप्रमाणे आहे. नवीन प्रकल्प सुरू झाल्यास, सामान्यतः सर्व न तपासलेल्या पद्धती या प्रकल्पात ताबडतोब जोडल्या जातात. प्रकल्प लहान असताना, आम्ही खरोखर काहीही धोका पत्करत नाही. अद्याप कोणतेही उत्पादन नाही, नष्ट करण्यासाठी काहीही नाही. म्हणून, ते प्रशिक्षण म्हणून वापरले जाऊ शकते. हा दृष्टिकोन कार्य करतो. परंतु सर्वच कंपन्यांना असे प्रकल्प अनेकदा सुरू करण्याची संधी नसते. जरी हे थोडे विचित्र आहे, कारण आता संपूर्ण डिजिटल परिवर्तन झाले आहे, प्रत्येकाने प्रतिस्पर्ध्यांशी टिकून राहण्यासाठी प्रयोग सुरू केले पाहिजेत.

येथे तुम्ही या निष्कर्षाप्रत आला आहात की तुम्हाला काय करावे लागेल याची प्रथम तुम्हाला समज असणे आवश्यक आहे. जग आदर्श नाही आणि उत्पादनही आदर्श नाही.

होय, या गोष्टी एकमेकांशी जोडलेल्या आहेत.

व्यवसाय देखील नेहमी समजत नाहीत की त्यांना या मार्गाने जाण्याची आवश्यकता आहे.

अशी परिस्थिती आहे ज्यामध्ये कोणतेही बदल शक्य नाहीत. यामुळे संघावर अधिक दडपण आहे. संघ आधीच बर्‍यापैकी भाजला आहे. तिच्याकडे कोणत्याही प्रयोगासाठी मोकळा वेळ नाही. ते सकाळपासून संध्याकाळपर्यंत वैशिष्ट्यांवर काम करतात. आणि व्यवस्थापनामध्ये कमी आणि कमी वैशिष्ट्ये आहेत. अधिक आणि अधिक आवश्यक आहेत. अशा परिस्थितीत कोणताही बदल शक्य नाही. संघाला एवढंच सांगता येईल की उद्या आपण काल ​​सारखेच करू, आपल्याला फक्त थोडी अधिक वैशिष्ट्ये बनवायची आहेत. या अर्थाने, कोणत्याही पद्धतींमध्ये कोणतेही संक्रमण शक्य नाही. ही एक उत्कृष्ट परिस्थिती आहे जेव्हा कुर्हाड धारदार करण्यासाठी वेळ नसतो, झाडे तोडणे आवश्यक असते, म्हणून ते कंटाळवाणा कुऱ्हाडीने कापतात. येथे कोणत्याही साध्या टिपा नाहीत.

(दिमित्री) मी चॅटमधून स्पष्टीकरण वाचेन: “परंतु आम्हाला वेगवेगळ्या स्तरांवर भरपूर चाचणी कव्हरेजची आवश्यकता आहे. चाचण्यांसाठी किती वेळ दिला जातो? हे थोडे महाग आहे आणि खूप वेळ लागतो.”

(ओलेग) हा एक उत्कृष्ट गैरसमज आहे. तुम्हाला आत्मविश्वास देण्यासाठी पुरेशा चाचण्या असाव्यात. सतत एकात्मता ही अशी गोष्ट नाही जिथे 100% चाचण्या आधी केल्या जातात आणि त्यानंतरच तुम्ही हा सराव लागू करू शकता. सतत एकात्मतेमुळे तुमचा संज्ञानात्मक भार कमी होतो कारण तुम्ही तुमच्या डोळ्यांनी पाहत असलेले प्रत्येक बदल इतके स्पष्ट असतात की ते काही बिघडते की नाही हे तुम्हाला समजते, अगदी चाचण्यांशिवाय. तुम्ही हे तुमच्या डोक्यात पटकन तपासू शकता कारण बदल लहान आहेत. तुमच्याकडे फक्त मॅन्युअल परीक्षक असले तरीही, त्यांच्यासाठीही ते सोपे आहे. तुम्ही गुंडाळले आणि म्हणाला: "बघा, काही तुटले आहे का?" त्यांनी तपासले आणि म्हणाले, "नाही, काहीही तुटलेले नाही." कारण परीक्षकाला कुठे बघायचे हे माहीत असते. तुमच्याकडे कोडच्या एका भागाशी संबंधित एक कमिट आहे. आणि हे विशिष्ट वर्तनाद्वारे शोषण केले जाते.

येथे आपण, अर्थातच, सुशोभित.

(दिमित्री) मी येथे सहमत नाही. एक सराव आहे - चाचणी-चालित विकास, जो तुम्हाला यापासून वाचवेल.

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

चाचण्यांपासून चांगले निरीक्षण वेगळे करता येत नाही. तुम्ही प्री प्रोडवर एकदा चाचण्या चालवल्यास, ते तुमच्या सर्व वापरकर्ता स्क्रिप्ट्स एकदा तपासतात आणि तेच. आणि जर तुम्ही त्यांना अंतहीन लूपमध्ये चालवले, तर ही तुमची तैनात केलेली मॉनिटरिंग सिस्टम आहे, जी अविरतपणे प्रत्येक गोष्टीची चाचणी करते - मग ती क्रॅश झाली की नाही. या प्रकरणात, फरक एवढाच आहे की ते एकदा किंवा दोनदा केले जाते. चाचण्यांचा एक अतिशय चांगला संच... अविरतपणे चालत आहे, हे निरीक्षण आहे. आणि योग्य देखरेख असे असावे.

आणि म्हणूनच, शुक्रवारी संध्याकाळी तयार होऊन घरी गेल्यावर तुम्ही ही स्थिती नेमकी कशी साधाल हा दुसरा प्रश्न आहे. कदाचित आपण फक्त एक धाडसी स्कंबॅग आहात.

सतत एकात्मतेकडे थोडे मागे जाऊया. आम्ही थोड्या वेगळ्या गुंतागुंतीच्या सरावात पळून गेलो.

आणि दुसरा भ्रम असा आहे की MVP, ते म्हणतात, त्वरीत करणे आवश्यक आहे, त्यामुळे तेथे चाचण्यांची अजिबात गरज नाही. त्या मार्गाने नक्कीच नाही. वस्तुस्थिती अशी आहे की जेव्हा आपण एमव्हीपीमध्ये वापरकर्ता कथा लिहिता तेव्हा आपण एकतर ती बॉलवर विकसित करू शकता, म्हणजे, आपण ऐकले की काही प्रकारची वापरकर्ता कथा होती आणि लगेच ती कोड करण्यासाठी धावला किंवा आपण टीडीडी वापरून कार्य करू शकता. आणि TDD नुसार, सराव दर्शविल्याप्रमाणे, यास जास्त वेळ लागत नाही, म्हणजे चाचण्या एक दुष्परिणाम आहेत. TDD चा सराव चाचणीबद्दल नाही. ज्याला टेस्ट ड्रायव्हन डेव्हलपमेंट म्हणतात ते असूनही, ते चाचण्यांबद्दल अजिबात नाही. हे देखील एक वास्तुशास्त्रीय दृष्टीकोन आहे. जे आवश्यक आहे ते लिहिण्याचा आणि आवश्यक नसलेल्या गोष्टी न लिहिण्याचा हा दृष्टीकोन आहे. अनुप्रयोग आर्किटेक्चर तयार करण्याच्या दृष्टीने आपल्या विचारांच्या पुढील पुनरावृत्तीवर लक्ष केंद्रित करण्याचा हा सराव आहे.

त्यामुळे या भ्रमातून मुक्त होणे इतके सोपे नाही. MVP आणि चाचण्या एकमेकांना विरोध करत नाहीत. अगदी, उलट, त्याउलट, जर तुम्ही TDD सराव वापरून MVP करत असाल, तर तुम्ही ते अजिबात सराव न करता, पण बॉलवर केल्‍यापेक्षा चांगले आणि जलद कराल.

ही एक अतिशय अस्पष्ट आणि गुंतागुंतीची कल्पना आहे. आता मी आणखी चाचण्या लिहीन आणि त्याच वेळी मी काहीतरी जलद करेन हे ऐकल्यावर ते अगदीच अपुरे वाटतं.

(दिमित्री) येथे बरेच लोक, जेव्हा ते MVP म्हणतात, तेव्हा लोक काहीतरी सामान्य लिहिण्यास खूप आळशी असतात. आणि या अजूनही वेगळ्या गोष्टी आहेत. MVP ला काही वाईट गोष्टीत बदलण्याची गरज नाही जी कार्य करत नाही.

होय, होय, तुम्ही बरोबर आहात.

आणि मग अचानक MVP in prod.

सर्वकाळ आणि सदैव.

आणि जेव्हा तुम्ही ऐकता की तुम्ही चाचण्या लिहिता आणि अधिक काम करता असे दिसते तेव्हा TDD खूप असामान्य वाटतो. हे खूप विचित्र वाटते, परंतु खरं तर ते या मार्गाने जलद आणि सुंदर बाहेर वळते. जेव्हा तुम्ही चाचणी लिहिता, तेव्हा तुम्ही आधीच तुमच्या डोक्यात खूप विचार करता की कोडला कोणता संबोधित केले जाईल आणि कसे, तसेच आम्ही त्यातून कोणते वर्तन अपेक्षित आहे. तुम्ही असे म्हणू नका की मी काही फंक्शन लिहिले आहे आणि ते काहीतरी करते. सुरुवातीला तुम्हाला वाटले होते की तिला अशा आणि अशा परिस्थिती आहेत, तिला अशा प्रकारे बोलावले जाईल. तुम्ही हे चाचण्यांसह कव्हर करता आणि यावरून तुम्हाला समजते की तुमचे इंटरफेस तुमच्या कोडमध्ये कसे दिसतील. याचा स्थापत्यशास्त्रावर मोठा परिणाम होतो. तुमचा कोड आपोआप अधिक मॉड्यूलर बनतो, कारण तुम्ही प्रथम त्याची चाचणी कशी कराल हे समजून घेण्याचा प्रयत्न करता आणि त्यानंतरच तो लिहा.

TDD सोबत माझ्या बाबतीत असे घडले की मी रुबी प्रोग्रामर असताना कधीतरी मी रुबी मेंटॉरची नियुक्ती केली होती. आणि तो म्हणतो: "चला TDD नुसार करू." मी विचार केला: "अरे, आता मला काहीतरी अतिरिक्त लिहावे लागेल." आणि आम्ही मान्य केले की दोन आठवड्यांच्या आत मी TDD वापरून पायथनमध्ये सर्व कार्यरत कोड लिहीन. दोन आठवड्यांनंतर, मला समजले की मला परत जायचे नाही. दोन आठवडे हे सर्वत्र लागू करण्याचा प्रयत्न केल्यानंतर, तुम्हाला समजेल की तुमच्यासाठी फक्त विचार करणे किती सोपे झाले आहे. परंतु हे स्पष्ट नाही, म्हणून मी प्रत्येकाला शिफारस करतो की जर तुम्हाला असे वाटत असेल की TDD कठीण, वेळखाऊ आणि अनावश्यक आहे, तर फक्त दोन आठवडे टिकून राहण्याचा प्रयत्न करा. माझ्यासाठी दोन पुरेसे होते.

(दिमित्री) आम्ही ही कल्पना पायाभूत सुविधांच्या ऑपरेशनच्या दृष्टिकोनातून विस्तृत करू शकतो. आम्ही काहीही नवीन लाँच करण्यापूर्वी, आम्ही मॉनिटरिंग करतो आणि नंतर लॉन्च करतो. या प्रकरणात, निरीक्षण आमच्यासाठी सामान्य चाचणी बनते. आणि देखरेखीच्या माध्यमातून विकास होतो. परंतु जवळजवळ प्रत्येकजण म्हणतो की ते लांब आहे, मी आळशी आहे, मी तात्पुरता मसुदा तयार केला आहे. जर आम्ही सामान्य निरीक्षण केले असेल, तर आम्हाला CI प्रणालीची स्थिती समजते. आणि सीआय सिस्टममध्ये भरपूर मॉनिटरिंग आहे. आपल्याला व्यवस्थेची स्थिती समजते, त्याच्या आत काय आहे ते आपल्याला समजते. आणि विकासादरम्यान, आम्ही फक्त प्रणाली बनवत आहोत जेणेकरून ती इच्छित स्थितीत पोहोचेल.

या पद्धती बर्याच काळापासून ज्ञात आहेत. आम्ही सुमारे 4 वर्षांपूर्वी याबद्दल चर्चा केली. परंतु 4 वर्षांत व्यावहारिकदृष्ट्या काहीही बदलले नाही.

पण या नोटवर, मी अधिकृत चर्चा संपवण्याचा प्रस्ताव मांडतो.

व्हिडिओ (मीडिया घटक म्हणून घातला, परंतु काही कारणास्तव कार्य करत नाही):

https://youtu.be/zZ3qXVN3Oic

स्त्रोत: www.habr.com