सबसे पहले, हम मस्तिष्क में निरंतर एकीकरण का परिचय देंगे

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

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

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

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

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

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

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

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


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