ماحولیاتی متغیرات کی ترتیب
فہرست:
خلاصہ
مسئلہ
ہم چاہتے ہیں کہ ہماری ایپلیکیشنز آرٹیفیکٹس/بائنریز/سورس سے آگے قابلِ ترتیب ہوں، تاکہ ایک بلڈ اپنے ڈپلائمنٹ ماحول کے مطابق مختلف رویہ اختیار کر سکے۔
اسے حاصل کرنے کے لیے ہم ماحولیاتی متغیرات کی ترتیب استعمال کرنا چاہتے ہیں۔
ہم ترتیب کو ایسی فائلوں کے ذریعے منظم کرنا چاہتے ہیں جنہیں ہم ورژن کنٹرول میں رکھ سکیں۔
ہم ڈویلپر کے تجربے کی کچھ سہولتیں فراہم کرنا چاہتے ہیں، مثلاً یہ جاننا کہ کیا ترتیب دیا جا سکتا ہے اور کوئی متعلقہ ڈیفالٹ۔
فیصلہ
متعلقہ ڈیفالٹ فائل اور اسکیما فائل کے ساتھ .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