बहु-रिलीज विकास

Question

के साथ एसवीएन का उपयोग करना मेरी टीम अपने स्रोत नियंत्रण को प्रबंधित करने के लिए एसवीएन का उपयोग कर रही है। मुझे यह देखने का कार्य दिया गया है कि क्या हम जिस तरह से एसवीएन का उपयोग करते हैं, उसमें सुधार करने के लिए वैसे भी है।

मैंने एसवीएन पुस्तक में से अधिकांश पढ़ा है और दूसरों ने एसवीएन का उपयोग करने के तरीके में बहुत सारे शोध किए हैं।

मैं एक सिंहावलोकन देने जा रहा हूं कि हम svn का उपयोग कैसे करते हैं और उम्मीद है कि किसी के पास मेरे लिए कुछ सुझाव हैं।

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

हमारे पास आमतौर पर दो होते हैं, कभी-कभी तीन निर्धारित निर्धारित डिलीवरी एक ही समय में चलते हैं। उदाहरण के लिए मैं रिलीज 3 के लिए कोडिंग कर सकता हूं, लेकिन मैं या अन्य रिलीज 2 के लिए परीक्षण कर रहे हैं और रिलीज 1 के लिए अंतिम बग फिक्स कर रहे हैं। एक ही समय में एक उत्पादन फिक्स भी हो सकता है।

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

जब भी कोई रिलीज या उत्पादन फ़िक्स उत्पादन में जाता है तो हम कोड को वापस ट्रंक में विलय करते हैं। फिर हम इसे सभी सक्रिय शाखाओं में ट्रंक (या रिलीज शाखा जो अभी उत्पादन में गए) से विलय करते हैं।

जैसा कि आपने देखा होगा कि हम विलय करने में बहुत समय व्यतीत करते हैं।

यह स्रोत नियंत्रण के नियंत्रण में व्यक्ति के लिए बहुत काम है। वे लगातार विलय कर रहे हैं और यह सुनिश्चित कर रहे हैं कि वे ट्रैक रखें कि किन शाखाओं को विलय कर दिया गया है।

ऐसा लगता है कि यह हमारे स्रोत नियंत्रण प्रबंधन प्रणाली के रूप में एसवीएन की तरह लगता है (मुझे पता है कि यह वास्तव में केवल संस्करण नियंत्रण है, लेकिन हम इसका उपयोग अपने स्रोत नियंत्रण को प्रबंधित करने के लिए कर रहे हैं) इसके साथ हमें मदद करने में सक्षम होना चाहिए।

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

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

धन्यवाद!

Answer 1

मुझे नहीं पता कि आप वास्तविक रूप से इस तरह की स्थिति को मंच पर प्रश्नों और उत्तरों के माध्यम से काम कर सकते हैं। आपका सबसे अच्छा विकल्प मेरे नियोक्ता, कोलाबनेट जैसी कंपनी से व्यावसायिक सेवाओं को देखना हो सकता है। Subversion Training Options

चलिए एक पल के लिए "ट्रंक" जैसे नामों को अलग करते हैं क्योंकि इन चीजों का अर्थ है जो भी आप चाहते हैं। मैं अपाचे सबवर्जन के लिए कमेटरों में से एक हूं और मैं कुछ हद तक विकास करने की सिफारिश करता हूं जैसे हम सबवर्सन के लिए करते हैं।

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

यह मॉडल अच्छी तरह से काम करता है क्योंकि परिवर्तन हमेशा एक ही दिशा में विलय और आप किसी को कुछ रिहाई के लिए त्वरित सुधार कर रही है और फिर ट्रंक में है कि एक ही ठीक करना भूल जाते हैं के बारे में चिंता करने की जरूरत नहीं है। तो बग अगली रिलीज में बैक अप नहीं दिखाता है।

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