सवाल
क्या उत्पादन के लिए SVN का उपयोग करने का कोई वैध कारण नहीं है, या यह केवल व्यक्तिगत पसंद का मामला है और SVN के खिलाफ कोई वास्तविक मामला नहीं है?
पृष्ठभूमि
मेरे कार्यस्थल में एसवीएन में रिलीज को टैग करने की संस्कृति है और फिर उन रिलीज को सीधे विभिन्न वेब सर्वरों में उपयोग करके svn coया svn switchसीधे उत्पादन में शामिल करना है।
मुझे व्यक्तिगत रूप से इससे समस्या है क्योंकि मेरा मानना है कि बिना बिल्ड और स्क्रिप्ट का उपयोग किए बिना या कुछ फॉर्म या स्वचालित रूप से आप इंटीग्रेटेड एनवायरनमेंट सेटिंग्स खो देते हैं क्योंकि वे अनडॉस्म्ड हैं। हालाँकि इससे भी अधिक मुझे यह महसूस होता है कि ऐसा करने के लिए एक गुप्त खतरा हो सकता है जिसे अनदेखा कर दिया गया है, जो अभी तक अपने बदसूरत सिर को पीछे करने के लिए है।
मैंने ऑपरेशन स्टाफ के साथ अपनी चिंताओं को उठाया है जो हमारे विभिन्न वातावरणों (कोडिंग, पूर्व-प्रोडक्शन, उत्पादन) आदि के लिए कोड को तैनात करने के लिए जिम्मेदार हैं। उनके तर्क बहुत ज्यादा थे कि यह अब तक बहुत अच्छा काम किया है, बदलने का कोई कारण नहीं है।
संपादित करें:
निर्माण और तैनाती के बारे में मेरा क्या मतलब है:
उदाहरण के लिए, यदि किसी डेवलपर को किसी विशेष वातावरण के लिए एक web.config सेटिंग की आवश्यकता होती है। Web.config को आमतौर पर svn में नहीं रखा जाता है और इसलिए इन फ़ाइलों को बिना किसी स्वचालित निर्माण स्क्रिप्ट के मैन्युअल रूप से अपडेट किया जाता है। इसलिए यदि वे खो गए हैं या OPS एक रिलीज़ के लिए web.config में फ़ील्ड जोड़ना भूल गए हैं तो आपके पास समस्याएँ हैं।
एक बिल्ड स्क्रिप्ट जो कहती है कि किसी विशेष वातावरण के लिए उपयुक्त web.config को स्वचालित रूप से उत्पन्न करने के लिए XMLPoke का उपयोग करता है, आदर्श है कि आपके पास एक संस्करण योग्य स्क्रिप्ट है जो आपके प्रत्येक वातावरण के लिए आवश्यक सभी परिवर्तनों को दस्तावेज़ करती है।
करंट बिल्ड एंड डिप्लो मेथड
परियोजना के लिए सवाल में एक डेवलपर मैन्युअल रूप से एक रिलीज बनाता है, अन्य परियोजनाओं में बिल्ड चरण स्वचालित रूप से NANT, या MSBuild के साथ होता है जो ठीक है।
अधिकांश प्रोजेक्ट्स के लिए डेटाबेस माइग्रेशन DB स्क्रिप्ट, या माइग्रेशन स्क्रिप्ट (Migrator.NET), या CMS पैकेज के माध्यम से होते हैं।
सीआई आमतौर पर टीम सिटी द्वारा एक चेकइन आधार पर किया जाता है, हमारे पास एक कोड समीक्षा प्रक्रिया है जो सभी टिकट शाखाओं में की जाती है और फिर ट्रंक (अच्छी तरह से काम करता है) में जांच से पहले सत्यापन और शुद्धता / गुणवत्ता के लिए समीक्षा की जाती है।
हालाँकि, वास्तविक कोड तैनाती SVN के माध्यम से हमेशा बहुत अधिक होती है, या तो टैग किए गए रिलीज़ के चेकआउट के माध्यम से या फिर आमतौर पर SVN स्विच के माध्यम से। यह कुछ ऐसा है जो मेरे साथ अजीब लगता है कि हम अपनी रिपॉजिटरी का उपयोग तैनाती प्रक्रिया के हिस्से के रूप में कर रहे हैं।
कॉन्फ़िगरेशन आमतौर पर बहुत बार नहीं बदलता है, केवल वही चीजें जो कॉन्फ़िगरेशन फ़ाइलों में होंगी वे पर्यावरण विशिष्ट जानकारी हैं। बाकी सब db में है।
मुझे यह काम गलत नहीं लगता, यह अच्छी तरह से काम करता है। हालाँकि मैं एक स्वचालित निर्माण और तैनाती के लिए प्रयास करना चाहता हूं। मैंने इसका उपयोग रेल्स और कैपिस्ट्रानो के साथ, और व्यक्तिगत परियोजनाओं के लिए सिग्विन, नेंट और एसएसएच का उपयोग करके किया है।
अधिक महत्वपूर्ण बात यह है कि मुझे अपने सहयोगियों को एक स्वचालित निर्माण और तैनाती का उपयोग करने के लिए बदलने के लिए बहुत विशिष्ट मान्य तर्क की आवश्यकता होगी।
या विशेष रूप से उत्पादन में तैनात करने के लिए एसवीएन का उपयोग करने के खिलाफ कोई वास्तविक वैध तर्क नहीं हैं?