ब्रांचिंग: रिलीज/विकास

Question

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

अब, यह एक समस्या पैदा करता है, क्योंकि मैं नहीं कर सकता, उदाहरण के लिए एक स्कीमा कॉपी करें ताकि एक डेवलपर मुख्य विकास सर्वर के समान डेटाबेस उदाहरण का उपयोग करके एक प्रयोग चला सके। मुझे मूल रूप से किसी अन्य होस्ट पर एक नया डेटाबेस उदाहरण बनाना है, और उस नए सर्वर को इंगित करने के लिए/etc/hosts को बदलना है।

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

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

विभिन्न शाखाओं के लिए फ़ाइल के विभिन्न "संस्करणों" से निपटने का उचित तरीका क्या है? क्या कोई ऐसी शाखा है जो मास्टर पर नवीनतम कोड के साथ सिंक हो रही है, लेकिन कुछ कॉन्फ़िगर/कोड फ़ाइलों के साथ बदल गया है? मुझे यह स्वचालित रूप से सिंक में रहने की उम्मीद नहीं है, लेकिन मैं कॉन्फ़िगरेशन फ़ाइलों (या उनमें से कुछ हिस्सों) को मर्ज नहीं कर पा रहा हूं, जबकि उन्हें पूरी तरह से अनदेखा नहीं कर रहा हूं (?)। उदाहरण के लिए: लाइन 6,7 (डीबी उपयोगकर्ता नाम और पासवर्ड) मर्ज न करें, लेकिन फ़ाइलों में अन्य परिवर्तनों को मर्ज करें।

Answer 1

ऐसा लगता है जैसे आपको गिट विशेषताओं पर पढ़ना चाहिए। Check out the section at the bottom of this page

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

Answer 2

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

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

यह भी यह संभव प्रत्येक सर्वर