Build Server mobil ishlanmada — bu nima, vazifalari va ishlash printsipi

Build Server nima

Build Server (kompilyatsiya serveri) — bu kodni kompilyatsiya qilish va relizlarni tayyorlash bilan bog‘liq vazifalarni avtomatik bajarish uchun mo‘ljallangan ixtisoslashtirilgan hisoblash tizimidir. Dasturchining lokal mashinasida kompilyatsiya qilishdan farqli o‘laroq, server repozitoriyning nusxasi bilan ishlaydi, toza muhit va barqaror bog‘liqlik versiyalaridan foydalanadi.

Build server Continuous Integration amaliyotining asosiy komponentidir. U har bir commit kim tomonidan qilinganidan qat‘i nazar, bir xil tekshirish jarayonidan o‘tishini kafolatlaydi. Bu “ mening mashinamda ishlaydi ” muammosini bartaraf etadi va yagona sifat standartini ta’minlaydi.

Google DORA, 2025 ma’lumotlariga ko‘ra, ajratilgan build serverdan foydalanadigan jamoalar o‘zgarishlarni tasdiqlash vaqtini soatlardan daqiqalargacha qisqartiradi. Bu oxirgi foydalanuvchilarga funksiyalar va tuzatishlarni yetkazib berish tezligiga bevosita ta’sir qiladi.

Mobil ishlanmada build server nima uchun kerak

Mobil ilovalarni kompilyatsiya qilish muhim resurslarni talab qiladi: Kotlin yoki Swift kompilyatsiyasi 5 dan 40 daqiqagacha davom etishi mumkin. Agar kompilyatsiyani dasturchining lokal mashinasida ishga tushirsangiz, u tugaguniga qadar samarali ishlay olmaydi. Build server bu muammoni hal qiladi, dasturchini boshqa vazifalar uchun bo‘shatadi.

Build server va CI server o‘rtasidagi farq

Amalda atamalar ko‘pincha sinonim sifatida ishlatiladi, ammo farq bor: CI server (Jenkins, CircleCI) — bu quvurlarni boshqaradigan tizim, build server esa — bu quvurlar bajariladigan fizik yoki virtual xostdir. Bitta CI server ko‘plab build agentlarini (build slaves) boshqarishi mumkin.

Build server arxitekturasi

Oddiy build server bir nechta komponentlardan iborat bo‘lib, ularning har biri jarayonning ma’lum bir bosqichi uchun javobgardir. Arxitekturani tushunish infratuzilmani jamoa yuklamasi ostida to‘g‘ri masshtablashga yordam beradi.

Asosiy komponentlar

Yadro (executor) — kompilyatsiya vazifalarini ishga tushiradi. Docker konteynerlari, virtual mashinalar yoki to‘g‘ridan-to‘g‘ri xostda ishlashi mumkin. Vazifalar navbati parallel kompilyatsiyalarning ustuvorliklarini boshqaradi. Artefakt ombori natijalarni (APK, IPA, AAB) keyingi nashr uchun saqlaydi.

Build agentlari tarmog‘i (build farm)

Ishni tezlashtirish uchun build server agentlar hovuzini boshqarishi mumkin. Har bir agent — kompilyatsiyani bajarishga qodir alohida mashina yoki konteyner. Yuklama oshganda, avtomatik masshtablash (auto-scaling) bulutda yangi agentlar qo‘shadi. Masalan, Jenkins Kubernetes plagini bilan har bir kompilyatsiya uchun dinamik podlar yaratishi mumkin.

pipeline {
    agent {
        kubernetes {
            yaml """
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: android-sdk
    image: openjdk:17-jdk
    command: ['sleep','infinity']
"""
        }
    }
    stages {
        stage('Build') {
            steps {
                sh './gradlew assembleDebug'
            }
        }
    }
}

Build server turlari

Build serverlar joylashtirish usuli va maqsadli texnologiya stekiga ko‘ra bir necha toifalarga bo‘linadi. Muayyan yechimni tanlash jamoa hajmi, byudjet va xavfsizlik talablariga bog‘liq.

Self-hosted build serverlar

Jenkins, TeamCity, Bamboo, GitLab Runner (self-hosted) — o‘z serverlarida yoki VPSda o‘rnatiladi. Afzalliklari: konfiguratsiya ustidan to‘liq nazorat, istalgan dasturiy ta’minotdan foydalanish imkoniyati, ma’lumotlar kompaniya infratuzilmasini tark etmaydi. Kamchiliklari: ma’muriyat, yangilash va masshtablash xarajatlari.

Bulutli boshqariladigan yechimlar

GitHub Actions, CircleCI, Bitrise, Codemagic, GitLab SaaS — serverlarni boshqarishni talab qilmaydi. To‘lov kompilyatsiya daqiqalari yoki obuna bo‘yicha olinadi. Kichik jamoalar uchun bu optimal boshlanishdir. Ko‘p kompilyatsiyali katta loyihalar uchun xarajatlar self-hosted yechim narxidan oshib ketishi mumkin.

iOS ishlanmasi uchun build serverlar

iOS ning o‘ziga xosligi shundaki, kompilyatsiya faqat macOS da mumkin. Variantlar: stenddagi Mac mini, MacStadium (Mac ijarasi), macOS runner bilan GitHub Actions, o‘z Mac agentlari bilan Bitrise. Self-hosted Mac build server qimmatbaho uskunani sotib olish va uni saqlashni talab qiladi.

Build server-ni qanday sozlash kerak

Android va iOS kompilyatsiyalari bilan mobil loyiha uchun build server-ni bosqichma-bosqich sozlashni ko‘rib chiqamiz. Asos sifatida iOS uchun self-hosted runner va Android uchun bulutli runner bilan GitHub Actions dan foydalanamiz.

1-qadam: CI serverini o‘rnatish va sozlash

Boshqaruv platformasini tanlang (Jenkins, GitLab, GitHub Actions). Master tugunni o‘rnating, SSH yoki personal access token orqali repozitoriyga kirishni sozlang. Repozitoriyga push bildirishnomalari bo‘yicha avtomatik kompilyatsiyani ishga tushirish uchun webhook sozlang.

2-qadam: Build agentlarini qo‘shish

Bir yoki bir nechta mashinani agent (slaves/runners) sifatida ro‘yxatdan o‘tkazing. Android kompilyatsiyalari uchun agent o‘rnatilgan JDK, Android SDK, Gradle bilan Linux yoki Windows da ishlashi mumkin. iOS uchun — Xcode Command Line Tools va CocoaPods bilan macOS da.

3-qadam: Quvurni sozlash

Bosqichlarni aniqlang: checkout, bog‘liqliklarni o‘rnatish, kompilyatsiya, test, artefaktni nashr qilish. Tezlashtirish uchun bog‘liqliklarni keshlashdan foydalaning (Gradle cache, CocoaPods cache, Docker image layers).

name: Android Build
on:
  push:
    branches: [main, develop]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'
      - name: Cache Gradle
        uses: actions/cache@v4
        with:
          path: ~/.gradle/caches
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*') }}
      - name: Build Release APK
        run: ./gradlew assembleRelease
      - name: Upload Artifact
        uses: actions/upload-artifact@v4
        with:
          name: app-release.apk
          path: app/build/outputs/apk/release/app-release.apk

Build serverlar narxini taqqoslash

Self-hosted va bulutli build server o‘rtasidagi tanlov nafaqat texnik, balki moliyaviy qarordir. Narx kompilyatsiyalar hajmi, talab qilinadigan bajarish vaqti va iOS uchun macOS zarurligiga qarab juda farq qiladi.

CAPEX vs OPEX

Self-hosted server kapital xarajatlarni (CAPEX) talab qiladi: uskuna sotib olish (Mac mini $699 dan, server stendlari, tarmoq uskunalari), sozlash va texnik xizmat ko‘rsatish. Bulutli yechimlar — operatsion xarajatlar (OPEX): kompilyatsiya daqiqalari uchun to‘lov. Kichik jamoalar uchun OPEX foydaliroq, kuniga yuzlab kompilyatsiyalari bo‘lgan katta loyihalar uchun CAPEX 6–12 oy ichida o‘zini oqlaydi.

Yashirin xarajatlar

Byudjetni hisoblashda yashirin xarajatlarni hisobga oling: dasturiy ta’minotni yangilash vaqti, nosozliklarni bartaraf etish, konfiguratsiyalarni zaxiralash, tarmoq artefaktlarini saqlash. Self-hosted yechimlar uchun asosiy texnik xizmat narxiga 20–30% qo‘shing. Bulutli yechimlar uchun — daqiqa limitining eng yuqori yuklamalarni, ayniqsa relizlardan oldin qoplashiga ishonch hosil qiling.

Xarajatlarni optimallashtirish

Build server xarajatlarini bir necha usul bilan kamaytirish mumkin: bulutda spot instanslardan foydalanish (70% gacha arzon), kompilyatsiyalar o‘rtasida bog‘liqliklarni keshlash, muvaffaqiyatsiz quvurlarning bajarilish vaqtini cheklash va ish vaqtidan tashqari faol bo‘lmagan self-hosted agentlarni avtomatik o‘chirishni sozlash.

Build serverlar uchun eng yaxshi amaliyotlar

Build serverning samarali ishlashi bir qator prinsiplarga rioya qilishni talab qiladi. Kompilyatsiya tezligini optimallashtirish va infratuzilma barqarorligi bevosita ishlab chiqish jamoasining unumdorligiga ta’sir qiladi.

Keshlash va inkremental kompilyatsiyalar

Gradle Build Cache, CCache C/C++ uchun, incremental compiler Kotlin va Swift uchun — barcha mavjud keshlash mexanizmlarini yoqing. Turli dasturchilar va agentlar kompilyatsiya natijalarini baham ko‘rishi uchun uzoqdagi kompilyatsiya keshlashni (HTTP yoki S3 orqali) sozlang.

Muhitlarni izolyatsiya qilish

Har bir kompilyatsiya toza muhitda ishga tushirilishi kerak. Oldingi kompilyatsiyalarning joriyga ta’sirini istisno qilish uchun Docker konteynerlaridan yoki vaqtinchalik virtual mashinalardan foydalaning. Bu “ iflos holat ” (state pollution) muammosini bartaraf etadi.

• Docker-dan foydalaning kompilyatsiya muhitlarini konteynerlashtirish uchun — bu kompilyatsiyalarning takrorlanuvchanligini kafolatlaydi
• Monitoring sozlang build server uchun — CPU, xotira, disk, kompilyatsiya vaqti, xatolar chastotasi
• Tozalashni avtomatlashtiring eski artefaktlarning disk maydonini to‘ldirmasligi uchun

Build server xavfsizligi

Build server manba kodlarga, imzo kalitlariga va sirlarga kirish huquqiga ega. Hujum yuzasini minimallashtiring: turli loyihalar uchun izolyatsiya qilingan agentlardan foydalaning, master tugunga kirishni cheklang, signed commits dan foydalaning va bog‘liqliklarni zaifliklar uchun tekshiring.