মোবাইল ডেভেলপমেন্টে .env ফাইল: এটি কী, উদ্দেশ্য এবং কাজের নীতি

.env ফাইল কী এবং কেন এটি প্রয়োজন

.env File একটি কনফিগারেশন ফাইল যা সাধারণ টেক্সট বিন্যাস KEY=VALUE-তে এনভায়রনমেন্ট ভেরিয়েবল সংরক্ষণ করে। প্রতিটি লাইনে একটি ভেরিয়েবল থাকে: কী-এর নাম এবং তার মান, সমান চিহ্ন দ্বারা পৃথক করা।

.env ফাইলগুলি আধুনিক ডেভেলপমেন্টের একটি মৌলিক সমস্যা সমাধান করে: বিভিন্ন পরিবেশ (স্থানীয়, পরীক্ষামূলক, উৎপাদন) সম্পূর্ণ ভিন্ন সেটিংস প্রয়োজন। স্থানীয় মেশিনে API সার্ভার URL হল http://localhost:8080, উৎপাদন সার্ভারে https://api.production.com। যদি এই মানগুলি সরাসরি অ্যাপ্লিকেশন কোডে হার্ডকোড করা থাকে, তবে প্রতিটি ভিন্ন পরিবেশের জন্য বিল্ডের জন্য সোর্স কোড পরিবর্তন প্রয়োজন হয়।

প্রধান অ্যাপ্লিকেশন কোডের বাইরে কনফিগারেশন সংরক্ষণের অভ্যাসটি The Twelve-Factor App ইশতেহারে (2011) মানক করা হয়েছিল, যা এনভায়রনমেন্ট ভেরিয়েবলকে অ্যাপ্লিকেশন কনফিগার করার একমাত্র সঠিক উপায় হিসাবে চিহ্নিত করেছিল। JetBrains Developer Ecosystem জরিপ (2024) অনুসারে, 67% এর বেশি মোবাইল ডেভেলপার তাদের প্রকল্পে .env ফাইল ব্যবহার করেন।

মোবাইল ডেভেলপমেন্টের জন্য, .env একটি অতিরিক্ত সুবিধা দেয়: মান বিল্ড পর্যায়ে Gradle (Android) বা xcconfig (iOS) এর মাধ্যমে প্রতিস্থাপিত হয়, যা সোর্স কোড পরিবর্তন না করেই ডেভেলপমেন্ট, স্টেজিং এবং প্রোডাকশনের জন্য পৃথক বিল্ড তৈরি করতে দেয়।

.env দলে কাজ করার সময় বিশেষভাবে কার্যকর: প্রতিটি ডেভেলপার তাদের নিজস্ব পরিবেশের জন্য সেটিংস সহ নিজস্ব স্থানীয় .env তৈরি করে (স্থানীয় DB পাথ, ডিবাগ API কী), যখন সাধারণ সেটিংস রিপোজিটরিতে .env.example হিসাবে স্থির করা হয়। এটি সেই পরিস্থিতি দূর করে যেখানে git pull-এর পরে একজন ডেভেলপারের বিল্ড একটি অজানা এনভায়রনমেন্ট ভেরিয়েবলের অভাবে ভেঙে যায়। দলের নতুন সদস্য কেবল .env.example কে .env-তে কপি করে এবং নিজের স্থানীয় মান পূরণ করে।

.env ফাইলের সিনট্যাক্স এবং গঠন

.env বিন্যাস অত্যন্ত সহজ: প্রতিটি লাইন KEY=VALUE আকারে একটি ভেরিয়েবল। সমান চিহ্নের আশেপাশের স্পেস সাধারণত উপেক্ষা করা হয়, তবে বেশিরভাগ লাইব্রেরিতে সেগুলি মানের অংশ হিসাবে বিবেচিত হয়, তাই এগুলি এড়ানো ভাল।

লেখার মৌলিক নিয়ম

মন্তব্য # চিহ্ন দিয়ে শুরু হয় — এর পরে পুরো লাইনটি উপেক্ষা করা হয়। খালি লাইনগুলিও এড়িয়ে যাওয়া হয়। যদি মানটিতে স্পেস থাকে, তবে এটি ডবল বা সিঙ্গেল কোটেশনের মধ্যে আবদ্ধ থাকে।

# মৌলিক এনভায়রনমেন্ট সেটিংস
APP_NAME=MyMobileApp
APP_ENV=development

# API কনফিগারেশন
API_BASE_URL=http://localhost:3000/api
API_TIMEOUT=30000

# সংবেদনশীল ডেটা
DB_PASSWORD=secret_password_123
JWT_SECRET=your_jwt_secret_key

মানের ধরন এবং এস্কেপিং

.env-এর সব ভেরিয়েবল স্ট্রিং, তবে লোডার লাইব্রেরি সেগুলিকে প্রয়োজনীয় টাইপে রূপান্তর করতে পারে। বিশেষ অক্ষর এস্কেপ করার জন্য ব্যাকস্ল্যাশ এবং কোটেশন ব্যবহার করা হয়। যদি মানটিতে পাঠ্যের অংশ হিসাবে # অক্ষর থাকে, তবে এটি \# হিসাবে এস্কেপ করা উচিত।

• স্ট্রিং — কোটেশন ছাড়া বা কোটেশনের মধ্যে: KEY=value বা KEY="value with spaces"
• সংখ্যা — কোটেশন ছাড়া লেখা হয়: PORT=8080
• বুলিয়ান মান — স্ট্রিং true/false: DEBUG=true
• মাল্টিলাইন — লাইনের শেষে ব্যাকস্ল্যাশ: KEY=line1\
line2
• প্রতিস্থাপন — কিছু পার্সারে: DB_URL=${DB_HOST}:${DB_PORT}

.env লোড করার সময়, লাইব্রেরি ভেরিয়েবল ইন্টারপোলেশন করতে পারে — এক কী-এর মান অন্যটির ভিতরে প্রতিস্থাপন করা। উদাহরণস্বরূপ, ভেরিয়েবল DATABASE_URL=postgres://${DB_USER}:${DB_PASS}@localhost/db একই ফাইল থেকে DB_USER এবং DB_PASS সম্প্রসারিত করবে।

মোবাইল প্রকল্পে .env ফাইল সংহতকরণ

.env সংযোগের পদ্ধতি প্ল্যাটফর্মের উপর নির্ভর করে। Android Gradle প্লাগইন ব্যবহার করে, iOS — xcconfig কনফিগারেশন ফাইল, এবং ক্রস-প্ল্যাটফর্ম সমাধান যেমন Flutter — বিশেষায়িত লাইব্রেরি।

Android এবং Gradle: BuildConfig সেটআপ

Android-এ, .env gradle-dotenv প্লাগইনের মাধ্যমে লোড করা হয়। প্লাগইন প্রকল্পের রুট থেকে .env পড়ে এবং BuildConfig-এ মান যোগ করে, যার পরে সেগুলি জেনারেটেড ফিল্ডের মাধ্যমে Kotlin বা Java কোডে উপলব্ধ হয়।

// build.gradle.kts (app level)
plugins {
    id("co.uzzu.dotenv") version "4.0.0"
}

android {
    buildFeatures {
        buildConfig = true
    }
}

kotlin {
    // কোডে অ্যাক্সেস: BuildConfig.API_BASE_URL
    buildConfigField("String", "API_BASE_URL",
        "\"" + dotenv.get("API_BASE_URL") + "\"")
}

iOS এবং Xcode: Config সংযোগ

iOS-এ, এনভায়রনমেন্ট ভেরিয়েবল সাধারণত xcconfig ফাইলের মাধ্যমে কনফিগার করা হয়। Swift-এ .env লোড করতে DotEnv লাইব্রেরি বা কাস্টম কী সহ বিল্ট-ইন Info.plist মেকানিজম ব্যবহার করা হয়।

// Swift প্রকল্পে .env লোড করা
import DotEnv

struct AppConfig {
    static func load() {
        let env = DotEnv(Bundle.main)
        env.load()

        let apiURL = ProcessInfo.processInfo
            .environment["API_BASE_URL"] ??
            "https://default.api.com"
    }
}

Flutter এবং Dart: flutter_dotenv লাইব্রেরি

Flutter-এর জন্য flutter_dotenv প্যাকেজ রয়েছে, যা অ্যাপ্লিকেশন initialization-এর সময় .env থেকে ভেরিয়েবল লোড করে। .env ফাইলটি প্রকল্পের রুটে রাখা হয় এবং ভেরিয়েবলগুলি dotenv ক্লাসের মাধ্যমে উপলব্ধ হয়।

// pubspec.yaml
dependencies:
  flutter_dotenv: ^5.1

// main.dart — স্টার্টআপে লোড হচ্ছে
import 'package:flutter_dotenv/flutter_dotenv.dart';

void main() async {
  await dotenv.load(fileName: '.env');
  var apiUrl = dotenv.get('API_BASE_URL');
  runApp(MyApp(baseUrl: apiUrl));
}

তিনটি পদ্ধতিই একটি সাধারণ নীতি ভাগ করে: .env বিল্ড পর্যায়ে বা অ্যাপ্লিকেশন শুরু হওয়ার সময় লোড করা হয়, মানগুলি ক্যাশে করা হয় এবং জেনারেটেড কনস্ট্যান্টের মাধ্যমে কোডে ব্যবহার করা হয়। এটি সংবেদনশীল ডেটাকে রিপোজিটরিতে যেতে বাধা দেয়।

React Native-এর জন্য react-native-config প্যাকেজ ব্যবহার করা হয়, যা বিল্ড পর্যায়ে প্রকল্পের রুটে একটি .env ফাইল থেকে Android-এর জন্য BuildConfig ক্লাস এবং iOS-এর জন্য Info.plist-এ কনস্ট্যান্ট স্বয়ংক্রিয়ভাবে জেনারেট করে। এটি বিশেষ করে স্টার্টআপগুলির জন্য সুবিধাজনক যারা Expo বা bare workflow ব্যবহার করে: রুট স্তরে একটি মাত্র .env সব প্ল্যাটফর্মকে কনফিগারেশন ডুপ্লিকেট না করেই একই এনভায়রনমেন্ট ভেরিয়েবল পেতে দেয়।

.env ফাইল নিরাপত্তা এবং সর্বোত্তম অনুশীলন

সমস্ত সুবিধা সত্ত্বেও, .env উৎপাদন পরিবেশে গোপনীয় তথ্য সংরক্ষণের জন্য একটি সম্পূর্ণ সমাধান নয়। এটি সুরক্ষার একটি মৌলিক স্তর সরবরাহ করে, কিন্তু ভুলভাবে ব্যবহার করলে এটি গোপনীয় ডেটা ফাঁসের কারণ হতে পারে।

.gitignore এর মাধ্যমে সুরক্ষা

সবচেয়ে গুরুত্বপূর্ণ নিয়ম — .env কখনই রিপোজিটরির সংস্করণ নিয়ন্ত্রণ ব্যবস্থায় যাওয়া উচিত নয়। ফাইলটি তৈরি করার সাথে সাথেই .gitignore-এ যোগ করা হয় এবং শুধুমাত্র নমুনা ফাইল .env.example খালি বা নকল মান সহ রিপোজিটরিতে কমিট করা হয়।

# .env.example — রিপোজিটরিতে কমিট করা হয়েছে
APP_NAME=
APP_ENV=development
API_BASE_URL=http://localhost:3000
API_TIMEOUT=30000
# DB_PASSWORD — উদাহরণেও উল্লেখ করবেন না!
# JWT_SECRET — উদাহরণেও উল্লেখ করবেন না!

# .gitignore
# Dotenv ফাইল
.env
.env*.local

উৎপাদন পরিবেশের জন্য বিকল্প

উৎপাদন প্রকল্পের জন্য, পেশাদার গোপনীয়তা ব্যবস্থাপনা সমাধান ব্যবহার করার পরামর্শ দেওয়া হয়। উৎপাদনে .env কেবল তখনই গ্রহণযোগ্য যখন ফাইলটি সার্ভারের document-root-এর বাইরে অবস্থিত এবং কঠোর অ্যাক্সেস অনুমতি রয়েছে।

• AWS Secrets Manager — কী রোটেশন এবং অ্যাক্সেস অডিট সহ ক্লাউড সিক্রেট স্টোরেজ
• Google Secret Manager — API কী এবং পাসওয়ার্ড সংরক্ষণের জন্য Google Cloud পরিষেবা
• HashiCorp Vault — ডায়নামিক সিক্রেট এবং সার্ভার-সাইড এনক্রিপশন সহ টুল
• Firebase Remote Config — মোবাইল অ্যাপ্লিকেশনের জন্য A/B টেস্টিং সহ ক্লাউড কনফিগারেশন
• GitLab CI/CD Variables — বিল্ড পাইপলাইনের জন্য বিল্ট-ইন সিক্রেট স্টোরেজ

Snyk State of Open Source Security (2024) অনুসারে, রিপোজিটরির মাধ্যমে .env ফাইল ফাঁস জরিপ করা কোম্পানিগুলির মধ্যে সমস্ত API কী প্রকাশের ঘটনার 12% এর বেশি কারণ ছিল। একটি ডেডিকেটেড সিক্রেট ম্যানেজার ব্যবহার এই ঝুঁকি শূন্যে নামিয়ে আনে।

প্রি-কমিট হুক বাস্তবায়নের মাধ্যমে অতিরিক্ত সুরক্ষা অর্জন করা হয়, যেখানে husky এবং lint-staged এর মতো টুল ব্যবহার করা হয়, যা পরীক্ষা করে যে ডেভেলপার দুর্ঘটনাক্রমে .env কমিটে যোগ করেছে কিনা। git-secrets (AWS) এবং talisman এর মতো টুল প্রতিটি কমিট API কী, টোকেন এবং পাসওয়ার্ডের প্যাটার্নের জন্য স্ক্যান করে, শনাক্ত হলে কমিট ব্লক করে। CI পাইপলাইনের জন্য, detect-secrets যোগ করার পরামর্শ দেওয়া হয় — একটি স্বয়ংক্রিয় স্ক্যানার যা ডেভেলপারের ভুল হলেও .env ফাইলকে রিপোজিটরিতে যেতে দেবে না।