लंबी अवधि की परियोजनाओं के उत्पाद संस्करण और शाखाकरण को संभालने का सबसे अच्छा तरीका क्या है?


21

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

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

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


2
विकास टीम (ओं) के उत्पादों, परियोजनाओं और संगठन के बारे में अधिक जानकारी के बिना, इसका जवाब देना बहुत मुश्किल होने वाला है, जो कि केट से बचाव नहीं है।
ChrisF

@ क्रिस - मैं कुछ पृष्ठभूमि पर काम कर रहा हूं, लेकिन मुझे पूरा यकीन है कि अन्य डेवलपर्स यहां भी हैंग करते हैं, इसलिए मुझे निर्दोष / दोषी को बचाने की जरूरत है।
rjzii


आपकी सबसे अच्छी शर्त अन्य प्रश्नों की जांच करना होगा - जैसे कि ऊपर से जुड़ा हुआ है - और फिर बिट्स के लिए पूछें कि वे कवर नहीं करते हैं।
ChrisF

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

जवाबों:


20

आपको कितनी (और किस तरह की) संरचना की आवश्यकता है, इस पर बहुत कुछ निर्भर करता है कि आप क्या करने में सक्षम होना चाहते हैं। पता लगाएँ कि आप क्या बिना नहीं रह सकते हैं, आप क्या चाहते हैं, और आपको क्या परवाह नहीं है।

फैसलों का एक अच्छा उदाहरण हो सकता है:

वे चीजें जिनके बिना हम नहीं रह सकते हैं:

  • किसी भी समय किसी भी पिछले रिलीज को फिर से संगठित करने में सक्षम हो
  • किसी भी समय उत्पाद के कई समर्थित प्रमुख संस्करणों को बनाए रखने में सक्षम हो

चीजें जो हम करना चाहते हैं:

  • शाखा विलय के बारे में चिंता किए बिना चल रहे प्रमुख-सुविधा विकास (अगले प्रमुख रिलीज के लिए) करने में सक्षम हो
  • पिछले रिलीज के लिए रखरखाव अद्यतन करने में सक्षम हो

वे चीजें जिनके बिना हम रह सकते हैं:

  • वर्तमान कार्य से पिछले रिलीज तक परिवर्तनों के स्वचालित बैकपोर्टिंग
  • कभी-कभी कुछ दिनों या सप्ताह में प्रमुख सुविधा विकास को बाधित न करें

यदि उपरोक्त आपके लक्ष्य थे, तो आप इस तरह की प्रक्रिया अपना सकते हैं:

  1. अपने VCS के ट्रंक पर सभी विकास कार्य करें ("git में मास्टर")
  2. जब आप किसी बड़ी रिलीज़ के करीब होते हैं, तो प्रमुख फ़ीचर डेवलपमेंट को रोक दें, और एक-एक हफ्ते के लिए सिस्टम की स्थिरता पर ध्यान दें
  3. जब ट्रंक स्थिर लगता है, तो इस प्रमुख रिलीज के लिए एक शाखा बनाएं
  4. प्रमुख विशेषता विकास अब ट्रंक पर आगे बढ़ सकता है, जबकि शाखा पर केवल बग फिक्स और रिलीज की तैयारी की अनुमति है
  5. हालांकि, शाखा में किए जाने वाले सभी बग फिक्स को पहले ट्रंक पर परीक्षण किया जाना चाहिए; यह सुनिश्चित करता है कि वे भविष्य के सभी रिलीज में भी मौजूद रहेंगे
  6. जब आप रिलीज़ करने के लिए तैयार हों, तो शाखा पर एक VCS (VCS) टैग बनाएं; इस टैग का उपयोग किसी भी समय, एक ही शाखा पर आगे के काम के बाद भी किसी भी समय रिलीज़ को दोबारा बनाने के लिए किया जा सकता है
  7. इस प्रमुख रिलीज (मामूली रिलीज) के लिए आगे रखरखाव अब शाखा पर तैयार किया जा सकता है; प्रत्येक को रिलीज़ से पहले टैग किया जाएगा
  8. इस बीच, प्रमुख फीचर विकास अगले प्रमुख रिलीज की ओर बढ़ रहा है, यह ट्रंक पर जारी रह सकता है
  9. जब आप उस रिलीज़ के करीब आते हैं, तो उपरोक्त चरणों को दोहराएं, उस रिलीज़ के लिए एक नई रिलीज़ शाखा बना सकते हैं । यह आपको एक ही समय में अलग-अलग छोटी रिलीज़ जारी करने की क्षमता के साथ, एक ही समय में समर्थित स्थिति में कई प्रमुख रिलीज़, प्रत्येक को अपनी शाखा पर करने की अनुमति देता है।

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


+1 हालांकि, मैं यह जोड़ना चाहूंगा कि स्रोत नियंत्रण केवल आपके पर्यावरण का हिस्सा है। मैं किसी भी बिल्ड सर्वर (डेटा) पर एक वीएम स्नैपशॉट ले सकता हूं और साथ ही एक डेवलपमेंट एनवायरनमेंट का एक स्नैप शॉट भी ले सकता हूं, ताकि जरूरत पड़ने पर आप सीधे एक वास्तविक बिल्ड वातावरण में जा सकें।
नील टिबरेला

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

1
उदाहरण के लिए, यदि संस्करण 4.3 ट्रंक पर विकसित किया जा रहा है, और आपको 4.1.x संस्करण में बग को ठीक करना है, तो 4.1 शाखा पर बग को ठीक करें, 4.1 शाखा पर परीक्षण करें, इसे 4.2 शाखा में मर्ज करें, परीक्षण करें (और संभवतः इसे ठीक करें) 4.2 शाखा पर, इसे ट्रंक में मर्ज करें, फिर इसे ट्रंक पर परीक्षण (और संभवतः ठीक करें) करें।
दाऊद का कहना है कि मोनिका

1

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

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


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

1

Git एक संस्करण नियंत्रण उपकरण है - यह फ़ाइलों के संस्करणों का प्रबंधन करता है। कॉन्फ़िगरेशन प्रबंधन उपकरण के बाद आप क्या कर रहे हैं। थिएस इन एवेलेबल की बहुतायत से, लेकिन ज्यादातर आईबीएम की पसंद से $ $ $ अधिक है।

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

मुझे इसकी जानकारी नहीं है, लेकिन यह निश्चित है कि यह मौजूद होगा, गिट के लिए एक सीएम टूल एडिक्शन।


0

यह प्रश्न एक अन्य प्रश्न से काफी मिलता-जुलता प्रतीत होता है, जिसका उत्तर मैंने हाल ही में दिया।

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.