ब्रांचिंग और विलय रणनीतियां

Question

मुझे अगले 6 महीनों में ब्रांचिंग, विलय और रिलीज करने की रणनीति के साथ आने का काम सौंपा गया है।

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

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

मुझे कौन सी रणनीतियों को नियोजित किया जाना चाहिए और योजना को निर्धारित करने से पहले मुझे किन बातों पर विचार करना चाहिए?

क्षमा करें अगर यह अस्पष्ट है, तो प्रश्न पूछने में संकोच न करें और यदि आवश्यक हो तो मैं अधिक जानकारी के साथ अपडेट करूंगा।

Answer 1

यह एकल सबसे अच्छा source control pattern है कि मैं भर में आ गए हैं। यह ट्रंक को किसी भी जंक से मुक्त करने के महत्व पर जोर देता है (ट्रंक में कोई जंक नहीं)। विकास शाखाओं में विकास किया जाना चाहिए, और नियमित विलय (कोड का परीक्षण करने के बाद) को ट्रंक (Pic 1) में वापस किया जाना चाहिए, लेकिन मॉडल अभी भी विकास के दौरान स्रोत को पैच करने की अनुमति देता है (Pic 2)। मैं निश्चित रूप से पूरी तरह से समझने के लिए, पूरी तरह से पोस्ट पढ़ने की सलाह देते हैं।

  Pic 1

  Pic 2

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

Answer 2

उपवर्तन पुस्तक some common branching patterns का वर्णन करती है। शायद आप इन्हें टीएफएस पर भी लागू कर सकते हैं।

Answer 3

मेरी पहली सिफारिश एरिक सिंक के Source Control HOWTO - विशेष रूप से branches और branch merge अध्याय पढ़ने के लिए होगी।

हमारे पास 3 कंटेनर हैं - हमारे काम के लिए DEV, MAIN, और रिलीज। मुख्य में हमारे सभी "तैयार-रिलीज" कोड शामिल हैं और हम इसे "मूल रूप से स्थिर" के रूप में सोचते हैं। DEV/Iteration (या DEV/फ़ीचर, या DEV/RiskyFeatureThatMightBreakSomeoneElse) MAIN से शाखाएं हैं और जब विचलन/फ़ीचर DEV वातावरण के पिछले प्रचार के लिए तैयार है तो विलय हो जाता है। हमारे पास टीएफएस भी DEV/Iteration शाखा और मुख्य शाखा से स्थापित है।

हमारे रिलीज कंटेनर में क्रमांकित रिलीज शामिल हैं (कई सबवर्जन रिपॉजिटरीज़ में उपयोग किए जाने वाले "टैग" कंटेनर के समान)। हम हर बार मुख्य रूप से मेन से एक शाखा लेते हैं - मुझे यह कहना पसंद है कि हम एक रिलीज शाखा को "काट रहे हैं" यह इंगित करने के लिए कि विलय समाप्त होने के बाद बहुत सारी गतिविधियां नहीं चलनी चाहिए।

VSS- के रूप में> TFS - माइक्रोसॉफ्ट एक upgrade path जो अपने संस्करण इतिहास रखना चाहिए का समर्थन करता है, लेकिन अगर आप यह इतिहास की जरूरत नहीं है, मैं सिर्फ, वीएसएस से नवीनतम संस्करण प्राप्त TFS में जाँच करेगा और वीएसएस भंडार संग्रहित करें।

एक अंतिम युक्ति - अपने टीम के सदस्यों को स्रोत नियंत्रण से परिचित करें। उन्हें ब्रांचिंग और विलय करना समझना चाहिए या आप बहुत सारे सफाई कार्य कर रहे होंगे :)।

शुभकामनाएं!

Answer 4

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

ट्रंक आपका मुख्य स्रोत है। इसमें "नवीनतम और महानतम" कोड शामिल है और आगे की ओर देख रहा है। यह आमतौर पर हमेशा स्थिर नहीं है।

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

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

आप भावी रिलीज़ बनाने के रूप में यह एक अच्छा विचार भी नए शाखाओं पर बड़े ग्राहकों को स्थानांतरित करने के शाखाओं की संभावित संख्या को कम करने के लिए आप हो सकता है की कोशिश करने के लिए है वापस पैच एक बग में तय।

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