निरंतर एकीकरण के साथ सबवर्सन

Question

क्षमा करें अगर इस प्रश्न का उत्तर पहले से मौजूद है, तो मुझे अभी तक उन्हें नहीं मिला।

मैं एक वेब विकास टीम का सदस्य हूं, हम एक वेब पोर्टल बनाए रखते हैं। रिलीज प्रबंधन सबवर्सन के साथ काम करता है। यह मैं जब पोर्टल में नई सुविधाएँ जोड़कर कैसे काम है:

• ट्रंक को कॉपी करके एक नई शाखा बनाएं
• कि शाखा में विकास करना
• समय समय पर कि शाखा में ट्रंक से अपडेट मर्ज (मैं चाहता हूँ यदि फ्रेमवर्क-परिवर्तन मेरी कोड तोड़ने पता है, इससे पहले कि यह UAT/एकता, जैसे)
• ट्रंक में शाखा को पुन: एकीकृत क्रम में यह लाइव हो

अब हम सतत के साथ एक समस्या है यह बताने के लिए को जाता है integr समझना:

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

क्या था के लिए सबसे अच्छा अभ्यास है टी? पुन: एकीकृत कई शाखाओं को विलय करने के लिए काम नहीं करता है, क्योंकि जैसे ही एक शाखा एकीकृत होती है, कार्यशील प्रति अब और साफ नहीं होती है। हालांकि, निरंतर एकीकरण किसी भी तरह संभव होना चाहिए ...

यदि प्रत्येक शाखा में ट्रंक परिवर्तन विलय हो जाते हैं, तो विभिन्न संशोधन किए जाते हैं। लेकिन फाइलों में एक ही सामग्री होनी चाहिए और बराबर होना चाहिए। क्या कोई मर्ज-ऑप्शन नहीं कह रहा है कि "दो नई/बदली गई फाइलें समान हैं तो एक संघर्ष को अनदेखा करें"?

किसी भी मदद के लिए धन्यवाद।

Answer 1

आप क्या वर्णित क्योंकि निम्नलिखित आवश्यकता के नहीं सतत एकीकरण है:

हर एक्स घंटे एक दिन, एकता सर्वर एक ट्रंक चेकआउट करता है और सभी शाखाओं (जो स्पष्ट रूप से एकीकरण प्रणाली के पास जाना चाहिए विलीन हो जाती है) में

रियल Continuous integration निम्नलिखित चरण शामिल हैं:

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

यदि आपके पास कई शाखाएं हैं, तो इसका मतलब है कि आपको प्रत्येक शाखा के लिए निरंतर एकीकरण करने के लिए कई शाखाओं के लिए कई बिल्ड योजनाओं को कॉन्फ़िगर करने की आवश्यकता है।

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

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

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

सारांश में,

1. अपनी प्रक्रिया से merge all branches कदम को बाहर करें (यह स्वचालित रूप से किया जा करने के लिए नहीं है)।
2. इसके बजाय मैन्युअल रूप से विलय करना।
3. यदि आपको यकीन है कि आपको हर समय शाखाएं रखने की ज़रूरत है, तो प्रत्येक शाखा अलग से के लिए लगातार एकीकरण कॉन्फ़िगर करें।
4. अन्यथा (आपको हर समय शाखाएं रखने की आवश्यकता नहीं है, और विकास समाप्त हो जाने के बाद उन्हें आसानी से मूल शाखा में फिर से जोड़ा जा सकता है) न्यूनतम पर शाखाओं की संख्या को कम करें।

शुभकामनाएं!