FeatureBranch

Git और Mercurial जैसे वितरित संस्करण नियंत्रण प्रणालियों (DVCS) के प्रसार के साथ, मैं तेजी से ब्रांचिंग (मर्ज) और मर्जिंग (विलय) के उचित उपयोग के बारे में चर्चाएं देख रहा हूं, और यह कैसे निरंतर एकीकरण (CI) के विचार में फिट बैठता है। इस मुद्दे को लेकर कुछ भ्रम है, खासकर जब बात ब्रांचिंग की और सीआई के विचारों की प्रासंगिकता की आती है।

सरल (पृथक) फ़ीचर शाखा

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

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





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

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

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

इस छवि के आकर्षण के बावजूद, कुछ समस्याएं इस दृष्टिकोण में दुबक सकती हैं।



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

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

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

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

समस्या जो हमें अधिक परेशान करती है वह है शब्दार्थ संघर्ष। सबसे सरल उदाहरण वह मामला हो सकता है जिसमें प्रोफेसर प्लम उस पद्धति का नाम बदलता है जिसे रेवरेंड ग्रीन अपने कोड में कहता है। उपकरण को फिर से संगठित करने से आपको समस्याओं के बिना विधि का नाम बदलने में मदद मिलेगी, लेकिन केवल आपके कोड में। इसलिए, अगर G1-6 में एक नया कोड होता है जो फू को कॉल करता है, तो प्रोफेसर प्लम को इसके बारे में नहीं पता होगा, क्योंकि यह परिवर्तन इसकी शाखा में नहीं है। जहां कुत्ते को दफनाया गया है, उसके बारे में जागरूकता केवल एक बड़े मर्ज में आएगी।

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

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

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

निरंतर एकीकरण

यह ऐसी समस्याएं हैं जिन्हें निरंतर एकीकरण को हल करना चाहिए। सीआई के साथ, मेरा चार्ट इस तरह दिखेगा।


यहां कई और मर्ज हैं, लेकिन विलय उन चीजों में से एक है, जो बहुत कम बार और शायद ही कभी टन में कम किया जाता है। नतीजतन, अगर प्रोफेसर प्लम कोड के उस हिस्से को बदल देता है जिस पर रेवरेंड ग्रीन निर्भर करता है, तो हमारा ग्रीन सहयोगी पी 1-2 मर्ज में बहुत पहले पता लगा लेगा। फिलहाल, उन्हें G1-6 के बजाय इन परिवर्तनों के साथ काम करने के लिए G1-2 को बदलना होगा (जैसा कि पिछले उदाहरण में था)।

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

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

प्रमुख एकीकरण

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



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

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

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

- डेव फ़ार्ले

यादृच्छिक एकीकरण बनाम निरंतर एकीकरण

और फिर भी, यदि पीआई सीआई से अलग है, तो किन मामलों में पीआई सीआई से बेहतर है?

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

ऐसे मामलों में, पीआई बीच में कुछ प्रदान कर सकता है। यह रेवरेंड ग्रीन को चुनने की अनुमति देता है कि प्रोफेसर प्लम परिवर्तनों को कब स्वीकार किया जाए। यदि प्रोफेसर प्लम पी 2 में कर्नेल एपीआई में कोई बदलाव करता है, तो रेवरेंड ग्रीन P1-2 आयात कर सकता है लेकिन जब तक प्रोफेसर प्लम अपना काम खत्म नहीं कर देता और मुख्य शाखा में विलय नहीं कर देता।

हालांकि, सामान्य तौर पर, मुझे नहीं लगता कि वीसीएस का उपयोग करके रिलीज के लिए कार्यक्षमता लाना एक अच्छा विचार है।

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

- डैन बोडर्ट

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

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

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

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

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