समानांतर विकास के लिए शाखा का उपयोग करने की मूल बातें

प्रविष्टि

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

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

रिलीज प्रबंधन

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

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

ब्रांचिंग का उपयोग करने से हमें एक पत्थर से दो पक्षियों को मारने की अनुमति मिलती है: रिलीज संस्करण का स्थिरीकरण (एक प्रक्रिया जिसे बग फिक्सिंग के रूप में जाना जाता है) का स्थिरीकरण करें और उसी समय अगली रिलीज के लिए नई कार्यक्षमता के साथ एप्लिकेशन का विस्तार करें। ये दो मुख्य हैं, हालांकि एकमात्र नहीं, एक परियोजना पर शाखा का उपयोग करने के तरीके।

कोड संस्करण के बारे में पाचन

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

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

प्रति रिलीज शाखा

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

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



प्रति सुविधा शाखा

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



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

शाखाओं के बीच एकीकरण

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



तस्वीर में दिखाई गई स्थिति पर विचार करें:

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

इस दृष्टिकोण के पेशेवरों और विपक्षों का मूल्यांकन करते समय, आपको ध्यान में रखना चाहिए:

• फ़ीचर शाखाएँ निरंतर एकीकरण के रास्ते में नहीं खड़ी होती हैं
• शब्दार्थ संघर्ष विशेष रूप से ब्रंचिंग के लिए विशिष्ट नहीं हैं
• फ़ीचर ब्रांच की तुलना में फ़ीचर टॉगलिंग और ब्रांच-बाय-एब्स्ट्रैक्शन में कुछ कमियां हैं।

मेनलाइन के माध्यम से एकीकरण एकीकृत करने का एकमात्र तरीका नहीं है - शाखाओं के बीच सीधे एकीकरण संभव है। मार्टिन फॉलर इस विधि को प्रमुख एकीकरण कहते हैं । इस एकीकरण विधि के लिए, परियोजना टीम के भीतर संचार बहुत महत्वपूर्ण है।

शाखा स्थिरता

इस तरह के मॉडल में स्थिरता का एक क्रम होता है, जहां रिलीज शाखाएं सबसे स्थिर होती हैं, मेनलाइन कम स्थिर होती है, और विकास शाखाएं सबसे अधिक अस्थिर होती हैं। एक नियम के रूप में, आरेख पर सबसे स्थिर शाखाएं सभी के ऊपर प्रदर्शित होती हैं, और अस्थिर - सभी के नीचे।



ओवरहेडिंग ब्रंचिंग के उपयोग के साथ जुड़ा हुआ है

निम्नलिखित लागत ब्रांचिंग से जुड़ी हैं:

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

शाखाओं और उन्हें हल करने के तरीकों के बीच निर्भरता के प्रकार

शाखाओं के बीच निम्नलिखित निर्भरताएँ हो सकती हैं:

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

ऐसी निर्भरताओं के साथ काम करने के लिए कई विशिष्ट समाधान हैं:

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

निष्कर्ष

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

एंटी ब्रांचिंग पैटर्न:

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