एनवायरनमेंट वेरिएबल कॉन्फ़िगरेशन

विषय-सूची:

• सारांश
  • मुद्दा
  • निर्णय
  • अवस्था
• विवरण
  • मान्यताएँ
  • बाधाएँ
  • रुख
  • तर्क
  • निहितार्थ
• संबंधित
  • संबंधित निर्णय
  • संबंधित आवश्यकताएँ
  • संबंधित कलाकृतियाँ
  • संबंधित सिद्धांत
• टिप्पणियाँ

सारांश

मुद्दा

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

• इसके लिए, हम एनवायरनमेंट वेरिएबल कॉन्फ़िगरेशन का उपयोग करना चाहते हैं।

• हम कॉन्फ़िगरेशन को उन फ़ाइलों से प्रबंधित करना चाहते हैं जिन्हें हम संस्करण नियंत्रण में रख सकें।

• हम डेवलपर अनुभव में कुछ सुविधा देना चाहते हैं, जैसे यह जानना कि क्या कॉन्फ़िगर किया जा सकता है और कौन-से प्रासंगिक डिफ़ॉल्ट हैं।

निर्णय

संबंधित डिफ़ॉल्ट फ़ाइल और स्कीमा फ़ाइल के साथ .env फ़ाइलों को चुनने का निर्णय लिया।

अवस्था

तय। नई क्षमताएँ सामने आने पर उन पर विचार करने के लिए खुले हैं।

विवरण

मान्यताएँ

हम एप्लिकेशन कोड और परिवेश कोड को अलग रखना पसंद करते हैं। हम मानते हैं कि ऐप को अलग-अलग परिवेशों में, जैसे विकास परिवेश, परीक्षण परिवेश, डेमो परिवेश, उत्पादन परिवेश आदि में, अलग तरह से काम करना होगा।

हम "12 factor app" के उद्योग-अभ्यास को, और उससे भी अधिक संबंधित "15 factor app" अभ्यास को पसंद करते हैं।

हमारी कई पिछली परियोजनाओं ने .env फ़ाइल या समान .env डायरेक्टरी की परिपाटी अपनाई है। इन्हें संस्करण नियंत्रण से बाहर रखना और इसके बजाय इन्हें तैनात करने, इनके संस्करण बनाने और इन्हें प्रबंधित करने का कोई और तरीका अपनाना एक सामान्य प्रथा है।

बाधाएँ

हम गोपनीय जानकारी को अपने स्रोत कोड प्रबंधन (SCM) संस्करण नियंत्रण प्रणाली (VCS) से बाहर रखना चाहते हैं।

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

रुख

हमने कुछ दृष्टिकोणों पर विचार किया:

• कॉन्फ़िगरेशन को ऐप में संग्रहीत करना, जैसे config.js फ़ाइल में।

• कॉन्फ़िगरेशन को परिवेश में संग्रहीत करना, जैसे .env फ़ाइल में।

• कॉन्फ़िगरेशन को किसी ज्ञात स्थान से लाना, जैसे लाइसेंस सर्वर से।

तर्क

हमने .env फ़ाइल वाला दृष्टिकोण इसलिए चुना क्योंकि:

• यह लोकप्रिय है, विशेषज्ञों के बीच भी।

• यह .env फ़ाइलों के उस पैटर्न का पालन करता है जिसे हमारी टीमों ने कई परियोजनाओं में कई बार सफलतापूर्वक उपयोग किया है।

• यह सरल है। विशेष रूप से, लाइसेंस सर्वर वाले दृष्टिकोण की तुलना में ऑडिट क्षमताओं की कमी जैसे जिन महत्वपूर्ण समझौतों को हम देखते हैं, उनके साथ हम फ़िलहाल सहज हैं।

निहितार्थ

हमें सार्वजनिक एनवायरनमेंट वेरिएबल कॉन्फ़िगरेशन को किसी भी गोपनीय जानकारी के प्रबंधन से अलग करने का तरीका निकालना होगा।

संबंधित

संबंधित निर्णय

हम अपेक्षा करते हैं कि हमारे सभी एप्लिकेशन इस दृष्टिकोण का उपयोग करें।

हम अपने उन सभी एप्लिकेशन को उन्नत करने की योजना बनाएँगे जो कम सक्षम दृष्टिकोण का उपयोग करते हैं, जैसे बाइनरी या स्रोत कोड में हार्डकोडिंग।

हम अपने उन सभी एप्लिकेशन को जस का तस रखेंगे जो अधिक सक्षम दृष्टिकोण का उपयोग करते हैं, जैसे लाइसेंसिंग सर्वर।

संबंधित आवश्यकताएँ

हम इन फ़ाइलों के लिए devops क्षमताएँ जोड़ेंगे, जिनमें हुक, परीक्षण और निरंतर एकीकरण शामिल हैं।

हमें इस निर्णय पर अपने सभी डेवलपर साथियों को प्रशिक्षित करना होगा।

संबंधित कलाकृतियाँ

जहाँ हम तैनात करते हैं, उन प्रत्येक क्षेत्र को अपनी .env फ़ाइल और संबंधित फ़ाइलों की आवश्यकता होगी।

संबंधित सिद्धांत

आसानी से पलटा जा सकने वाला।

टिप्पणियाँ

उदाहरण फ़ाइल .env:

NAME=Alice Anderson
EMAIL=alice@example.com

उदाहरण फ़ाइल .env.defaults:

NAME=Joe Doe
EMAIL=joe@example.com

केवल कुंजियों वाली उदाहरण फ़ाइल .env.schema:

NAME
EMAIL