एसवीएन में शाखाएँ

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

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

सृजन

एक शाखा बहुत सरलता से बनाई गई है:

svn copy svn://svnserver.ru///trunk svn://svnserver.ru///branches/_ -m '    ' 

अब, ताकि डेवलपर को परिवर्तन मुख्य विकास ट्रंक (ट्रंक) में नहीं बचाया जाता है, लेकिन चयनित शाखा में, उसे इस शाखा में स्विच करना होगा।

 cd ~/web// #      svn sw svn://svnserver.ru///branches/_ svn update #    ,     svn:externals    

अब आप शाखा में विकास का संचालन कर सकते हैं, इस चिंता के बिना कि अप्रयुक्त या असत्यापित समाधान उत्पादन में जाएंगे। उसी समय, डेवलपर अपने मेजबान LOGIN_RAZrabrabotchika के साथ काम करता है। परियोजना। CLIENT। Devinver.ru

तैयार या मध्यवर्ती समाधान दिखाने के लिए, इस शाखा के लिए एक परीक्षण मेजबान बनाया जाता है। इस प्रक्रिया को स्वचालित करना आवश्यक है ताकि डेवलपर्स इस पर समय व्यतीत न करें। प्रबंधक और परीक्षक हमेशा परीक्षण होस्ट NAME_VETKI.PROEKT.KLIENT.devserver.ru पर समाधान की जांच करते हैं। आप डेवलपर के होस्ट पर कुछ भी सत्यापित नहीं कर सकते। क्योंकि:

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

इसलिए, केवल अच्छा अभ्यास होगा:

1. कार्य पूरा करें
2. परिवर्तन करें
3. उन्हें टेस्ट सर्वर पर रोल करें
4. अपनी आँखों से कम से कम एक बार यह देखने के लिए कि सब कुछ सही ढंग से वहाँ लुढ़का हुआ है
5. कार्य में परीक्षण होस्ट पर समस्या स्थान के लिए एक लिंक प्रकाशित करें (मेगाप्लान या अन्य टास्कट्रैकर में)

उत्तरार्द्ध किया जाना चाहिए, भले ही यह लिंक कार्य में कई बार पाया गया हो। हड़बड़ी या लापरवाही के कारण वर्णित 5 क्रियाओं में से 4 को छोड़ दिया जा सकता है।

विलयन

प्रबंधक द्वारा समाधान की जाँच करने और कोई त्रुटि नहीं पाए जाने के बाद, आपको शाखा को ट्रंक में इंजेक्ट करने की आवश्यकता है।

मान लीजिए कि हमारे पास एक शाखा ए (ट्रंक) है, जिसमें मुख्य विकास चल रहा है। संशोधन 100 में, हम इसे से शाखा B को शाखा देते हैं (शाखाओं / TITLE_NAME) (A @ 100, B @ 101) फिर दोनों शाखाएं लंबे समय तक सक्रिय रूप से विकसित होती हैं (A @ 167, B @ 189) और हमें उनका विलय करना होगा। यदि आप "माथे पर" (sw A, मर्ज AB) का विलय करते हैं, तो बहुत सारे संघर्ष होंगे जिन्हें हल करना बहुत मुश्किल है। सही दृष्टिकोण इस प्रकार है:

 svn switch svn://svnserver.ru///branches/_ #   B svn merge -r 101:167 svn://svnserver.ru///trunk . #       A    ( ** **) svn ci -m 'merge with -r 101:167 trunk' #    (   ,    )  .         svn switch svn://svnserver.ru///trunk #   A svn merge svn://svnserver.ru///trunk svn://svnserver.ru///branches/_ . #     B svn ci -m 'merge with _@190' #      , ..    A    

मैं आपका ध्यान आकर्षित करता हूं: यदि शाखाएं पहले से ही अतीत में विलय कर चुकी हैं, तो यह आवश्यक है कि प्रारंभिक संशोधन के रूप में नवोदित संशोधन नहीं, लेकिन अंतिम संशोधन, जिसमें शाखाएं "समान" थीं। इसके अलावा, यह आवश्यक रूप से ए से बी में परिवर्तन का जलसेक नहीं हो सकता है, बी में ए में भी जलसेक हो सकता है।

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

विलय के बाद, आपको ट्रंक (trunk.PROEKT। CLIENT.devserver.ru) के लिए एक परीक्षण होस्ट बनाने या मौजूदा फ़ोल्डर को अपडेट करने की आवश्यकता है। उसके बाद, हम टास्क में टेस्ट होस्ट पर समस्या वाले स्थान के लिंक को टास्क में फेंक देते हैं। ऐसा क्यों करते हैं, क्योंकि हमने शाखा होस्ट में बदलाव की जाँच की है? ट्रंक में किए गए परिवर्तन या अन्य परिवर्तन जो ट्रंक में डाले गए थे वे हमारे द्वारा आवश्यक संपादन को प्रभावित कर सकते हैं। अक्सर, सीएसएस के कारण समस्याएं हो सकती हैं, जैसा कि बस सामान्य नियमों से कई वर्गों को प्रभावित होता है, लेकिन अन्य स्थितियां भी हैं। इसलिए, बाहर रोल करने से पहले ट्रंक पर एक और जांच बहुत आवश्यक है।

लापरवाह प्रबंधक

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

और इसलिए, निकट भविष्य में वह ग्राहक से एक छड़ी प्राप्त करेगा: "अब वेब पर अधिकांश ग्राहक IE ब्राउज़र का उपयोग नहीं कर सकते ... हमने पिछली बार कहा था कि आधे से अधिक उपयोगकर्ता इसका उपयोग करते हैं, इसलिए कृपया मुख्य रूप से IE पर सभी सुधारों का परीक्षण करें। कृपया इस त्रुटि को जल्द से जल्द ठीक करें! "

प्रबंधक कार्य "तत्काल" सेट करता है !!! त्रुटि !!! ”और अगली बार तक चेक के बारे में भूल जाता है।

"किए गए → चेक किए गए → (फिक्स्ड → चेक किए गए) * n → रोल आउट" एल्गोरिथ्म का उल्लंघन तत्काल कार्य-संपादन की उपस्थिति की ओर जाता है जो डेवलपर्स को लय से बाहर निकालता है और नियोजित कार्यों से विचलित होता है, ग्राहकों और उपयोगकर्ताओं के सामने हमारी समग्र प्रतिष्ठा को खराब करता है और इस प्रक्रिया को गति नहीं देता है।