विजुअल स्टूडियो में विकास के 1 वर्ष के विलय के लिए रणनीतियाँ


32

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

मेरे प्रारंभिक मर्ज पुल पर, TFS ने संघर्ष समाधान के साथ ~ 6500 फ़ाइलों की सूचना दी। इनमें से कुछ आसान होंगे, लेकिन उनमें से कुछ अधिक कठिन होंगे (विशेष रूप से कुछ जावास्क्रिप्ट, एपीआई नियंत्रक और इन नियंत्रक का समर्थन करने वाली सेवाएं)।

क्या ऐसा कोई तरीका है जो मैं ले सकता हूं जो मेरे लिए यह आसान बना देगा?

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

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


63
नहीं। आपके पास दो अलग-अलग शाखाएं हैं जो एक वर्ष के लिए सक्रिय रूप से विकसित हुई थीं। मर्ज चूसने वाला है।
17 की 26

2
आपकी टीम ने किन बदलावों की सीमा तय की है? यह उन परिवर्तनों को पहचानने के लिए अधिक कुशल हो सकता है और फिर उन्हें वर्तमान मास्टर कोडबेस में मैन्युअल रूप से पुन: लागू कर सकता है।
kdgregory

2
क्या यह 2015 या 2016 की संपूर्णता है? अगर 2015 में इसकी 2 साल, जिसका मतलब है कि यह दोगुना हो जाएगा।
डेविड का कहना है कि

1
यदि क्लाइंट आपके लिए काम कर रहा है तो आपके संस्करण नियंत्रण प्रणाली में एक अलग शाखा पर क्यों है?
Ixrec

17
आप जो भी करते हैं, सुनिश्चित करें कि आप प्रति घंटा बिलिंग कर रहे हैं।
शॉन मैकसोमेलेशिंग

जवाबों:


37

एक सरल तरीका होता जो आपके नए विकास को इस दुर्भाग्यपूर्ण स्थिति में लाए बिना आपको मुख्य शाखा से अलग रखता था : ट्रंक से किसी भी परिवर्तन को दैनिक आधार पर आपकी देव शाखा में विलय कर दिया जाना चाहिए था । (क्या आपका मुवक्किल वास्तव में इतना छोटा था कि वह अनुमान नहीं लगा सकता था कि आपकी शाखा को अगले दिन मुख्य लाइन में वापस जाने की आवश्यकता है?)

वैसे भी, सबसे अच्छा तरीका IMHO है जो पहले हाथ पर क्या होना चाहिए, इसे फिर से करने की कोशिश कर रहा है:

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

यह तब काम कर सकता है जब टीमों ने सख्ती से संस्करण नियंत्रण के क्लासिक नियमों का पालन किया ("केवल प्रतिबद्ध, परीक्षण किए गए राज्य" और "जल्दी और अक्सर जांच")।

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

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

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


9
यदि आप पुन: एकीकरण के दौरान ट्रंक पर विकास जारी रख रहे हैं तो मेरा सुझाव है कि आप ट्रंक टिप को पहले शाखा दें और उसी से विकास करें। अन्यथा आप प्रभावी रूप से अतीत और भविष्य को एक साथ मिला रहे हैं। लेकिन मैं स्वाभाविक रूप से किसी भी अंतरिक्ष-समय की छूट पर डॉक्टर ब्राउन को टाल देता हूं।
राडारबॉब

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

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

यह अच्छी सलाह है। यहाँ कुछ चीजों को संबोधित करने के लिए संपादन देखें।
user258451

1
@ user258451: तो आपके पास ट्रंक और नई देव शाखा के लिए अलग-अलग क्यूए टीमें थीं जो एक-दूसरे से बात नहीं करना चाहती थीं? महान स्कॉट: - ((
डॉक ब्राउन

14

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

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

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

चाबी तो चलती ही रहती है।

संपादित करें:

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

'जैक एडली' और '17 ऑफ 26 'की टिप्पणियों के लिए धन्यवाद


1
इस दृष्टिकोण के साथ बड़ी समस्या यह है कि यह संस्करण नियंत्रण प्रणाली में छोड़े गए परिवर्तनों के रिकॉर्ड को नष्ट कर देगा।
जैक एदले

अनिवार्य रूप से मर्ज के दौरान दूसरी बार एक ही परिवर्तन करने से, आपके पास अभी भी परिवर्तनों का एक लॉग होगा, यह सिर्फ मर्ज में किए गए क्रम में होगा बजाय कि वे विकास के दौरान किए गए थे। आदर्श नहीं, लेकिन कुछ भी नहीं से बेहतर। इसके अलावा आप अभी भी मूल unmerged राज्य होगा, अगर वह संस्करण नियंत्रण में रखा गया था।
एरड्रिक आयरनरोज़

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

@ 17of26 जबकि मैं मानता हूं कि आप कुछ बदलावों के रिकॉर्ड को बहाल कर सकते हैं, 26 में से 17 सही है कि यह रिकॉर्ड पूर्ण या सटीक नहीं होगा। यह हो सकता है कि रिकॉर्ड के इस नुकसान को एक स्वीकार्य समझौता बनाने के लिए यह दृष्टिकोण पर्याप्त रूप से आसान हो, क्योंकि वे अब जिस बुरी स्थिति में हैं, उसे देखते हुए, हालांकि, मुझे लगता है कि वे जो भी निर्णय लेते हैं, उसे पहचानना एक महत्वपूर्ण दोष है।
जैक ऐडले

1
@ जेक एडले मैं निश्चित रूप से सहमत हूं कि यह काफी समस्या है, इसलिए मैंने अपने उत्तर को प्रतिबिंबित करने के लिए थोड़ा जोड़ा है। मुझे आशा है कि यह ठीक है?
एडरिक आयरनॉर्स

8

कुछ साल पहले हमारे पास शाखाओं को अलग रखने की समान आवश्यकताओं वाला एक ग्राहक था। तो हमने किया।

हमने कभी उनकी शाखा को वापस विलय नहीं किया। उनका अपना एक अनूठा संस्करण था। हमने उन परिवर्तनों के लिए अतिरिक्त शुल्क लिया क्योंकि अनिवार्य रूप से हमारे पास 1 मुख्य ट्रंक और शाखाओं के बजाय दो प्रमुख चड्डी थीं।

हमने वापस ट्रंक में विलय करने का प्रयास किया लेकिन 2 सप्ताह के बाद हमने उस प्रयास को छोड़ने का फैसला किया क्योंकि यह समय के साथ कोई ठोस लाभ नहीं था।

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


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

1

यह मजेदार होने वाला नहीं है, लेकिन यह कितना दर्दनाक होगा यह परिवर्तनों की प्रकृति पर निर्भर करता है, और वे कितने अलग हैं।

मेरा सुझाव है कि आप पहले जितना संभव हो, रिफैक्टरिंग के माध्यम से शाखाओं को जोड़ने का प्रयास करें वास्तविक मर्ज करने ।

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

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

कोड के उन क्षेत्रों में जहां दोनों शाखाओं में गैर-तुच्छ परिवर्तन हुए हैं, आपको सावधानीपूर्वक कोड का निरीक्षण करना होगा और फिर से लिखना होगा।

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