मान लीजिए कि आपके पास एक विशिष्ट वेब ऐप है और फ़ाइल कॉन्फ़िगरेशन के साथ है। परियोजना पर काम करने वाले प्रत्येक डेवलपर के पास अपने देव बक्से के लिए एक संस्करण होगा, एक देव, ठेस और मंच संस्करण होंगे। आप स्रोत नियंत्रण में इससे कैसे निपटते हैं? इस फ़ाइल में बिल्कुल भी जांच न करें, इसे अलग-अलग नामों से जांचें या कुछ पूरी तरह से फैंसी करें?
जवाबों:
मैंने अतीत में जो भी किया है वह एक डिफ़ॉल्ट कॉन्फिग फाइल है जिसे सोर्स कंट्रोल में चेक किया गया है। फिर, प्रत्येक डेवलपर की अपनी स्वयं की ओवरराइड कॉन्फ़िग फ़ाइल होती है जिसे स्रोत नियंत्रण से बाहर रखा जाता है। ऐप पहले डिफ़ॉल्ट को लोड करता है, और फिर यदि ओवरराइड फ़ाइल मौजूद है, तो डिफ़ॉल्ट फ़ाइल की वरीयता में ओवरराइड से किसी भी सेटिंग्स को लोड करता है और उपयोग करता है।
सामान्य तौर पर, छोटे ओवरराइड बेहतर फ़ाइल करते हैं, लेकिन यह हमेशा एक डेवलपर के लिए बहुत ही गैर-मानक वातावरण के साथ अधिक सेटिंग्स शामिल कर सकता है।
विन्यास है कोड, और आप इसे संस्करण चाहिए। हम उपयोगकर्ता नाम पर अपनी कॉन्फ़िगरेशन फ़ाइलों को आधार बनाते हैं; UNIX / Mac और Windows दोनों में आप उपयोगकर्ता के लॉगिन नाम का उपयोग कर सकते हैं, और जब तक ये प्रोजेक्ट के लिए अद्वितीय हैं, तब तक आप ठीक हैं। आप इसे पर्यावरण में भी ओवरराइड कर सकते हैं, लेकिन आपको करना चाहिए सब कुछ नियंत्रित ।
यह आपको दूसरों के कॉन्फ़िगरेशन की जांच करने की भी अनुमति देता है, जो बिल्ड और प्लेटफ़ॉर्म समस्याओं का निदान करने में मदद कर सकता है।
उस फ़ाइल का संस्करण न करें। एक टेम्पलेट या कुछ और संस्करण।
मेरी टीम प्रत्येक वातावरण (web.config.dev, web.config.test, web.config.prod) के लिए अलग-अलग फ़ाइलों के संस्करण रखती है। हमारी परिनियोजन स्क्रिप्ट सही संस्करण को कॉपी करती है, इसका नाम बदलकर web.config कर दिया जाता है। इस तरह, हमारे पास प्रत्येक पर्यावरण के लिए कॉन्फिग फाइलों पर पूर्ण संस्करण नियंत्रण है, आसानी से एक अंतर प्रदर्शन कर सकते हैं, आदि।
वर्तमान में मेरे पास उदाहरण के लिए अतिरिक्त एक्सटेंशन के साथ "टेम्पलेट" कॉन्फिग फ़ाइल है:
web.config.rename
हालाँकि, मैं इस पद्धति के साथ एक समस्या देख सकता हूं यदि महत्वपूर्ण परिवर्तन हुए हैं।
टेम्पलेट दृष्टिकोण पर +1।
लेकिन चूंकि इस प्रश्न में Git को टैग किया गया है, इसलिए मन को वितरित वैकल्पिक स्प्रिंग्स, जिसमें अनुकूलन एक निजी परीक्षण शाखा पर रखे गए हैं:
A---B---C---D--- <- mainline (public)
\ \
B'------D'--- <- testing (private)
इस योजना में, मेनलाइन में एक सामान्य, "टेम्प्लेट" कॉन्फ़िगरेशन फ़ाइल होती है, जिसमें कार्यात्मक बनने के लिए न्यूनतम मात्रा में समायोजन की आवश्यकता होती है।
अब, डेवलपर्स / परीक्षक अपने दिल की सामग्री के लिए कॉन्फ़िगर फ़ाइल को ट्विक कर सकते हैं, और केवल एक निजी परीक्षण शाखा (जैसे बी '= बी + अनुकूलन) पर स्थानीय रूप से इन परिवर्तनों को करते हैं। हर बार मेनलाइन एडवांस में, वे सहजता से इसे परीक्षण में मिला देते हैं, जिसके परिणामस्वरूप मर्ज कमिट्स जैसे डी '(= बी के कस्टमाइज़ेशन का डी + मर्ज किया गया संस्करण) होता है।
यह योजना वास्तव में चमकती है जब "टेम्प्लेट" कॉन्फिग फ़ाइल अपडेट की जाती है: दोनों पक्षों के परिवर्तन मर्ज हो जाते हैं, और असंगत होने पर (या परीक्षण विफलताओं) होने की संभावना होती है!
हमारे द्वारा उपयोग किए जाने वाले समाधान में केवल एकल कॉन्फ़िगरेशन फ़ाइल (web.config / app.config) है, लेकिन हम उस फ़ाइल में एक विशेष खंड जोड़ते हैं जिसमें सभी वातावरणों के लिए सेटिंग्स हैं।
वहाँ एक स्थानीय, देव, गुणवत्ता आश्वासन, उत्पादन वर्गों प्रत्येक हमारे कॉन्फ़िग फ़ाइल (ओं) में है कि वातावरण के लिए प्रासंगिक विन्यास कुंजियों युक्त।
यह सब काम xxx.Environment नाम की एक असेंबली है जो हमारे सभी अनुप्रयोगों (winforms और webforms) में संदर्भित है जो उस एप्लिकेशन को बताता है कि यह किस पर्यावरण पर काम कर रहा है।
Xxx.Environment विधानसभा मशीन की जानकारी की एक पंक्ति पढ़ता है । दी गई मशीन कीconfig जो यह बताती है कि यह DEV, QA, आदि पर है। यह प्रविष्टि हमारे सभी वर्कस्टेशन और सर्वर पर मौजूद है।
उम्मीद है की यह मदद करेगा।
मैंने हमेशा कॉन्फ़िगर फ़ाइलों के सभी संस्करणों को स्रोत नियंत्रण में रखा है, web.config फ़ाइल के समान फ़ोल्डर में।
उदाहरण के लिए
web.config
web.qa.config
web.staging.config
web.production.config
मैं इस नामकरण सम्मेलन को पसंद करता हूं (जैसा कि web.config.production या production.web.config के विपरीत है)
डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल को इस तरह कॉन्फ़िगर किया जाना चाहिए कि आप स्थानीय रूप से अपनी मशीन पर एप्लिकेशन चला सकें।
सबसे महत्वपूर्ण बात, ये फाइलें हर पहलू में लगभग 100% समान होनी चाहिए, यहां तक कि स्वरूपण भी। आपको इंडेंट करने के लिए एक संस्करण में टैब और दूसरे में रिक्त स्थान का उपयोग नहीं करना चाहिए। आपको फाइलों के खिलाफ एक अलग उपकरण चलाने में सक्षम होना चाहिए ताकि यह देखा जा सके कि उनके बीच क्या अंतर है। मैं फ़ाइलों को अलग करने के लिए WinMerge का उपयोग करना पसंद करता हूं।
जब आपकी निर्माण प्रक्रिया बायनेरिज़ बनाती है, तो एक ऐसा कार्य होना चाहिए जो उस वातावरण के लिए उपयुक्त फ़ाइल के साथ web.config को अधिलेखित कर दे। यदि फ़ाइलों को ज़िप किया गया है, तो गैर-प्रासंगिक फ़ाइलों को उस बिल्ड से हटा दिया जाना चाहिए।
मैंने पहले टेम्प्लेट का उपयोग किया है, अर्थात web.dev.config, web.prod.config, आदि, लेकिन अब 'ओवरराइड फ़ाइल' तकनीक पसंद करते हैं। Web.config फ़ाइल में अधिकांश सेटिंग्स होती हैं, लेकिन बाहरी फ़ाइल में db कनेक्शन जैसे पर्यावरण-विशिष्ट मान होते हैं। पॉल विल्सन के ब्लॉग पर अच्छी व्याख्या ।
मुझे लगता है कि यह कॉन्फ़िगरेशन फ़ाइलों के बीच दोहराव की मात्रा को कम करता है जो नए मूल्यों / विशेषताओं को जोड़ते समय दर्द पैदा कर सकता है।
मैं संस्करण को नियंत्रित करता हूं, लेकिन कभी भी इसे अन्य सर्वरों पर नहीं धकेलता। यदि उत्पादन सर्वर को बदलाव की आवश्यकता होती है, तो मैं उस परिवर्तन को सीधे कॉन्फ़िगर फ़ाइल में करता हूं।
यह सुंदर नहीं हो सकता है, लेकिन यह ठीक काम करता है।
एप्लिकेशन / web.config के चेक-इन, सादे-वेनिला संस्करण को सभी डेवलपर मशीनों पर काम करने के लिए पर्याप्त सामान्य होना चाहिए, और किसी भी नए सेटिंग परिवर्तन के साथ अद्यतित रखा जाना चाहिए, अगर आपको देव के लिए सेटिंग्स के एक विशिष्ट सेट की आवश्यकता है। / परीक्षण / उत्पादन सेटिंग्स, उन सेटिंग्स के साथ अलग-अलग फाइलों में जांच करें, जैसा कि गेटकीलर ने कहा, किसी प्रकार के नामकरण सम्मेलन के साथ, हालांकि मैं आमतौर पर "web.prod.config" के साथ जाता हूं, क्योंकि फ़ाइल एक्सटेंशन को बदलना नहीं है।
हम एक टेम्पलेट विन्यास फाइल का उपयोग करते हैं जिसे संस्करण नियंत्रण में जांचा जाता है और फिर पर्यावरण-विशिष्ट सेटिंग्स के साथ टेम्पलेट फ़ाइल में विशिष्ट प्रविष्टियों को बदलने के लिए हमारे स्वचालित निर्माण में एक कदम है। पर्यावरण-विशिष्ट सेटिंग्स को एक अलग XML फ़ाइल में संग्रहीत किया जाता है जो संस्करण नियंत्रण में भी है।
हम अपने स्वचालित निर्माण में MSBuild का उपयोग कर रहे हैं, इसलिए हम मूल्यों को अद्यतन करने के लिए MSBuild सामुदायिक कार्य से XmlUpdate कार्य का उपयोग करते हैं।
एक लंबे समय के लिए, मैंने वही किया है जो bcwood ने किया है। मैं स्रोत नियंत्रण के तहत web.dev.config, web.test.config, web.prod.config इत्यादि की प्रतियां रखता हूं, और फिर मेरी बिल्ड / तैनाती प्रणाली उन्हें स्वचालित रूप से नामांकित करती है क्योंकि यह विभिन्न वातावरणों में तैनात है। आप फ़ाइलों के बीच अतिरेक की एक निश्चित मात्रा प्राप्त करते हैं (विशेष रूप से सभी asp.net सामान के साथ), लेकिन आम तौर पर यह वास्तव में अच्छी तरह से काम करता है। आपको यह भी सुनिश्चित करना होगा कि टीम के सभी लोग सभी को अपडेट करने के लिए याद रखें लोग बदलाव फाइलों ।
वैसे, मैं एक्सटेंशन के रूप में अंत में ".config" रखना पसंद करता हूं ताकि फ़ाइल एसोसिएशन टूट न जाएं।
जहाँ तक कॉन्फ़िगर फ़ाइल के स्थानीय डेवलपर संस्करण हैं, मैं हमेशा लोगों को उसी स्थानीय सेटिंग्स का उपयोग करने के लिए प्रोत्साहित करने की पूरी कोशिश करता हूँ, ताकि आपका अपना संस्करण होने की कोई आवश्यकता न हो। यह हमेशा सभी के लिए काम नहीं करता है, जिस स्थिति में लोग आमतौर पर इसे स्थानीय रूप से आवश्यकतानुसार बदल देते हैं और वहां से चले जाते हैं। यह बहुत दर्दनाक या कुछ भी नहीं है।
हमारी परियोजना पर हमारे पास एक उपसर्ग के साथ फ़ाइलों में संग्रहीत कॉन्फ़िगरेशन है, फिर हमारी बिल्ड सिस्टम वर्तमान सिस्टम के होस्टनाम के आधार पर उपयुक्त कॉन्फ़िगरेशन में खींचती है। यह एक अपेक्षाकृत छोटी टीम पर हमारे लिए अच्छा काम करता है, अगर हम एक नया कॉन्फ़िगरेशन आइटम जोड़ते हैं तो हमें अन्य लोगों की फ़ाइलों में कॉन्फ़िगरेशन परिवर्तन लागू करने की अनुमति मिलती है। जाहिर है यह निश्चित रूप से डेवलपर्स की बिना संख्या वाली स्रोत परियोजनाओं को खोलने का पैमाना नहीं है।
हमारे यहां दो समस्याएं हैं।
सबसे पहले हमें कॉन्फ़िगरेशन फ़ाइल को नियंत्रित करना होगा जो सॉफ्टवेयर के साथ भेज दिया गया है।
किसी डेवलपर के लिए मास्टर कॉन्फ़िग फ़ाइल में परिवर्तन करने के लिए अवांछित को चेक करना सभी दो आसान है, यदि वे विचलन वातावरण में एक ही फ़ाइल का उपयोग कर रहे हैं।
दूसरी तरफ, यदि आपके पास एक अलग कॉन्फ़िगरेशन फ़ाइल है जिसे इंस्टॉलर द्वारा शामिल किया गया है, तो इसमें एक नई सेटिंग जोड़ना भूल जाना, या इसमें टिप्पणियों को विचलन में टिप्पणियों के साथ सिंक से बाहर निकलने देना बहुत आसान है फ़ाइल को कॉन्फ़िगर करना।
तब हमें समस्या होती है कि डेवलपर्स को कॉन्फ़िगरेशन फ़ाइल की प्रतिलिपि को अप-टू-डेट रखना पड़ता है क्योंकि अन्य डेवलपर्स नई कॉन्फ़िगरेशन सेटिंग्स जोड़ते हैं। हालाँकि डेटाबेस कनेक्शन स्ट्रिंग्स जैसी कुछ सेटिंग्स प्रत्येक डेवलपर के लिए अलग होती हैं।
एक 3 समस्या है प्रश्न / उत्तर कवर नहीं करते हैं। जब आप अपने सॉफ़्टवेयर का नया संस्करण स्थापित करते हैं, तो ग्राहक आपके कॉन्फ़िगरेशन फ़ाइल में किए गए परिवर्तनों में कैसे विलीन हो जाता है?
मुझे अभी तक एक अच्छा समाधान देखना है जो सभी मामलों में अच्छी तरह से काम करता है, हालांकि मैंने कुछ आंशिक समाधान (जिन्हें आवश्यकतानुसार अलग-अलग संयोजनों में जोड़ा जा सकता है) देखा है जो समस्या को बहुत कम करता है।
सबसे पहले आपके मुख्य कॉन्फ़िगरेशन फ़ाइल में आपके पास कॉन्फ़िगरेशन आइटम की संख्या कम करें।
यदि आपको अपने ग्राहकों को अपने मैपिंग को बदलने की आवश्यकता नहीं है, तो कोड पर कॉन्फ़िगरेशन को स्थानांतरित करने के लिए धाराप्रवाह NHibernate (या अन्यथा) का उपयोग करें।
इसी तरह चित्रण इंजेक्शन सेटअप के लिए।
जब संभव हो तो कॉन्फ़िगरेशन फ़ाइल को विभाजित करें, जैसे कि लॉग 4नेट लॉग को कॉन्फ़िगर करने के लिए एक अलग फ़ाइल का उपयोग करें।
बहुत सारी कॉन्फ़िगरेशन फ़ाइलों के बीच आइटम न दोहराएं, उदाहरण के लिए यदि आपके पास 4 वेब एप्लिकेशन हैं जो सभी एक ही मशीन पर स्थापित हैं, तो एक समग्र कॉन्फ़िगरेशन फ़ाइल है जो प्रत्येक एप्लिकेशन में web.config फ़ाइल को इंगित करती है।
(डिफ़ॉल्ट रूप से एक सापेक्ष पथ का उपयोग करें, इसलिए web.config फ़ाइल को बदलना दुर्लभ है)
शिपिंग कॉन्फ़िगरेशन फ़ाइल प्राप्त करने के लिए विकास कॉन्फ़िगरेशन फ़ाइल को संसाधित करें।
Xml टिप्पणियों में डिफ़ॉल्ट मान द्वारा किया जा सकता है जो तब बिल्ड फ़ाइल में सेट किए गए कॉन्फ़िगरेशन फ़ाइल में सेट होते हैं। या ऐसे सेक्शन जिन्हें इंस्टॉलर बनाने की प्रक्रिया के हिस्से के रूप में हटा दिया जाता है।
केवल एक डेटाबेस कनेक्शन स्ट्रिंग्स होने के बजाय, प्रति डेवलपर्स एक है।
उदाहरण के लिए, रन टाइम में "डेटाबेस_आईएनआर" (जहां ianr मेरा उपयोगकर्ता नाम या मशीन का नाम है) कॉन्फ़िगरेशन फ़ाइल में देखें, यदि यह नहीं मिला है, तो "डेटाबेस" देखें
एक द्वितीय स्तर "जैसे -oracle या -sqlserver" डेवलपर्स के लिए दोनों डेटाबेस सिस्टम में लाने के लिए इसे तेज बनाते हैं।
यह निश्चित रूप से किसी अन्य कॉन्फ़िगरेशन मान के लिए भी किया जा सकता है।
फिर "_userName" में समाप्त होने वाले सभी मानों को कॉन्फ़िगरेशन फ़ाइल को शिपिंग करने से पहले धारीदार किया जा सकता है।
हालाँकि अंत में आप एक "कॉन्फ़िगरेशन फ़ाइल के मालिक" हैं जो कॉन्फ़िगरेशन फ़ाइल (ओं) को ऊपर या अन्यथा प्रबंधित करने की जिम्मेदारी लेता है। वह / वह भी प्रत्येक शिपमेंट से पहले ग्राहक कामकाज विन्यास फाइल पर एक अंतर करना चाहिए।
आप एक देखभाल करने वाले व्यक्ति को इस समस्या की कुछ कमी की आवश्यकता को दूर नहीं कर सकते।
मुझे नहीं लगता कि एक भी समाधान है जो सभी मामलों के लिए काम करता है क्योंकि यह कॉन्फिग फाइलों में डेटा की संवेदनशीलता, या आपके द्वारा उपयोग की जा रही प्रोग्रामिंग भाषा और कई अन्य कारकों पर निर्भर हो सकता है। लेकिन मुझे लगता है कि स्रोत नियंत्रण के तहत सभी वातावरणों के लिए कॉन्फिग फाइल रखना महत्वपूर्ण है, इसलिए आप हमेशा जान सकते हैं कि इसे कब और किसके द्वारा बदला गया था, और इससे भी महत्वपूर्ण बात यह है कि अगर चीजें गलत हो जाती हैं, तो इसे पुनर्प्राप्त करने में सक्षम हों। और वे करेंगे।
तो यहाँ है कि मैं यह कैसे करते हैं। यह आमतौर पर नोडज परियोजनाओं के लिए है, लेकिन मुझे लगता है कि यह अन्य रूपरेखाओं और भाषाओं के लिए भी काम करता है।
मैं जो भी करता हूं configsवह परियोजना के मूल में एक निर्देशिका बनाता है , और उस निर्देशिका के तहत सभी वातावरणों के लिए कई फाइलें रखता है (और प्रत्येक डेवलपर के पर्यावरण के लिए कुछ समय के लिए अलग-अलग फाइलें) जो सभी स्रोत नियंत्रण में ट्रैक की जाती हैं। और वास्तविक फ़ाइल है जो कोड configप्रोजेक्ट के रूट पर नामित का उपयोग करता है । यह एकमात्र फ़ाइल है जिसे ट्रैक नहीं किया गया है। तो ऐसा दिखता है
root
|
|- config (not tracked)
|
|- configs/ (all tracked)
|- development
|- staging
|- live
|- James
जब कोई परियोजना की जाँच करता है तो वह उस असंबंधित configफ़ाइल में उपयोग की जाने वाली कॉन्फ़िगर फ़ाइल को कॉपी कर लेता है और वह अपनी इच्छानुसार इसे संपादित करने के लिए स्वतंत्र होता है, लेकिन आवश्यकतानुसार अन्य वातावरण फ़ाइलों में आने से पहले इन परिवर्तनों को कॉपी करने के लिए भी ज़िम्मेदार होता है।
और सर्वर पर, अनटैक की गई फ़ाइल बस उस वातावरण के अनुरूप ट्रैक की गई फ़ाइल की प्रतिलिपि (या संदर्भ) हो सकती है। जेएस में आपको उस फ़ाइल की आवश्यकता के लिए बस 1 पंक्ति हो सकती है।
यह प्रवाह पहली बार में थोड़ा जटिल हो सकता है, लेकिन इसके बहुत फायदे हैं: 1. आपको कभी भी बिना बैकअप के सर्वर पर डिलीट या संशोधित होने वाली कॉन्फिग फाइल के बारे में चिंता करने की जरूरत नहीं है। 2. यदि कोई डिवेलपर के पास कोई कस्टम कॉन्फिगर हो तो मशीन और उसकी मशीन किसी भी तैनाती से पहले किसी भी कारण से 3. के लिए कार्य करना बंद कर आप के लिए config फ़ाइलों diff कर सकते हैं developmentऔर stagingउदाहरण के लिए और कुछ भी याद आ रही है या टूट अगर देखते हैं।
मैंने उसी समस्या का सामना किया और मुझे इसके लिए एक समाधान मिला। मैंने पहली बार सभी फाइलों को केंद्रीय भंडार (डेवलपर वाले भी) में जोड़ा।
इसलिए अगर कोई डेवलपर रिपॉजिटरी से फाइल लेता है तो डेवलपर कॉन्फिगर भी होता है। इस फ़ाइल में किए गए परिवर्तन से, गिट को इन परिवर्तनों के बारे में पता नहीं होना चाहिए। इस तरह से परिवर्तनों को रिपॉजिटरी में धकेला / प्रतिबद्ध नहीं किया जा सकता है, लेकिन स्थानीय रूप से बने रहें।
मैंने इसे git कमांड का उपयोग करके हल किया है update-index --assume-unchanged:। मैंने एक बैट फाइल बनाई, जो उन परियोजनाओं के निर्माण में निष्पादित होती है, जिनमें एक फाइल होती है, जिसके परिवर्तन को गिट द्वारा अनदेखा किया जाना चाहिए। यहाँ मैं कोड को बैट फ़ाइल में रखा गया हूँ:
IF NOT EXIST %2%\.git GOTO NOGIT
set fileName=%1
set fileName=%fileName:\=/%
for /f "useback tokens=*" %%a in ('%fileName%') do set fileName=%%~a
set "gitUpdate=git update-index --assume-unchanged"
set parameter= "%gitUpdate% %fileName%"
echo %parameter% as parameter for git
"C:\Program Files (x86)\Git\bin\sh.exe" --login -i -c %parameter%
echo Make FIleBehaveLikeUnchangedForGit Done.
GOTO END
:NOGIT
echo no git here.
echo %2%
:END
उदाहरण के लिए, मैंने अपने प्रस्ताव में बैट फाइल को कॉल किया:
call "$(ProjectDir)\..\..\MakeFileBehaveLikeUnchangedForGit.bat" "$(ProjectDir)Web.config.developer" "$(SolutionDir)"
मुझे SO पर एक बैट फाइल मिली, जो सही कॉन्फिग फाइल को web.config / app.config में कॉपी करती है। मैं इस बैट फाइल को प्रीलिफ्ट में भी कहता हूं। इस बल्ले फ़ाइल के लिए कोड है:
@echo off
echo Comparing two files: %1 with %2
if not exist %1 goto File1NotFound
if not exist %2 goto File2NotFound
fc %1 %2
if %ERRORLEVEL%==0 GOTO NoCopy
echo Files are not the same. Copying %1 over %2
copy %1 %2 /y & goto END
:NoCopy
echo Files are the same. Did nothing
goto END
:File1NotFound
echo %1 not found.
goto END
:File2NotFound
copy %1 %2 /y
goto END
:END
echo Done.
उदाहरण के लिए, मैंने अपने प्रस्ताव में बैट फाइल को कॉल किया:
call "$(ProjectDir)\..\..\copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config