संस्करण नियंत्रण और व्यक्तिगत कॉन्फ़िगरेशन फ़ाइल

Question

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

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

हालाँकि, यह अभी भी एक तदर्थ समाधान की तरह लगता है।

क्या आप एक बेहतर समाधान का प्रस्ताव कर सकते हैं?

पेशेवर क्या करते हैं?

Comments

देखें stackoverflow.com/questions/6009/…

— jk।

बोगल ... पृथ्वी पर आप डेवलपर्स को मॉड्यूल को फिर से चालू करने और प्रमुख उन्नयन के अलावा किसी भी बिंदु पर ग्राहक कॉन्फ़िगरेशन को तोड़ने की अनुमति क्यों दे रहे हैं ?

— मार्क बूथ

@jk हाँ, एक बेहतर मैच भी है: stackoverflow.com/questions/1974886/…

— Erel Segal-Halevi

मैं चकरा गया हूं। जब आप नवीनीकरण स्थापित करते हैं, तो यह कोई समस्या नहीं है।

— जोशुआ

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

— विलियम पायने

Answer 1

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

मैं यहां दो संभावित समाधानों के बारे में सोच सकता हूं:

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

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

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

Answer 2

यह एक उचित समाधान है।

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

फिर जब प्रत्येक उपयोगकर्ता अपना व्यक्तिगत कॉन्फ़िगरेशन बदलता है तो आप इन परिवर्तनों को अपनी स्थानीय प्रतिलिपि में लिखते हैं।

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

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

Answer 3

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

$db_user = "${test.db_user}";

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

Answer 4

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

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

Comments

+1 उल्लेख करने के लिए कि यह केवल डेवलपर्स के लिए समस्या नहीं है, बल्कि एक सामान्य तैनाती समस्या है।

— सलेस्के

Answer 5

व्यक्तिगत कॉन्फ़िगरेशन फ़ाइल (कॉन्फ़िगरेशन फ़ाइल स्वरूप का संस्करण संख्या) में एक संस्करण संख्या डालें।

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

आप शायद अंत उपयोगकर्ताओं के लिए कुछ इस तरह की प्रक्रिया चाहते हैं, इसलिए आप इसे अपने डेवलपर्स के जीवन को आसान बनाने के लिए उपयोग कर सकते हैं।

Answer 6

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

यह सुनिश्चित करने के लिए ध्यान रखता है कि मर्ज सही किया गया है, लेकिन यह मेरे लिए बहुत सुरक्षित लगता है।

Comments

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

— sleske

@ स्लेसके इसके लिए एक निश्चित मात्रा में अनुशासन की आवश्यकता होती है। लेकिन ईमानदारी से, मैं सबसे डेवलपर्स से यह ठीक करने की क्षमता की उम्मीद करूंगा।

— थॉमस ओवेन्स

Answer 7

हम यहां क्या करते हैं सेटिंग्स के ब्लॉक बनाते हैं। यह Zend में इस तरह किया जा सकता है:

[production]
key1: parameter1
key2: parameter2

[testing: production]
key1: parameter2
key3: parameter4

इसका मतलब है कि परीक्षण उत्पादन को विरासत में देता है और इसे की 3 के साथ विस्तारित करता है। फिर प्रत्येक डेवलपर को अपना पर्यावरण (इस मामले में परीक्षण या उत्पादन) निर्धारित करना होगा

Comments

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

— इरेल सहगल-हलेवी

कितनी सेटिंग्स और कैसे उनका उपयोग किया जाता है इसके आधार पर आप Zend के लिए ini फ़ाइल में संसाधनों का उपयोग कर सकते हैं। यकीन नहीं होता कि यह आपकी समस्या के लिए भी लागू है।

— Agilix

मुझे एक और सामान्य समाधान की आवश्यकता थी, जो सभी प्रकार की उपयोगकर्ता-विशिष्ट प्राथमिकताओं को संभाल सके, न कि केवल संसाधनों को।

— एरेल सहगल-हलेवी

बस यहाँ एक विचार है, लेकिन यह एक डेटाबेस में संग्रहीत करने के लिए बेहतर नहीं होगा? कम से कम प्राथमिकताएँ। और फिर आप उन लोगों को एक उपयोगकर्ता जोड़ सकते हैं। यदि नहीं, तो यह सिर्फ एक विचार था;)

— Agilix

Answer 8

यह पोस्ट पर आधारित एक उपयोगी समाधान है: पासवर्ड को स्रोत नियंत्रण में रखना

सारांश में रणनीति यह है कि "कॉन्फ़िगरेशन फ़ाइल के एन्क्रिप्टेड संस्करण को स्रोत नियंत्रण में रखें और फिर एक ऐसा साधन प्रदान करें जिसके माध्यम से उपयोगकर्ता उस डेटा को एन्क्रिप्ट और डिक्रिप्ट कर सके।"

1. एक डमी comfig फ़ाइल बनाएं और इसे .ignignore।
2. एक मेकफाइल बनाएं जो कॉन्फिग फाइल को एन्क्रिप्ट और डिक्रिप्ट कर सकता है
3. भंडार और एन्क्रिप्टेड कॉन्फ़िगर फ़ाइल को भंडार में संग्रहित करें
4. मेकफाइल पासवर्ड के लिए पूछता है, और पासवर्ड के लिए लेखक से कैसे संपर्क करें।
5. प्रोजेक्ट का निर्माण करते समय, यदि मेकफाइल नहीं चला है, तो कंसोल के साथ उपयोगकर्ता को सलाह दें। "(फ़ाइल को कॉन्फ़िगर करें [conf / settings.json] गायब है! क्या आप चलाना भूल गए हैं? make decrypt_conf ?");
6. यह सुनिश्चित करने के लिए एक चेक का वर्णन किया गया है कि कॉन्फ़िगरेशन फ़ाइल अद्यतित है।

Comments

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

— डेरेक

हालांकि यह एक दिलचस्प पोस्ट है।

— एलिग सेगल-हलेवी

Answer 9

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

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

Comments

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

— Mael

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

— बिएनवेनिडो डेविड