Mobil proqramlarda Build Config — bu nədir, qurulması və iş prinsipi

Mobil inkişafda Build Config nədir

Build Config — mobil tətbiqin kompilyasiya, yığım və paketləmə prosesini müəyyən edən parametrlər toplusudur. Yığım konfiqurasiyası hədəf platformanın seçimini, minimum SDK versiyasını, optimallaşdırma flaqlarını, imzalama açarlarını və mühit dəyişənlərini əhatə edir.

Müasir mobil layihələrdə nadir hallarda yalnız bir yığım konfiqurasiyası olur. Adətən onlar bir neçə olur: debug (debug ilə inkişaf üçün), release (optimallaşdırma ilə istehsal üçün), staging (real məlumatlarla test üçün) və müxtəlif flavorlar (demo, tam, korporativ versiyalar).

Gradle Build Tool Survey (2025) sorğusuna görə, orta hesabla Android layihəsi 3.2 müxtəlif yığım konfiqurasiyası istifadə edir, iOS layihəsi isə — 2.8. Hər konfiqurasiyanın öz kompilyasiya flaqları, imzalama sertifikatları və server URL-ləri ola bilər.

Build Config-in əsas vəzifəsi bu konfiqurasiyalar arasında keçidi avtomatlaşdırmaqdır. Server URL-ni və ya debug flaqını əl ilə dəyişmək əvəzinə, proqramçı IDE-də istədiyi Build Variant-ı seçir və yığım sistemi müvafiq parametrləri əvəz edir.

Build Config-in düzgün qurulması tətbiqin təhlükəsizliyinə kritik təsir göstərir: debug yığımında ətraflı loglar, verilənlər bazası inspektoru və debug endpointləri aktiv olur, onlar release faylından fiziki olaraq xaric edilməlidir. Gradle bunu Build Types vasitəsilə həll edir: debug-da debuggable true flaqı, release-da ProGuard ilə minifyEnabled true quraşdırıla bilər. iOS buna Swift Active Compilation Conditions vasitəsilə nail olur, burada #if DEBUG daxilindəki kod release konfiqurasiyasında kompilyasiya olunmur.

Android-də Build Config: Gradle və BuildConfig

Android iki əsas anlayışı olan Gradle yığım sistemindən istifadə edir: Build Types və Product Flavors. Onların kombinasiyası Build Variants yaradır — hər variant öz tam yığım konfiqurasiyasına uyğundur.

Build Types: debug və release

Build Type — tətbiqin necə yığıldığını müəyyən edən konfiqurasiyadır. Gradle standart olaraq iki tip yaradır: debug (debug ilə, obfuskasiyasız) və release (ProGuard/R8 ilə, dərc üçün imzalanmış). Proqramçı öz tiplərini əlavə edə bilər: staging, benchmark, qa.

// build.gradle.kts
android {
    buildTypes {
        debug {
            isDebuggable = true
            buildConfigField("String", "API_URL", "\"http://dev.api.com\"")
        }
        release {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
            buildConfigField("String", "API_URL", "\"https://prod.api.com\"")
        }
    }
}

Product Flavors: tətbiqin versiyaları

Product Flavors bir kod bazasından bir tətbiqin müxtəlif versiyalarını yaratmağa imkan verir. Məsələn: reklamlı pulsuz versiya, reklamsız ödənişli versiya və əlavə funksiyaları olan korporativ versiya. Hər flavorun öz applicationId-i, resursları və SDK asılılıqları ola bilər.

android {
    productFlavors {
        register("demo") {
            applicationId = "com.example.app.demo"
            versionNameSuffix = "-demo"
        }
        register("full") {
            applicationId = "com.example.app"
            versionNameSuffix = ""
        }
    }
}

BuildConfig sinfi: koddan giriş

Gradle hər Build Variant üçün konfiqurasiya sahələri olan BuildConfig sinfi yaradır. Proqramçı öz sahələrini buildConfigField vasitəsilə əlavə edir, standart sahələr (DEBUG, APPLICATION_ID, BUILD_TYPE, VERSION_CODE, FLAVOR) isə avtomatik yaradılır.

// Kodda BuildConfig istifadəsi
class NetworkModule {
    fun createApiClient(): ApiClient {
        return if (BuildConfig.DEBUG) {
            ApiClient(
                baseUrl = BuildConfig.API_URL,
                interceptor = HttpLoggingInterceptor()
            )
        } else {
            ApiClient(baseUrl = BuildConfig.API_URL)
        }
    }
}

BuildConfig həmçinin yığım mərhələsində funksionallığı aktivləşdirməyə və ya söndürməyə imkan verir. Məsələn, FEATURE_CHAT_ENABLED sahəsi əlavə edib çatı yalnız tətbiqin tam versiyasında aktivləşdirmək olar, runtime yoxlamaları və kodda şərti operatorlar olmadan.

Şəbəkə sorğularını debug etmək üçün DEBUG sahəli BuildConfig, OkHttp-da HttpLoggingInterceptor-u yalnız debug yığımları üçün avtomatik qoşmağa imkan verir. Bu, istehsalda heç bir HTTP sorğusunun qeydə alınmayacağını təmin edir, hətta proqramçı release yığımından əvvəl logları silməyi təsadüfən unutsa belə.

iOS-da Build Config: Xcode və Build Settings

iOS ekosistemində Build Config Xcode Build Settings vasitəsilə idarə olunur — hər parametrin müxtəlif konfiqurasiyalar (Debug, Release, Staging) üçün fərqli dəyərləri ola bilən parametrlər cədvəlidir.

Xcode Build Configurations

Xcode standart olaraq iki konfiqurasiya yaradır: Debug (inkişaf üçün, optimallaşdırmasız) və Release (istehsal üçün, -Os optimallaşdırması ilə). Proqramçı Project > Info > Configurations menyusu vasitəsilə öz konfiqurasiyalarını əlavə edə bilər.

Hər konfiqurasiya üçün Build Settings qurulur: kompilyator flaqları (OTHER_SWIFT_FLAGS, GCC_PREPROCESSOR_DEFINITIONS), imzalama kodu (CODE_SIGN_IDENTITY), provisioning profilləri və entitlements. Xcode bu parametrləri project.pbxproj faylında saxlayır.

xcconfig: xarici konfiqurasiya faylları

Build Settings-i rahat idarə etmək üçün iOS proqramçıları .xcconfig fayllarından istifadə edirlər — KEY = VALUE formatında parametrləri olan mətn faylları. Bu, Xcode üçün .env-in analoqudur: dəyərlər layihəyə qoşulur və project.pbxproj-dakı parametrləri əvəz edir.

// Debug.xcconfig
BUNDLE_ID_SUFFIX = .debug
API_BASE_URL = http://localhost:8080
SWIFT_ACTIVE_COMPILATION_CONDITIONS = DEBUG
CODE_SIGN_IDENTITY = Apple Development

// Release.xcconfig
BUNDLE_ID_SUFFIX =
API_BASE_URL = https://api.production.com
SWIFT_ACTIVE_COMPILATION_CONDITIONS =
CODE_SIGN_IDENTITY = Apple Distribution

Info.plist: icra zamanı konfiqurasiya

Build Config parametrlərinin bir hissəsi Info.plist-ə daxil olur — iOS tətbiqinin manifest faylı. Info.plist vasitəsilə URL sxemləri, icazələr (kamera, mikrofon), arxa plan rejimləri və üçüncü tərəf xidmətləri vasitəsilə giriş konfiqurasiyası qurulur.

xcconfig-dən alınan dəyərləri $(VARIABLE_NAME) sintaksisi vasitəsilə Info.plist-ə əvəz etmək olar. Məsələn, Info.plist-dəki $(API_BASE_URL) aktiv yığım konfiqurasiyasına uyğun açılır. Bu, bütün Apple platformaları üçün mühit parametrlərinin idarə olunmasını mərkəzləşdirir.

CI/CD paylaylarında Build Config

Müasir layihələrdə Build Config fasiləsiz inteqrasiya sistemləri ilə inteqrasiya olunur: GitLab CI, GitHub Actions, Bitrise, CircleCI. Hər paylay CI/CD sisteminin mühit dəyişənləri vasitəsilə Build Config parametrlərini əvəz edə bilər.

CI-da Gradle Build Config

Android üçün CI paylayı Build Variant göstərilməklə Gradle-i işə salır: ./gradlew assembleFullRelease. İmzalama parametrləri CI dəyişənləri vasitəsilə ötürülür: STORE_PASSWORD, KEY_ALIAS. Gradle onları icra mühitindən oxuyur və build.gradle.kts-ə əvəz edir.

// build.gradle.kts — CI dəyişənlərindən oxunma
android {
    signingConfigs {
        register("release") {
            storeFile = file(System.getenv("KEYSTORE_PATH") ?: "debug.keystore")
            storePassword = System.getenv("STORE_PASSWORD") ?: ""
            keyAlias = System.getenv("KEY_ALIAS") ?: "key"
            keyPassword = System.getenv("KEY_PASSWORD") ?: ""
        }
    }
}

CI-da Xcode Build Config

iOS üçün CI konfiqurasiya flaqları ilə xcodebuild istifadə edir: -configuration Release. İmzalama sertifikatları CI secrets vasitəsilə, profillər isə Apple Developer Portal API və ya Fastlane match vasitəsilə çatdırılır.

Fastlane aləti Build Config idarəetməsini avtomatlaşdırır: xcconfig yaradır, Info.plist-də versiyaları yeniləyir, yığılmış IPA-ları imzalayır və App Store Connect-ə yükləyir. Fastlane gym (yığım) və match (imzalama) — iOS CI paylaylarının standartıdır.

Bitrise Build Report (2025) məlumatına görə, CI-da Build Config qurulmuş layihələr əl ilə yığım qurulması vaxtını 73% azaldır və imzalama xətalarının sayını 89% aşağı salır. Avtomatlaşdırılmış Build Config production-ready paylayının məcburi elementidir.

Digər vacib aspekt — Build Config vasitəsilə versiyalama parametrləşdirilməsidir. Gradle versionCode və versionName-i CI dəyişənlərindən oxuyub onları build.gradle.kts-ə dinamik əvəz etməyə imkan verir, bu da proqramçılar arasında versiya uyğunsuzluğunu aradan qaldırır. iOS-da oxşar vəzifə agvtool (Apple Generic Versioning Tool) vasitəsilə həll olunur, o, git teqləri və ya CI-də build nömrəsi əsasında yığım nömrəsini artıra bilir.