गिट: एप्लिकेशन कॉन्फ़िगरेशन और विभिन्न वातावरण

Question

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

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

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

क्या गिट का उपयोग करके इसे पूरा करने का कोई तरीका है?

आपके विचार के लिए धन्यवाद!

Answer 1

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

उदाहरण के लिए, आपके पास "config.staging" और "config.production" गिट में चेक किया गया हो सकता है, और जब आप स्टेजिंग पर तैनात होते हैं, तो इंस्टॉल टूल "config.staging" को "config" पर कॉपी करने के लिए चुनता है। या आपके पास एक "config.template" फ़ाइल हो सकती है, जिसे तैनाती में "कॉन्फ़िगर" बनाने के लिए टेम्पलेट किया जाएगा।

Answer 2

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

Answer 3

आप पोस्ट-मर्ज या पोस्ट-चेकआउट हुक का उपयोग करके यह सत्यापित करने के लिए प्रयास कर सकते हैं कि यह सब कुछ होना चाहिए, और इसे अन्यथा ठीक करें। यह वास्तव में seems to be suggested by the ProGit book है।

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