6

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

+0

एक समय में एक सुविधा विलय कर रहा है एक विकल्प नहीं। – rerun

उत्तर

5

यह निर्भर करता है कि आपने सुविधा क्यों छोड़ी।

यदि "आखिरी पल में" सिस्टम परीक्षण के दौरान है, और आप इसे दोहराना नहीं चाहते हैं, तो मैं कहूंगा कि आप बस सुविधा को अक्षम करते हैं और इसे वैसे भी भेजते हैं।

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

मेरा मतलब है कि UI तत्वों को हटाएं या छुपाएं जो सुविधा को सक्षम करते हैं, तो उपयोगकर्ताओं को यह नहीं पता होगा कि यह वहां है (बशर्ते यह डिफ़ॉल्ट रूप से बंद हो)।

उम्मीद है कि भविष्य में रिलीज के दौरान कोड के उस हिस्से को दोबारा करने का अवसर होगा और या तो सुविधा को हटा दें या इसे ठीक से पुन: पेश करें।

+0

लगभग सही (लेकिन अभी भी +1)। अक्षम करें, * आरई-टेस्ट *, फिर जहाज। सुविधा को अक्षम करने के लिए आवश्यक न्यूनतम परिवर्तन के साथ अक्षम करें। एक जीयूआई आधारित प्रणाली में, यह मेनू आइटम को अक्षम करने या हटाने के जितना आसान हो सकता है। अन्य प्रणालियों में, आपको न्यूनतम परिवर्तन को समझने की आवश्यकता है ... – Mawg

+0

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

1

यदि आप क्लाइंट के रूप में TortoiseSVN का उपयोग कर रहे हैं, तो इसके संदर्भ में संदर्भ में "इस संशोधन से रोल वापस परिवर्तन" है।

बस कार्यशील प्रतिलिपि पर लॉग दिखाएं, और उस संशोधन को चुनें जिसे आप रिवर्स-विलय करना चाहते हैं (मामले में, संशोधन जो विशेषता है कि आप विशेषता शाखा में विलय करते हैं)।

alt text http://img64.imageshack.us/img64/9053/svnreversemerge.png

अन्यथा, आप एक रिवर्स कर सकते हैं कमांड लाइन से मर्ज करें। रिवर्स विलय एक नया संशोधन बनाता है जो कि हेड संशोधन आपके द्वारा रिवर्स-विलय के संशोधन से किए गए परिवर्तनों से कम है, ताकि आप हमेशा "रिवर्स रिवर्स" विलय कर सकें। एसवीएन इस तरह से महान है।

+0

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

संबंधित मुद्दे

 संबंधित मुद्दे