आपातकालीन सुधारों के लिए एसवीएन रेपो कैसे सेट करें?

Question

कई सालों से डेवलपर होने के नाते यह मुझे कुछ पता होना चाहिए लेकिन नहीं।

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

यह आम तौर पर ठीक काम करता है सिवाय इसके कि हमारे पास परिस्थितियों में आपातकालीन/तत्काल परिवर्तन की आवश्यकता होती है जब ट्रंक में कोड को अंतिम रूप दिया नहीं जाता है।

मैं इस स्थिति को समायोजित करने के लिए रेपो कैसे स्थापित कर सकता हूं? मैंने सोचा कि this response एक अच्छा जवाब था लेकिन यह अभी भी मेरे सिर पर थोड़ा सा है।

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

यानी। इस स्थिति मैं एक बेहतर समाधान है क्योंकि के लिए यह कुछ समय

• रेव 1000 उत्पादन
• रेव 1001-1005 पर अद्यतन किया जाता है कर रहे हैं नई सुविधा अनुरोधों/बग फिक्स कि में शामिल किया जाएगा आ गई है चाहता हूँ अगले संस्करण
• रेव 1006 एक तत्काल ठीक कर अधिक सुविधा अपडेट
• रेव 1010 उत्पादन
• रेव 1007-1009 के लिए कर रहे धक्का दिया करने की आवश्यकता है कि अगले संशोधन उत्पादन

के लिए अद्यतन किया जाना चाहिए है

अद्यतन:

की SVN बुक शाखाओं में अनुभाग के माध्यम से पढ़ने के बाद, मैं निम्नलिखित स्थापना के बारे में सोच रहा हूँ।

1. शाखा बनाएं जब

   svn copy /trunk /branches/production_01 -m 'Production release'

2. उत्पादन पर ठेस, उत्पादन शाखा

   svn switch /branches/production_01

3. करने के लिए एक स्विच करना एक तत्काल ठीक है, तो पुश करने के लिए तैयार आवश्यक, डेवलपर को शाखा में बदलाव करने की जरूरत है:

   svn checkout /branches/production_01
// make changes
svn merge /trunk # make sure changes get merged into trunk as well
svn commit -m 'Urgent fix

4. उत्पादन पर, अद्यतन नवीनतम शाखा

   svn update

इससे मिलती-जुलती इस प्रक्रिया ध्वनि हमारे सेटअप के लिए काम करेगा करता है?

Answer 1

इस समस्या से निपटने के विभिन्न तरीके हैं, लेकिन मुझे लगता है कि सबसे कारगर तरीका मैंने यह किया देखा है निम्नलिखित है:

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

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

दोष यह है कि आपको प्रत्येक शाखा के लिए विभिन्न ऐप सर्वर डोमेन, प्लस ट्रंक और प्री-प्रोड के साथ विभिन्न सीआई वातावरण की आवश्यकता है।

Answer 2

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

आपकी स्थिति में मैं एक स्थायी production शाखा रखूंगा। जब भी आप एक सामान्य रिलीज करते हैं, तो इसे trunk में स्थिर करें, trunkproduction में विलय करें, और वहां से परीक्षण करें और दबाएं।

एक हॉटफिक्स के लिए, production से एक नई शाखा बनाते हैं, तो में अपने परिवर्तन करें, तो यह दोनों विलय production और trunk में। आपकी सामान्य रिलीज के साथ, आप production से परीक्षण और धक्का देते हैं।सबसे पुराना शाखा से

---

हमेशा शाखा आप में वापस मर्ज करने के लिए करना चाहते हैं। यह विलय को अधिक स्वच्छ बनाता है।

Answer 3

वास्तव में इसे प्राप्त करने के कई तरीके हैं। हॉटफिक्स को लागू करने की विधि संशोधन नियंत्रण और प्रोजेक्ट रिलीज़ की समग्र प्रक्रिया पर निर्भर करती है।

1. /trunk मुख्य विकास शाखा, को छोड़कर जब व्यापक काम इस तरह के नए प्रमुख विशेषताओं के रूप में जगह लेता है सक्रिय विकास के लिए इस्तेमाल होता है: इस तरह के रूप में, मैं बुनियादी revision control प्रक्रिया हम अपने सभी परियोजनाओं के लिए रोजगार का वर्णन करके मेरा उत्तर उपसर्ग जाएगा या refactoring। इस मामले में डेवलपर /branches/foo पर प्रतिलिपि बनायेगा, फिर काम पूरा होने पर /trunk में वापस विलय करें। मुख्य रूप से /trunk में काम करना या शाखाओं का उपयोग करना डेवलपर्स की संख्या, परियोजना की जटिलता, परियोजना का मंच और विकास की गति पर निर्भर करता है। किसी भी मामले में, /trunk को यथासंभव स्थिर रखने की कोशिश करना सबसे अच्छा है।
2. एक बार मील का पत्थर तक पहुंचने के बाद, और /trunk में काम उत्पादन साइट पर रिलीज के लिए तैयार है, /trunk की प्रतिलिपि बनाई गई है, उदाहरण के लिए, /tags/2.5.0 (इस रिलीज़ के लिए संस्करण संख्या)।
3. यह रिलीज पहले एकसैंडबॉक्स साइट (उदा, test.example.com) svn switch ^/tags/2.5.0 (नोट कैरेट (^) URL में अंकन;) का उपयोग करने के लिए लागू किया जाता है और समीक्षा के लिए ग्राहक या गुणवत्ता आश्वासन टीम के लिए दिखाया गया है।
4. यदि ग्राहक या क्यूए टीम समायोजन का अनुरोध करता है, तो चरण 1-3 दोहराया जाता है और मामूली संस्करण संख्या बढ़ जाती है (उदाहरण के लिए, /tags/2.5.1 पर)।
5. एक बार सैंडबॉक्स साइट का परीक्षण और रिलीज के लिए अनुमोदित होने के बाद, सैंडबॉक्स साइट लॉन्च करने के लिए उपयोग किए जाने वाले एक ही चरण उत्पादन स्थल (यानी svn switch ^/tags/2.5.1) पर लागू होते हैं।

तो फिर, इस मामले में हम उत्पादन साइट के लिए एक तत्काल हॉटफिक्स लागू करने की आवश्यकता है, हम करेंगे:

1. ठीक सीधे रिलीज़ संस्करण के लिए /tags/2.5.1 पर /tags/2.5.1 की एक स्थानीय काम कर प्रति का उपयोग कर लागू करें या सीधे सैंडबॉक्स साइट पर।
2. यदि स्थानीय कार्य प्रतिलिपि में परिवर्तन किए गए थे तो हम परिवर्तन और अद्यतन (svn up) सैंडबॉक्स साइट करेंगे। फिर हम समीक्षा/अनुमोदन प्रक्रिया दोहराते हैं।
3. एक बार स्वीकृत होने के बाद, बस उत्पादन साइट (svn up) अपडेट करें।
4. /tags/2.5.1 पर रिलीज़ संस्करण में किए गए परिवर्तन /trunk में विलय कर दिए गए हैं।