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

Question

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

database_password=secret 
foo=bar 

database_password=* 
foo=bar 

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

उदाहरण:

स्थानीय संस्करण: VCS में

database_password=own_secret 
foo=bar 

कॉन्फ़िग फ़ाइल:

database_password=* 
foo=bar 

फिर अचानक, कॉन्फ़िग फ़ाइल परिवर्तन:

database_password=* 
foo=bar 
baz=foo 

और स्थानीय संस्करण डब्ल्यू प्रत्येक डेवलपर के लिए बन जाएगा:

database_password=own_secret 
foo=bar 
baz=foo 

यह मेरा समाधान है। मैं इस व्यवहार को कैसे प्राप्त कर सकता हूं? आप अपनी कॉन्फ़िगरेशन फ़ाइलों को कैसे स्टोर करते हैं? क्या ऐसा करने का कोई तरीका है, या मुझे कुछ हैक करना चाहिए?

Answer 1

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

इसी प्रकार के प्रश्न के लिए see my answer भी।

Answer 2

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

मुझे इसके बजाए ऐसा करने का कोई तरीका नहीं दिख रहा है। यदि आपको एक अलग दृष्टिकोण मिलता है तो कृपया साझा करें।

Answer 3

में केवल रहस्यों के साथ एक अलग फ़ाइल है, जो संस्करण नियंत्रण में नहीं है?

या आदर्श रूप से, पासवर्ड पूरी तरह से openssh, या इसी तरह का उपयोग करते हैं, और प्रत्येक उपयोगकर्ता के लिए सार्वजनिक/निजी कुंजी प्रमाणीकरण करते हैं।

Answer 4

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

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

Answer 5

सुनिश्चित नहीं है कि आपकी कॉन्फ़िगरेशन कैसे कार्यान्वित की गई है, लेकिन पदानुक्रमित ओवरइड होने के कारण मैं इसे कैसे संभालेगा।

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

मैंने इसे .NET में किया है लेकिन PHP नहीं है इसलिए मुझे नहीं पता कि यह कितना आसान होगा मुझे डर है।

Answer 6

संवेदनशील क्षेत्रों को खाली करने के लिए पूर्व-प्रतिबद्ध हुक के बारे में क्या? यह मानता है कि आप निश्चित रूप से नेटवर्क पर फ़ाइल को पहले स्थान पर भेज रहे हैं। समस्या के दूसरे छोर के लिए

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

Answer 7

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

Answer 8

स्थानीय ओवरराइड फ़ाइल बनाएं जिसमें उपयोगकर्ता चर जानकारी PHP चर के रूप में होती है।

$local_password = 'qUzaEAFK13uK2KHy'; 

फिर फ़ाइल है कि आपके डीबी पासवर्ड शामिल में

इस

$overrides = 'local_overrides.php'; 

if (file_exists($overrides)) { 
    #include_once($overrides); 
    $db_password = $local_password; 
} else { 
    // perform appropriate action: set default? echo error message? log error?  
    $db_password = 'l1m1t3d!' 
} 

स्थानीय ओवरराइड फ़ाइल की तरह कुछ करना होगा:

उदाहरण के लिए जो निम्नलिखित शामिल हैं एक फ़ाइल local_overrides.php बनाएं जिसका नाम स्रोत नियंत्रण से कभी नहीं देखा जाना चाहिए।

Answer 9

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

मैं पहले से ही एक पूरा उदाहरण के साथ एक समान प्रश्न का उत्तर दिया, कैसे दृश्य स्टूडियो में ऐसा करने के लिए:
how to ignore files in kiln/mercurial using tortoise hg "that are part of the repository"