Architecture Decision Record

Active theme: Light

← निर्णय नोंद उदाहरणे

पर्यावरण चल कॉन्फिगरेशन

सामग्री:

सारांश

समस्या

आम्हाला आमचे अनुप्रयोग आर्टिफॅक्ट/बायनरी/स्रोताच्या पलीकडे कॉन्फिगर करता येण्याजोगे हवे आहेत, जेणेकरून एकच बिल्ड त्याच्या डिप्लॉयमेंट वातावरणानुसार वेगळे वागू शकेल.

  • हे साध्य करण्यासाठी, आम्हाला पर्यावरण चल कॉन्फिगरेशन वापरायचे आहे.

  • आम्हाला आवृत्ती नियंत्रित करता येणाऱ्या फाईलींचा वापर करून कॉन्फिगरेशन व्यवस्थापित करायचे आहे.

  • आम्हाला काही विकासक अनुभव सुलभता द्यायची आहे, जसे की काय कॉन्फिगर करता येते आणि संबंधित डीफॉल्ट काय आहेत हे जाणून घेणे.

निर्णय

संबंधित डीफॉल्ट फाईल आणि स्कीमा फाईलसह .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