पर्यावरण चर: ये क्या हैं, मोबाइल प्रोजेक्ट्स में उपयोग और कॉन्फ़िगरेशन

पर्यावरण चर क्या हैं

पर्यावरण चर एक कुंजी-मान जोड़ी होते हैं जो ऑपरेटिंग सिस्टम API के माध्यम से एप्लिकेशन प्रक्रिया के लिए सुलभ होते हैं। ये प्रक्रिया बनाते समय इसे पास किए जाते हैं और केवल इसके रनटाइम के दौरान मौजूद रहते हैं। स्रोत कोड में एम्बेडेड कॉन्फ़िगरेशन पैरामीटर के विपरीत, पर्यावरण चरों को मान बदलने के लिए पुनः कंपाइलेशन की आवश्यकता नहीं होती। यह Twelve-Factor App का मूलभूत सिद्धांत है, जो कोड और कॉन्फ़िगरेशन के बीच स्पष्ट पृथक्करण सुनिश्चित करता है।

मोबाइल डेवलपमेंट में, पर्यावरण चर विभिन्न वातावरणों के लिए अलग-अलग कॉन्फ़िगरेशन की समस्या को हल करते हैं: डेवलपर स्थानीय सर्वर का उपयोग करता है, परीक्षक staging का उपयोग करता है, और उपयोगकर्ता प्रोडक्शन का उपयोग करते हैं। कोड में if-else शर्तों के साथ तीन बैकएंड URL संग्रहीत करने के बजाय, डेवलपर बिल्ड समय पर पर्यावरण चर के माध्यम से एक URL पास करता है। यह कोड को सरल बनाता है और परीक्षण वातावरण में गलती से प्रोडक्शन सर्वर का उपयोग करने के जोखिम को समाप्त करता है।

मुख्य लाभ सुरक्षा है: संवेदनशील डेटा कोड रिपॉजिटरी में नहीं जाता। API कुंजियाँ, Firebase रहस्य, बैकएंड एक्सेस टोकन और प्रमाणपत्र CI/CD के माध्यम से सीधे बिल्ड वातावरण में लोड किए जाते हैं। यदि कोई हमलावर कोड रिपॉजिटरी तक पहुँच प्राप्त करता है, तो उसे वहाँ कोई रहस्य नहीं मिलेगा, क्योंकि वे CI सिस्टम के संरक्षित भंडारों में संग्रहीत होते हैं और केवल बाइनरी फ़ाइल बिल्ड चरण में पास किए जाते हैं।

मोबाइल डेवलपमेंट में पर्यावरण चरों की आवश्यकता क्यों है

मोबाइल प्रोजेक्ट्स में कम से कम तीन वातावरण होते हैं: डेवलपमेंट, स्टेजिंग और प्रोडक्शन। प्रत्येक वातावरण को अपने स्वयं के कॉन्फ़िगरेशन सेट की आवश्यकता होती है: सर्वर URL, पैकेज नाम, हस्ताक्षर योजना और पुश नोटिफिकेशन प्रमाणपत्र। पर्यावरण चरों के बिना, डेवलपर को प्रत्येक बिल्ड से पहले मैन्युअल रूप से कॉन्फ़िगरेशन बदलना पड़ता है, जिससे त्रुटियाँ होती हैं: परीक्षण बिल्ड में भूला हुआ प्रोडक्शन कुंजी वास्तविक उपयोगकर्ताओं को सूचनाएँ भेज सकता है या भुगतान API की खपत कर सकता है।

वातावरण पृथक्करण

पर्यावरण चर कोड बदले बिना बैकएंड स्विच करने की अनुमति देते हैं: बस API_BASE_URL चर में मान बदलें। फ़ीचर फ़्लैग्स को FEATURE_CHAT_ENABLED=true जैसे चरों के माध्यम से प्रबंधित किया जाता है, जो प्रोडक्शन को प्रभावित किए बिना स्टेजिंग में नई सुविधाओं को सक्षम करने की अनुमति देता है। प्रत्येक वातावरण का अपनी .env फ़ाइल होती है जो बिल्ड समय पर लोड होती है।

class AppConfig {
  static final String apiBaseUrl =
    const String.fromEnvironment('API_BASE_URL',
      defaultValue: 'http://localhost:8080');
}

कुंजी सुरक्षा

हार्डकोडेड कुंजियाँ मोबाइल एप्लिकेशन की एक सामान्य कमज़ोरी हैं। एक हमलावर jadx या Hopper जैसे टूल का उपयोग करके APK या IPA को डीकंपाइल करता है और बाइनरी फ़ाइल से रहस्य निकालता है। यहाँ तक कि ऑबफ़स्केशन भी स्ट्रिंग लिटरल की रक्षा नहीं करता — वे डीकंपाइलेशन के बाद कोड में आसानी से मिल जाते हैं। पर्यावरण चर इस समस्या को CI/CD के माध्यम से बिल्ड समय पर कुंजियाँ पास करके हल करते हैं, जहाँ वे लॉग में मास्क किए जाते हैं।

object Config {
    val apiKey: String =
        System.getenv("API_KEY") ?: throw
            IllegalStateException("API_KEY not set")
}

CI/CD एकीकरण

पर्यावरण चर बिल्ड पाइपलाइनों के साथ एकीकृत होते हैं: GitHub Actions, GitLab CI, Bitrise और CircleCI गुप्त चरों का समर्थन करते हैं जो लॉग में प्रदर्शित नहीं होते। बिल्ड समय पर, CI ब्रांच या टैग के आधार पर उपयुक्त मान प्रतिस्थापित करता है: develop ब्रांच के लिए staging उपयोग किया जाता है, v* टैग के लिए प्रोडक्शन उपयोग किया जाता है। यह प्रक्रिया को स्वचालित करता है और मानवीय कारक को समाप्त करता है, यह सुनिश्चित करता है कि प्रत्येक बिल्ड को कॉन्फ़िगरेशन का सही सेट मिलता है।

.env फ़ाइलें और प्रबंधन लाइब्रेरी

.env फ़ाइल KEY=VALUE फ़ॉर्मेट में पर्यावरण चरों को संग्रहीत करने का एक मानक तरीका है। इसे रिपॉजिटरी में शामिल नहीं किया जाता; इसके बजाय, सभी चरों के टेम्पलेट और खाली मानों के साथ .env.example जोड़ा जाता है। प्रत्येक डेवलपर टीम के अन्य सदस्यों के कॉन्फ़िगरेशन को प्रभावित किए बिना स्थानीय सेटिंग्स के साथ अपनी .env फ़ाइल बनाता है। विभिन्न वातावरणों के लिए अलग-अलग फ़ाइलों का उपयोग किया जाता है: .env.dev, .env.stage, .env.prod।

# .env.example — डेवलपर्स के लिए टेम्पलेट
API_BASE_URL=http://localhost:8080
FEATURE_CHAT_ENABLED=true
SENTRY_DSN=

मोबाइल प्रोजेक्ट्स के लिए, .env फ़ाइलों के साथ काम करने के लिए विशेष लाइब्रेरी मौजूद हैं:

• flutter_dotenv (Flutter) — dotenv.load() के माध्यम से रनटाइम पर .env से चर लोड करता है
• BuildConfig (Android) — build.gradle मानों से टाइप किए गए फ़ील्ड उत्पन्न करता है
• xcconfig (iOS) — विभिन्न Xcode बिल्ड स्कीमों से कॉन्फ़िगरेशन फ़ाइलों को जोड़ता है
• react-native-config (React Native) — .env फ़ाइलों के माध्यम से चर प्रबंधन

CI/CD में ब्रांचिंग सेटिंग्स विभिन्न .env फ़ाइलों को प्रतिस्थापित करने की अनुमति देती हैं: परीक्षण सर्वरों के लिए .env.dev, प्री-रिलीज़ के लिए .env.stage और ऐप स्टोर पर प्रकाशन के लिए .env.prod। रहस्यों वाली फ़ाइलें सुरक्षित भंडार (Vault, AWS Secrets Manager) से लोड की जाती हैं और रिपॉजिटरी में संग्रहीत नहीं की जाती हैं। यह सुनिश्चित करता है कि संस्करण नियंत्रण प्रणाली से समझौता होने पर भी, रहस्य सुरक्षित रहते हैं।

iOS प्रोजेक्ट्स में पर्यावरण चर

iOS इकोसिस्टम बिल्ड स्तर पर चर प्रबंधित करने के लिए xcconfig फ़ाइलों का उपयोग करता है। ये Xcode स्कीमों से जुड़ी होती हैं और Debug तथा Release कॉन्फ़िगरेशन के लिए मानों को ओवरराइड करने की अनुमति देती हैं। xcconfig फ़ाइलें इनहेरिटेंस का समर्थन करती हैं: सामान्य सेटिंग्स के साथ एक आधार फ़ाइल और प्रत्येक वातावरण के लिए विशिष्ट फ़ाइलें बनाई जा सकती हैं।

xcconfig फ़ाइलों का कॉन्फ़िगरेशन

xcconfig फ़ाइलें KEY = VALUE फ़ॉर्मेट में चर संग्रहीत करती हैं और Configuration सेटिंग्स के माध्यम से Xcode में बिल्ड स्कीम से जुड़ी होती हैं। xcconfig से चर $(VARIABLE_NAME) सिंटैक्स के माध्यम से Info.plist में उपलब्ध होते हैं, जो विभिन्न स्कीमों के लिए अलग-अलग बंडल पहचानकर्ता और ऐप नाम की अनुमति देता है। त्वरित वातावरण पहचान के लिए, ऐप नाम में Dev या Staging प्रत्यय जोड़ा जाता है।

# Config/Dev.xcconfig — डेवलपमेंट कॉन्फ़िगरेशन
API_BASE_URL = http://localhost:3000
BUNDLE_ID_SUFFIX = .dev
APP_DISPLAY_NAME = MyApp Dev

चर पढ़ने के लिए Swift कोड

iOS में चरों तक रनटाइम पहुँच के लिए, Configuration.swift फ़ाइल का उपयोग किया जाता है, जो Bundle.main.object(forInfoDictionaryKey:) के माध्यम से Info.plist से मान पढ़ती है। यह दृष्टिकोण गारंटी देता है कि चर बिल्ड समय पर परिभाषित होते हैं और लॉन्च के तुरंत बाद एप्लिकेशन के लिए उपलब्ध होते हैं। मान मॉड्यूल इनिशियलाइज़ेशन के दौरान एक बार पढ़े जाते हैं और एप्लिकेशन जीवनचक्र के दौरान त्वरित पहुँच के लिए कैश किए जाते हैं।

enum AppEnvironment {
    static var apiBaseURL: URL {
        guard let urlString = Bundle.main
            .object(forInfoDictionaryKey: "API_BASE_URL"),
              let url = URL(string: urlString as! String)
        else { fatalError("API_BASE_URL is not configured") }
        return url
    }

    static var isChatEnabled: Bool {
        Bundle.main.object(
            forInfoDictionaryKey: "FEATURE_CHAT_ENABLED"
        ) as? Bool ?? false
    }
}

Android प्रोजेक्ट्स में पर्यावरण चर

Android BuildConfig के माध्यम से पर्यावरण चरों का समर्थन करता है — एक स्वचालित रूप से उत्पन्न वर्ग जिसके फ़ील्ड मॉड्यूल की build.gradle फ़ाइल में परिभाषित होते हैं। BuildConfig प्रत्येक फ्लेवर और बिल्ड प्रकार के लिए अलग-अलग कंपाइल समय पर बनाया जाता है। यह कोड में सशर्त ऑपरेटरों का उपयोग किए बिना डिबग और रिलीज़ के लिए अलग-अलग मान रखने की अनुमति देता है, जिससे प्रदर्शन और सुरक्षा में सुधार होता है।

BuildConfig फ़ील्ड का कॉन्फ़िगरेशन

BuildConfig फ़ील्ड defaultConfig या विशिष्ट buildTypes में buildConfigField के माध्यम से सेट किए जाते हैं। प्रत्येक वातावरण के लिए एक अलग buildType या productFlavor बनाया जाता है। यह सख्त कॉन्फ़िगरेशन पृथक्करण सुनिश्चित करता है: डिबग स्थानीय सर्वर का उपयोग करता है, रिलीज़ प्रोडक्शन का उपयोग करता है। BuildConfig फ़ील्ड स्थिर रूप से टाइप किए जाते हैं, जो कोड में उन तक पहुँचने पर त्रुटियों को समाप्त करता है।

// build.gradle (Module: app)
android {
    defaultConfig {
        buildConfigField "String", "API_BASE_URL",
            "\"http://localhost:8080\""
    }
    buildTypes {
        debug {
            buildConfigField "String", "API_BASE_URL",
                "\"http://dev.api.itsectr.com\""
        }
        release {
            buildConfigField "String", "API_BASE_URL",
                "\"https://api.itsectr.com\""
        }
    }
}

साझा मानों के लिए gradle.properties

प्रोजेक्ट रूट में gradle.properties फ़ाइल वैश्विक Gradle चर संग्रहीत करती है। ये $variableName सिंटैक्स के माध्यम से सभी मॉड्यूल में उपलब्ध होते हैं और निर्भरता संस्करणों, बिल्ड फ़्लैग्स और API कुंजियों को निर्दिष्ट करने के लिए उपयोग किए जाते हैं। BuildConfig के विपरीत, gradle.properties केवल Gradle कॉन्फ़िगरेशन चरण में काम करता है, एप्लिकेशन रनटाइम पर नहीं। इसलिए, gradle.properties में निर्दिष्ट पासवर्ड और API कुंजियाँ डीकंपाइल्ड कोड में दिखाई नहीं देती हैं, क्योंकि वे केवल कंपाइल समय पर BuildConfig उत्पन्न करने के लिए उपयोग की जाती हैं।

# gradle.properties
SENTRY_DSN=https://key@sentry.io/project
MAPS_API_KEY=AIzaSy...

Android प्रोजेक्ट्स में रहस्यों के सुरक्षित स्थानांतरण के लिए, local.properties (VCS से बाहर रखा गया) या System.getenv() के माध्यम से build.gradle में CI/CD चरों से मान लोड करने की अनुशंसा की जाती है। यह सुनिश्चित करता है कि कुंजियाँ रिपॉजिटरी में नहीं जाती हैं। Google Play Console पर प्रकाशित करते समय, सुनिश्चित करें कि सभी डिबग कुंजियों को संबंधित BuildConfig मानों के साथ विभिन्न buildTypes या productFlavors के माध्यम से प्रोडक्शन संस्करणों से बदल दिया गया है।