Környezeti változók: mi ez, használat és konfigurálás mobil projektekben

Mik azok a környezeti változók

A környezeti változók egy kulcs-érték pár, amely az operációs rendszer API-ján keresztül érhető el az alkalmazás folyamata számára. A folyamat létrehozásakor kerülnek átadásra, és csak annak futási ideje alatt léteznek. Ellentétben a forráskódba ágyazott konfigurációs paraméterekkel, a környezeti változók nem igényelnek újrafordítást az értékek megváltoztatásához. Ez a Twelve-Factor App alapelve, amely egyértelmű elválasztást biztosít a kód és a konfiguráció között.

A mobilfejlesztésben a környezeti változók megoldják a különböző konfigurációk problémáját a környezetekhez: a fejlesztő helyi szervert használ, a tesztelő staging-et, a felhasználók az éles környezetet. Ahelyett, hogy három backend URL-t tárolna a kódban if-else feltételes operátorokkal, a fejlesztő egy URL-t ad át egy környezeti változón keresztül a build szakaszban. Ez leegyszerűsíti a kódot és kiküszöböli az éles szerver véletlen használatának kockázatát a tesztkörnyezetben.

A fő előny a biztonság: az érzékeny adatok nem kerülnek be a kód repozitóriumba. Az API-kulcsok, Firebase titkok, backend hozzáférési tokenek és tanúsítványok CI/CD-n keresztül közvetlenül a build környezetbe töltődnek be. Ha egy támadó hozzáfér a kód repozitóriumhoz, nem talál ott titkokat, mivel azok a CI rendszer védett tárolóiban vannak, és csak a bináris fájl build szakaszában kerülnek átadásra.

Miért van szükség környezeti változókra a mobilfejlesztésben

A mobil projektek legalább három környezettel rendelkeznek: development, staging és éles. Minden környezet saját konfigurációs készletet igényel: szerver URL, csomagnév, aláírási séma és push értesítési tanúsítványok. Környezeti változók nélkül a fejlesztőnek manuálisan kell módosítania a konfigurációt minden build előtt, ami hibákhoz vezet: egy elfelejtett éles kulcs egy teszt buildben valós felhasználóknak küldött értesítéseket vagy fizetős API fogyasztást okozhat.

Környezetek szétválasztása

A környezeti változók lehetővé teszik a backend váltását a kód módosítása nélkül: elegendő az API_BASE_URL változó értékét kicserélni. A funkciókapcsolók (feature flags) olyan változókon keresztül kezelődnek, mint a FEATURE_CHAT_ENABLED=true, ami lehetővé teszi új funkciók bekapcsolását a staging-ben az éles környezet befolyásolása nélkül. Minden környezethez saját .env fájl készül, amely a build szakaszban töltődik be.

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

Kulcsok biztonsága

A keményen kódolt kulcsok a mobil alkalmazások gyakori sérülékenysége. Egy támadó jadx vagy Hopper eszközökkel dekompilálja az APK-t vagy IPA-t, és kinyeri a titkokat a bináris fájlból. Még az obfuszkáció sem védi a string literálokat — ezek könnyen megtalálhatók a kódban a dekompilálás után. A környezeti változók megoldják ezt a problémát azáltal, hogy a kulcsokat a build szakaszban CI/CD-n keresztül adják át, ahol elrejtésre kerülnek a naplókban.

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

CI/CD integráció

A környezeti változók integrálódnak a build pipeline-okkal: GitHub Actions, GitLab CI, Bitrise és CircleCI támogatják a titkos változókat, amelyek nem jelennek meg a naplókban. A build szakaszban a CI a megfelelő értékeket helyettesíti be az ág vagy tag alapján: a develop ághoz staging, a v* taghez éles környezet használatos. Ez automatizálja a folyamatot és kiküszöböli az emberi tényezőt, garantálva, hogy minden build a megfelelő konfigurációs készletet kapja.

.env fájlok és kezelő könyvtárak

A .env fájl a környezeti változók tárolásának szabványos módja KEY=VALUE formátumban. Nem kerül be a repozitóriumba, helyette .env.example kerül hozzáadásra az összes változó sablonjával és üres értékekkel. Minden fejlesztő létrehozza saját .env fájlját helyi beállításokkal, anélkül hogy befolyásolná a csapat más tagjainak konfigurációját. Különböző környezetekhez külön fájlok használatosak: .env.dev, .env.stage, .env.prod.

# .env.example — sablon fejlesztőknek
API_BASE_URL=http://localhost:8080
FEATURE_CHAT_ENABLED=true
SENTRY_DSN=

Mobil projektekhez speciális könyvtárak léteznek a .env fájlokkal való munkához:

• flutter_dotenv (Flutter) — betölti a változókat a .env-ből futásidőben a dotenv.load() segítségével
• BuildConfig (Android) — tipizált mezőket generál a build.gradle értékekből
• xcconfig (iOS) — konfigurációs fájlokat csatlakoztat különböző Xcode build sémákhoz
• react-native-config (React Native) — változókezelés .env fájlokon keresztül

Az ág beállításai a CI/CD-ben lehetővé teszik különböző .env fájlok behelyettesítését: .env.dev teszt szerverekhez, .env.stage kiadás előttihez, .env.prod pedig az alkalmazásboltokban történő publikáláshoz. A titkokat tartalmazó fájlok biztonságos tárolóból (Vault, AWS Secrets Manager) töltődnek be, és nem kerülnek a repozitóriumba. Ez garantálja, hogy még a verziókezelő rendszer kompromittálása esetén is a titkok védettek maradnak.

Környezeti változók iOS projektekben

Az iOS ökoszisztéma xcconfig fájlokat használ a változók build szintű kezeléséhez. Ezek csatlakoznak az Xcode sémákhoz, és lehetővé teszik az értékek felülírását a Debug és Release konfigurációkhoz. Az xcconfig fájlok támogatják az öröklődést: létrehozható egy alap fájl közös beállításokkal és specifikus fájlok minden környezethez.

xcconfig fájlok konfigurálása

Az xcconfig fájlok KEY = VALUE formátumban tárolják a változókat, és a Configuration beállításokon keresztül csatlakoznak a build sémához az Xcode-ban. Az xcconfig változói a Info.plist-ben érhetők el a $(VARIABLE_NAME) szintaxis segítségével, ami lehetővé teszi különböző bundle azonosítók és alkalmazásnevek használatát különböző sémákhoz. A környezet gyors azonosításához az alkalmazás nevéhez Dev vagy Staging utótag kerül hozzáadásra.

# Config/Dev.xcconfig — fejlesztési konfiguráció
API_BASE_URL = http://localhost:3000
BUNDLE_ID_SUFFIX = .dev
APP_DISPLAY_NAME = MyApp Dev

Swift kód a változók olvasásához

A változók futásidőben történő eléréséhez iOS-ben a Configuration.swift fájl használatos, amely a Bundle.main.object(forInfoDictionaryKey:) segítségével olvassa az értékeket az Info.plist-ből. Ez a megközelítés garantálja, hogy a változók a build szakaszban meghatározásra kerülnek, és közvetlenül az indítás után elérhetők az alkalmazás számára. Az értékek egyszer kerülnek beolvasásra a modul inicializálásakor, és gyors elérés céljából gyorsítótárazásra kerülnek az alkalmazás életciklusa során.

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
    }
}

Környezeti változók Android projektekben

Az Android a környezeti változókat a BuildConfig — egy automatikusan generált osztály, amelynek mezői a modul build.gradle fájljában vannak meghatározva — segítségével támogatja. A BuildConfig a fordítás szakaszában jön létre minden flavor és build típus számára külön-külön. Ez lehetővé teszi különböző értékek használatát debug és release esetén anélkül, hogy feltételes operátorokat használnánk a kódban, ami növeli a teljesítményt és a biztonságot.

BuildConfig mezők konfigurálása

A BuildConfig mezők a buildConfigField segítségével állíthatók be a defaultConfig-ban vagy konkrét buildTypes-ben. Minden környezethez külön buildType vagy productFlavor jön létre. Ez biztosítja a konfigurációk szigorú elkülönítését: debug a helyi szervert használja, release az éles környezetet. A BuildConfig mezők statikusan tipizáltak, ami kiküszöböli a hibákat a kódban történő hivatkozáskor.

// 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 közös értékekhez

A projekt gyökerében található gradle.properties fájl globális Gradle változókat tárol. Ezek a $variableName szintaxis segítségével érhetők el minden modulban, és függőségi verziók, build flag-ek és API-kulcsok megadására használatosak. A BuildConfig-tól eltérően a gradle.properties csak a Gradle konfigurációs szakaszában működik, nem az alkalmazás futásidőben. Ezért a gradle.properties-ben megadott jelszavak és API-kulcsok nem láthatók a dekompilált kódban, mivel csak a BuildConfig fordítási szakaszban történő generálásához használatosak.

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

A titkok biztonságos továbbításához Android projektekben ajánlott a local.properties (VCS-ből kizárt) használata, vagy az értékek betöltése CI/CD változókból a build.gradle-be a System.getenv() segítségével. Ez garantálja, hogy a kulcsok nem kerülnek a repozitóriumba. A Google Play Console-ban történő publikáláskor győződjön meg arról, hogy az összes debug kulcsot lecserélték éles verziókra különböző buildTypes vagy productFlavors segítségével a megfelelő BuildConfig értékekkel.