आप स्रोत नियंत्रण में कॉन्फ़िगरेशन फ़ाइलों से कैसे निपटते हैं?

फ़ाइल जो संस्करण नहीं है। एक टेम्पलेट या कुछ संस्करण।

मैं संस्करण इसे नियंत्रित करता हूं, लेकिन इसे अन्य सर्वरों पर कभी भी धक्का नहीं देता हूं। अगर उत्पादन सर्वर को एक बदलाव की आवश्यकता है, तो मैं उस परिवर्तन को सीधे कॉन्फ़िगरेशन फ़ाइल में बदलता हूं।

यह सुंदर नहीं हो सकता है, लेकिन यह ठीक काम करता है।

वर्तमान में मेरे पास "टेम्पलेट" कॉन्फ़िगरेशन फ़ाइल है जो एक अतिरिक्त एक्सटेंशन के साथ है उदाहरण के लिए:

web.config.rename

हालांकि, यदि महत्वपूर्ण परिवर्तन बदल गए हैं, तो मैं इस विधि के साथ कोई समस्या देख सकता हूं।

मेरी टीम प्रत्येक वातावरण (web.config.dev, web.config.test, web.config.prod) के लिए कॉन्फ़िगरेशन फ़ाइलों के अलग-अलग संस्करण रखती है। हमारी तैनाती स्क्रिप्ट सही संस्करण की प्रतिलिपि बनाते हैं, इसे web.config पर नामित करते हैं। इस तरह, हमारे पास प्रत्येक वातावरण के लिए कॉन्फ़िगरेशन फ़ाइलों पर पूर्ण संस्करण नियंत्रण है, आसानी से एक diff प्रदर्शन कर सकते हैं।

ऐप / web.config का चेक-इन, सादा-वेनिला संस्करण सभी डेवलपर मशीनों पर काम करने के लिए सामान्य होना चाहिए, और किसी भी नए सेटिंग में इत्यादि के साथ अद्यतित रहना चाहिए, आदि। यदि आपको देव के लिए सेटिंग्स का एक विशिष्ट सेट चाहिए / परीक्षण / उत्पादन सेटिंग्स, उन सेटिंग्स के साथ अलग-अलग फ़ाइलों में जांचें, क्योंकि गेटकिल्लर ने कुछ प्रकार के नामकरण सम्मेलन के साथ कहा है, हालांकि मैं आमतौर पर "web.prod.config" के साथ जाता हूं, क्योंकि फ़ाइल एक्सटेंशन को नहीं बदला जाता है।

मैंने अतीत में जो किया है वह एक डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल है जिसे स्रोत नियंत्रण में चेक किया गया है। फिर, प्रत्येक डेवलपर की अपनी ओवरराइड कॉन्फ़िगरेशन फ़ाइल होती है जिसे स्रोत नियंत्रण से बाहर रखा जाता है। ऐप पहले डिफ़ॉल्ट लोड करता है, और फिर यदि ओवरराइड फ़ाइल मौजूद है, तो वह लोड करता है और ओवरराइड से ओवरराइड से किसी भी सेटिंग्स को डिफ़ॉल्ट फ़ाइल में उपयोग करता है।

आम तौर पर, ओवरराइड फ़ाइल जितनी छोटी होती है, लेकिन इसमें हमेशा एक गैर-मानक वातावरण वाले डेवलपर के लिए अधिक सेटिंग्स हो सकती हैं।

हमें यहां दो समस्याएं हैं।

• Firstly we have to control the configuration file that is shipped with the software.

  It is all two easy for a developer to check in an unwanted to change to the master config file, if they are using the same file in the devolvement environment.

  On the other side, if you have a separate configuration file that is included by the installer, it is very easy to forget to add a new setting to it, or to let the comments in it get out of sync with the comments in the devolvement configuring file.

• Then we have the problem that developers have to keep there copy of the configuration file up-to-date as other developers add new configuration settings. However some settings like database connection strings are different for each developer.

• There is a 3rd problem the question/answers do not cover. How do you merge in the changes a customer have make to your configuration file when you install a new version of your software?

मुझे अभी तक एक अच्छा समाधान देखना है   हालांकि, सभी मामलों में अच्छी तरह से काम करता है   मैंने कुछ आंशिक समाधान देखा है   (जिसे अलग-अलग जोड़ा जा सकता है   आवश्यकतानुसार संयोजन) जो कम हो जाता है   समस्या बहुत है।

• Firstly reduce the number of configuration items you have in your main configuration file.

  If you don?t have a need to let your customers change your mappings, use Fluent NHibernate (or otherwise) to move the configuration into code.

  Likewise for depency injection setup.

• Split up the configuration file when possible, e.g. use a separate file to configure what Log4Net logs.

• Don?t repeat items between lots of configuration files, e.g. if you have 4 web applications that are all installed on the same machine, have a overall configuration file that the web.config file in each application points to.

  (Use a relative path by default, so it is rare to have to change the web.config file)

• Process the development configuration file to get the shipping configuration file.

  The could be done by have default values in the xml comments that are then set in the configuration file when a build is done. Or having sections that are deleted as part of the process of creating the installer.

• Instead of just having one database connection strings, have one per developers.

  E.g first look for ?database_ianr? (where ianr is my username or machine name) in the configuration file at run time, if it is not found, then look for ?database?

  Have a 2nd level "e.g. -oracle or -sqlserver" make it quicker for developers to get to both database systems.

  This can of course also be done for any other configuration value.

  Then all values that end in ?_userName? can be striped out before shipping the configuration file.

हालांकि अंत में आप क्या हैं   विन्यास फाइल के मालिक? उस   प्रबंधन के जिम्मेदारी लेता है   ऊपर या के रूप में विन्यास फाइल (ओं)   अन्यथा। उसे भी करना चाहिए   ग्राहक facings पर diff   प्रत्येक से पहले विन्यास फाइल   लदान।

आप किसी देखभाल करने वाले व्यक्ति की कुछ समस्या को कम नहीं कर सकते हैं।

कॉन्फ़िगरेशन है कोड, और आपको इसे संस्करण करना चाहिए। हम उपयोगकर्ता नाम पर हमारी विन्यास फाइलों का आधार बनाते हैं; यूनिक्स / मैक और विंडोज दोनों में आप उपयोगकर्ता के लॉगिन नाम तक पहुंच सकते हैं, और जब तक ये परियोजना के लिए अद्वितीय हैं, तो आप ठीक हैं। आप पर्यावरण में इसे ओवरराइड भी कर सकते हैं, लेकिन आप चाहिए संस्करण सब कुछ नियंत्रित कर सकते हैं।

यह आपको दूसरों की कॉन्फ़िगरेशन की जांच करने की अनुमति देता है, जो बिल्ड और प्लेटफ़ॉर्म समस्याओं का निदान करने में सहायता कर सकता है।

लंबे समय तक, मैंने बिल्कुल किया है कि बीसीवुड ने क्या किया है। मैं web.dev.config, web.test.config, web.prod.config, आदि की प्रतियों को स्रोत नियंत्रण के तहत रखता हूं, और फिर मेरा निर्माण / तैनाती प्रणाली स्वचालित रूप से उनका नाम बदलती है क्योंकि यह विभिन्न वातावरणों पर तैनात होती है। आपको फ़ाइलों के बीच कुछ निश्चित अनावश्यकता मिलती है (विशेष रूप से वहां की सभी एएसपीनेट सामग्री के साथ), लेकिन आम तौर पर यह वास्तव में अच्छी तरह से काम करता है। आपको यह भी सुनिश्चित करना होगा कि टीम के हर कोई फाइल बदलते समय सभी फ़ाइलों को अपडेट करने के लिए याद रखें।

वैसे, मैं विस्तार के रूप में अंत में ".config" रखना चाहता हूं ताकि फाइल एसोसिएशन टूटा न जाए।

कॉन्फ़िगरेशन फ़ाइल के स्थानीय डेवलपर संस्करणों तक, मैं हमेशा लोगों को उसी स्थानीय सेटिंग्स का उपयोग करने के लिए प्रोत्साहित करने के लिए अपना सर्वश्रेष्ठ प्रयास करता हूं ताकि आपके स्वयं के संस्करण की आवश्यकता न हो। यह हमेशा हर किसी के लिए काम नहीं करता है, इस मामले में लोग आमतौर पर इसे स्थानीय रूप से आवश्यक रूप से प्रतिस्थापित करते हैं और वहां से जाते हैं। यह बहुत दर्दनाक या कुछ भी नहीं है।

हम केवल उत्पादन कॉन्फ़िगरेशन फ़ाइल को चेक इन करते हैं। यह डेवलपर की ज़िम्मेदारी है जब वे इसे स्टेजिंग या डेवलपमेंट के लिए स्रोत से बाहर खींचते समय फ़ाइल को बदल दें। इसने हमें अतीत में जला दिया है इसलिए मैं इसका सुझाव नहीं दूंगा।

हम एक टेम्पलेट कॉन्फ़िगरेशन फ़ाइल का उपयोग करते हैं जिसे संस्करण नियंत्रण में चेक किया गया है और उसके बाद टेम्पलेट फ़ाइल में विशिष्ट प्रविष्टियों को पर्यावरण-विशिष्ट सेटिंग्स के साथ बदलने के लिए हमारे स्वचालित निर्माण में एक चरण है। पर्यावरण-विशिष्ट सेटिंग्स एक अलग xml फ़ाइल में संग्रहीत हैं जो संस्करण नियंत्रण के अंतर्गत भी है।

हम अपने स्वचालित निर्माण में एमएसबिल्ड का उपयोग कर रहे हैं, इसलिए हम XmlUpdate कार्य का उपयोग MSBuild Community Tasks से अपडेट करने के लिए करते हैं। मान।

@ ग्रांट सही है।

मैं 100 अन्य डेवलपर्स के साथ एक टीम में हूं, और हमारी कॉन्फ़िगरेशन फ़ाइलों को स्रोत नियंत्रण में चेक नहीं किया गया है। हमारे पास रिपॉजिटरी में फ़ाइलों के संस्करण हैं जिन्हें प्रत्येक चेक आउट के साथ खींचा जाता है लेकिन वे नहीं बदलते हैं।

यह हमारे लिए बहुत अच्छी तरह से काम किया है।

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

तो यहां मैं यह कैसे करता हूं। यह आमतौर पर नोडज परियोजनाओं के लिए है, लेकिन मुझे लगता है कि यह अन्य ढांचे और भाषाओं के लिए भी काम करता है।

मैं जो करता हूं वह प्रोजेक्ट की जड़ पर configs निर्देशिका बनाता है, और उस निर्देशिका के तहत सभी वातावरणों के लिए कई फाइलें रखती हैं (और प्रत्येक डेवलपर के पर्यावरण के लिए कुछ बार अलग-अलग फाइलें भी) जो सभी ट्रैक की जाती हैं स्रोत नियंत्रण। और प्रोजेक्ट की जड़ पर कोड config नामक वास्तविक फ़ाइल है। यह एकमात्र फ़ाइल है जिसे ट्रैक नहीं किया जाता है। तो ऐसा लगता है

root
|
|- config (not tracked)
|
|- configs/ (all tracked)
    |- development
    |- staging
    |- live
    |- James

जब कोई प्रोजेक्ट जांचता है तो वह कॉन्फ़िगरेशन फ़ाइल की प्रतिलिपि बनाता है, वह अनचाहे config फ़ाइल में उपयोग करना चाहता है और वह इसे संपादित करने के लिए स्वतंत्र है क्योंकि वह चाहता है लेकिन वह इन बदलावों को कॉपी करने से पहले भी जिम्मेदार है आवश्यकतानुसार अन्य पर्यावरण फाइलें।

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

यह प्रवाह पहले थोड़ा जटिल हो सकता है लेकिन इसमें बहुत अच्छे फायदे हैं: 1. आपको बैकअप के बिना सर्वर पर हटाए गए या संशोधित कॉन्फ़िगरेशन फ़ाइल के बारे में चिंता करने की ज़रूरत नहीं है 2. वही अगर किसी डेवलपर की मशीन पर कुछ कस्टम कॉन्फ़िगरेशन है और उसकी मशीन किसी भी कारण से काम करना बंद कर देती है 3. किसी भी परिनियोजन से पहले आप विकास और staging के लिए कॉन्फ़िगरेशन फ़ाइलों को भिन्न कर सकते हैं उदाहरण के लिए और देखें कि क्या कुछ गुम या टूटा हुआ है या नहीं।

टेम्पलेट दृष्टिकोण पर +1।

लेकिन चूंकि इस प्रश्न में टैग गिट, वितरित विकल्प है स्प्रिंग्स को ध्यान में रखना, जिसमें निजीकरण पर अनुकूलन रखा जाता है डाली:

A---B---C---D---           <- mainline (public)
     \       \
      B'------D'---        <- testing (private)

इस योजना में, मुख्य रेखा में एक सामान्य, "टेम्पलेट" कॉन्फ़िगरेशन होता है फ़ाइल को कार्यात्मक होने के लिए समायोजन की न्यूनतम मात्रा की आवश्यकता होती है।

अब, डेवलपर / परीक्षक कॉन्फ़िगरेशन फ़ाइल को उनके दिल में बदल सकते हैं सामग्री, और केवल इन परिवर्तनों को स्थानीय रूप से एक निजी पर प्रतिबद्ध करें परीक्षण शाखा (उदा। बी '= बी + अनुकूलन)। प्रत्येक बार मुख्य लाइन अग्रिम, वे आसानी से परीक्षण में विलय करते हैं, जिसके परिणामस्वरूप डी '(= डी + अनुकूलन के डी + विलय संस्करण) जैसे कार्यों को मर्ज करें।

यह योजना वास्तव में चमकती है जब "टेम्पलेट" कॉन्फ़िगरेशन फ़ाइल अद्यतन होती है: दोनों पक्षों के परिवर्तन विलय हो जाते हैं, और इसकी अत्यधिक संभावना होती है अगर वे असंगत हैं तो संघर्ष (या परीक्षण विफलताओं) में परिणाम!

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

मैंने पहले टेम्पलेट का उपयोग किया है, यानी web.dev.config, web.prod.config, आदि, लेकिन अब 'ओवरराइड फ़ाइल' तकनीक पसंद करते हैं। Web.config फ़ाइल में अधिकांश सेटिंग्स शामिल हैं, लेकिन बाहरी फ़ाइल में पर्यावरण-विशिष्ट मान जैसे डीबी कनेक्शन शामिल हैं। पॉल विल्सन का ब्लॉग पर अच्छी व्याख्या।

मुझे लगता है कि यह कॉन्फ़िगरेशन फ़ाइलों के बीच डुप्लीकेट की मात्रा को कम करता है जो नए मान / विशेषताओं को जोड़ते समय दर्द का कारण बन सकता है।

हमारे द्वारा उपयोग किया जाने वाला समाधान केवल एक ही कॉन्फ़िगरेशन फ़ाइल (web.config / app.config) होना है, लेकिन हम उस फ़ाइल में एक विशेष अनुभाग जोड़ते हैं जिसमें सभी वातावरण के लिए सेटिंग्स शामिल हैं।

हमारे LOCAL, DEV, QA, PRODUCTION अनुभाग हैं जिनमें प्रत्येक कॉन्फ़िगरेशन कुंजी को हमारे कॉन्फ़िगरेशन फ़ाइल में उस वातावरण से प्रासंगिक है।

यह सब काम xxx.Environment नामक एक असेंबली है जिसे हमारे सभी अनुप्रयोगों (विनफॉर्म और वेबफॉर्म) में संदर्भित किया जाता है जो एप्लिकेशन को बताता है कि यह किस माहौल पर चल रहा है।

Xxx.Environment असेंबली दी गई मशीन के machine.config से जानकारी की एक पंक्ति को पढ़ती है जो बताती है कि यह DEV, QA, आदि पर है। यह प्रविष्टि हमारे सभी वर्कस्टेशन पर मौजूद है और सर्वर।

उम्मीद है की यह मदद करेगा।

मैंने हमेशा web.config फ़ाइल के समान फ़ोल्डर में कॉन्फ़िगरेशन फ़ाइलों के सभी संस्करणों को स्रोत नियंत्रण में रखा है।

उदाहरण के लिए

web.config
web.qa.config
web.staging.config
web.production.config

मैं इस नामकरण सम्मेलन को पसंद करता हूं (जैसा कि web.config.production या production.web.config के विपरीत) है

• जब आप फ़ाइल नाम से सॉर्ट करते हैं तो यह फ़ाइलों को एकसाथ रखता है
• जब आप फ़ाइल एक्सटेंशन द्वारा सॉर्ट करते हैं तो यह फ़ाइलों को एकसाथ रखता है
• अगर फाइल को गलती से उत्पादन में धकेल दिया जाता है, तो आप http पर सामग्री को देखने में सक्षम नहीं होंगे क्योंकि आईआईएस * .config फ़ाइलों को सेवारत होने से रोक देगा

डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल को कॉन्फ़िगर किया जाना चाहिए ताकि आप स्थानीय रूप से अपनी मशीन पर एप्लिकेशन चला सकें।

सबसे महत्वपूर्ण बात यह है कि इन फ़ाइलों को हर पहलू में लगभग 100% समान होना चाहिए, यहां तक ​​कि स्वरूपण भी। आपको एक संस्करण में टैब का उपयोग नहीं करना चाहिए और इंडेंटिंग के लिए किसी अन्य स्थान पर स्पेस का उपयोग नहीं करना चाहिए। आप फ़ाइलों के खिलाफ एक diff उपकरण चलाने में सक्षम होना चाहिए ताकि यह देखने के लिए कि उनके बीच क्या अंतर है। मैं फ़ाइलों को diffing के लिए WinMerge का उपयोग करना पसंद करते हैं।

जब आपकी बिल्ड प्रक्रिया बाइनरी बनाती है, तो ऐसा कार्य होना चाहिए जो web.config को उस वातावरण के लिए उपयुक्त कॉन्फ़िगरेशन फ़ाइल के साथ ओवरराइट करता हो। अगर फ़ाइलों को ज़िपित किया गया है, तो उस निर्माण से गैर प्रासंगिक फाइलों को हटा दिया जाना चाहिए।

मुझे एक ही समस्या का सामना करना पड़ा और मुझे इसके लिए एक समाधान मिला। मैंने पहली बार सभी फाइलों को केंद्रीय भंडार (डेवलपर भी) में जोड़ा।

तो यदि कोई डेवलपर रिपोजिटरी से फ़ाइलों को प्राप्त करता है तो डेवलपर कॉन्फ़िगरेशन भी होता है। इस फ़ाइल में बदलते समय, गिट को इन परिवर्तनों से अवगत नहीं होना चाहिए। इस तरह के परिवर्तन को भंडार में धक्का / प्रतिबद्ध नहीं किया जा सकता है लेकिन स्थानीय रूप से रहना चाहिए।

मैंने गिट कमांड का उपयोग करके इसे हल किया: 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