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

শুধু কী (key) সহ উদাহরণ .env.schema ফাইল:

NAME
EMAIL