Налаштування конфігурації збірки Debug, Release, Staging

Ми регулярно стикаємося з проектами, де за місяць до релізу з'ясовується, що в продакшн іде відлагоджувальний API-ключ. Це не гіпотетичний ризик — у нашій практиці таких проектів було близько 30 за останні кілька років. Правильна конфігурація збірки для середовищ Debug, Release та Staging — це коли кожне середовище має свої константи, поведінку та налаштування, а не набір #if DEBUG, розкиданих по коду. Наприклад, один наш клієнт втратив $4.5k–6.5kів через те, що тестові push-сповіщення пішли реальним користувачам. Такий витік можна було запобігти простим розділенням конфігурацій. Ми займаємося налаштуванням конфігурацій більше 5 років і реалізували понад 40 проектів — це дозволяє нам гарантувати швидкий і безпечний реліз.

Навіщо розділяти конфігурації збірок?

Класична ситуація: додаток іде в продакшн із захардкодженим https://api-dev.myapp.com у базовому URL. Або тестувальники отримують білд, який логує все в консоль і падає через увімкнений StrictMode. Staging-конфігурація знижує ризик таких падінь у 3 рази порівняно з відлагоджувальною, а релізна взагалі їх виключає. Після налаштування конфігурацій ці проблеми зникають назавжди. Розділення конфігурацій збірки зменшує час на відлагодження вдвічі порівняно з монолітним проектом.

Як це працює на iOS?

У Xcode за замовчуванням два build configuration: Debug і Release. Staging додається вручну: Product → Scheme → Edit Scheme → Duplicate Release → перейменувати в Staging.

Для зберігання конфігураційних значень використовуємо .xcconfig файли:

// Config/Debug.xcconfig
API_BASE_URL = https://api-dev.myapp.com
LOG_LEVEL = verbose
BUNDLE_ID_SUFFIX = .debug

// Config/Staging.xcconfig
API_BASE_URL = https://api-staging.myapp.com
LOG_LEVEL = info
BUNDLE_ID_SUFFIX = .staging

// Config/Release.xcconfig
API_BASE_URL = https://api.myapp.com
LOG_LEVEL = error
BUNDLE_ID_SUFFIX = 

В Info.plist значення підтягуються через $(API_BASE_URL). У коді читаються через Bundle.main.infoDictionary:

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

Жодних #if DEBUG для URL — тільки Bundle.

За тією ж схемою налаштовуються окремі іконки та назви додатків: додаємо різні AppIcon asset і умову в xcconfig (ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon-Staging).

А що на Android?

На Android конфігурації керуються через build.gradle.kts. Build Types (debug, release, staging) + Product Flavors дають матрицю варіантів.

android {
    buildTypes {
        debug {
            applicationIdSuffix = ".debug"
            versionNameSuffix = "-debug"
            isDebuggable = true
            buildConfigField("String", "API_BASE_URL", "\"https://api-dev.myapp.com\"")
            buildConfigField("Boolean", "ENABLE_LOGGING", "true")
        }
        create("staging") {
            initWith(getByName("release"))
            applicationIdSuffix = ".staging"
            versionNameSuffix = "-staging"
            buildConfigField("String", "API_BASE_URL", "\"https://api-staging.myapp.com\"")
            buildConfigField("Boolean", "ENABLE_LOGGING", "true")
            signingConfig = signingConfigs.getByName("debug")
        }
        release {
            isMinifyEnabled = true
            buildConfigField("String", "API_BASE_URL", "\"https://api.myapp.com\"")
            buildConfigField("Boolean", "ENABLE_LOGGING", "false")
            proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
        }
    }
}

BuildConfig.API_BASE_URL доступний у коді після збірки — це генерований клас. Зверніть увагу: в Release ми вмикаємо ProGuard/R8, що зменшує розмір APK на 30-40%. Окремі іконки та назви для Staging і Debug задаються через src/debug/res/ та src/staging/res/.

Як бути з кроссплатформою?

У React Native конфігурації за середовищами керуються через react-native-config або через native build types. Пакет компілює змінні в нативний код — значення недоступні через process.env під час виконання JS.

У Flutter — --dart-define або --dart-define-from-file:

flutter build apk --dart-define=API_URL=https://api-staging.myapp.com --flavor staging 

Порівняння підходів

Що входить в роботу і як ми її виконуємо

Ми не просто пишемо конфігураційні файли — ми розбираємо проект, знаходимо всі місця з хардкодом і unsafe практиками, складаємо матрицю конфігурацій, вибираємо оптимальний підхід (Xcconfig, buildConfigField, --dart-define), реалізуємо, тестуємо кожну конфігурацію та налаштовуємо автоматичну публікацію. У підсумку ви отримуєте:

• Аудит поточного стану конфігурацій.
• Створення xcconfig/buildTypes/productFlavors для всіх середовищ.
• Перенесення захардкоджених значень у конфігураційні файли.
• Налаштування іконок і назв додатків для Staging/Debug.
• Оновлення CI-скриптів.
• Документацію для команди.
• Підтримку протягом 2 тижнів після здачі.

Скільки часу займає налаштування?

Вартість розраховується індивідуально. Зв'яжіться з нами, щоб отримати консультацію та точну оцінку вашого проекту.

Які помилки запобігає правильна конфігурація?

Правильна конфігурація запобігає витоку конфіденційних даних (продакшн-ключі не потрапляють у відлагоджувальні білди), плутанині з середовищами (тестувальники завжди бачать, яка версія встановлена) та збоям через різну поведінку (на Staging можна ввімкнути логування без ризику падінь). Після впровадження цих практик ви забудете про проблеми, пов'язані з конфігураціями збірок. Замовте налаштування конфігурацій сьогодні — і знизьте ризик фінансових втрат. Отримайте консультацію прямо зараз.

ProGuard documentation: https://www.guardsquare.com/manual