Build Server v mobilním vývoji — co to je, úkoly a princip fungování

Co je Build Server

Build Server (kompilační server) — je specializovaný výpočetní systém určený pro automatické provádění úkolů souvisejících s kompilací kódu a přípravou vydání. Na rozdíl od lokální kompilace na počítači vývojáře, server pracuje s kopií repozitáře, používá čisté prostředí a pevné verze závislostí.

Build server je klíčovou součástí praktiky Continuous Integration. Zaručuje, že každý commit prochází stejným ověřovacím procesem bez ohledu na to, kdo jej provedl. To odstraňuje problém „funguje na mém počítači” a zajišťuje jednotný standard kvality.

Podle údajů Google DORA, 2025, týmy používající vyhrazený build server zkracují čas potvrzení změn z hodin na minuty. To přímo ovlivňuje rychlost doručování funkcí a oprav koncovým uživatelům.

Proč je build server potřebný v mobilním vývoji

Kompilace mobilních aplikací vyžaduje významné prostředky: kompilace Kotlin nebo Swift může trvat 5 až 40 minut. Pokud je kompilace spuštěna na lokálním počítači vývojáře, nemůže produktivně pracovat, dokud není dokončena. Build server tento problém řeší tím, že uvolňuje vývojáře pro jiné úkoly.

Rozdíl mezi build serverem a CI serverem

V praxi jsou termíny často používány jako synonyma, ale je tu rozdíl: CI server (Jenkins, CircleCI) — je systém, který spravuje pipeliny, zatímco build server — je fyzický nebo virtuální hostitel, na kterém jsou tyto pipeliny prováděny. Jeden CI server může spravovat mnoho build agentů (build slaves).

Architektura build serveru

Typický build server se skládá z několika komponent, z nichž každá je zodpovědná za určitou fázi procesu. Porozumění architektuře pomáhá správně škálovat infrastrukturu pod zátěží týmu.

Hlavní komponenty

Jádro (executor) — spouští úkoly sestavení. Může pracovat jako Docker kontejnery, virtuální stroje nebo přímo na hostiteli. Fronta úkolů spravuje priority paralelních sestavení. Úložiště artefaktů uchovává výsledky (APK, IPA, AAB) pro následnou publikaci.

Síť build agentů (build farm)

Pro urychlení práce může build server spravovat fond agentů. Každý agent — je samostatný stroj nebo kontejner schopný provést sestavení. Při růstu zátěže přidává automatické škálování (auto-scaling) nové agenty v cloudu. Například Jenkins s pluginem Kubernetes může dynamicky vytvářet pody pro každé sestavení.

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

Typy build serverů

Build servery se dělí do několika kategorií podle způsobu umístění a cílového technologického stacku. Výběr konkrétního řešení závisí na velikosti týmu, rozpočtu a bezpečnostních požadavcích.

Self-hosted build servery

Jenkins, TeamCity, Bamboo, GitLab Runner (self-hosted) — instalují se na vlastní servery nebo VPS. Výhody: úplná kontrola nad konfigurací, možnost použít libovolný software, data neopouštějí infrastrukturu společnosti. Nevýhody: náklady na správu, aktualizace a škálování.

Spravovaná cloudová řešení

GitHub Actions, CircleCI, Bitrise, Codemagic, GitLab SaaS — nevyžadují správu serverů. Platba probíhá za minuty sestavení nebo prostřednictvím předplatného. Pro malé týmy je to optimální začátek. Pro velké projekty s vysokým objemem sestavení mohou náklady přesáhnout cenu self-hosted řešení.

Build servery pro vývoj iOS

Specifikem iOS je, že kompilace je možná pouze na macOS. Možnosti: Mac mini v racku, MacStadium (pronájem Macu), GitHub Actions s macOS runnerem, Bitrise s vlastními Mac agenty. Self-hosted Mac build server vyžaduje nákup drahého zařízení a jeho údržbu.

Jak nastavit build server

Podíváme se na krok za krokem nastavení build serveru pro mobilní projekt s Android a iOS sestaveními. Jako základ použijeme GitHub Actions s self-hosted runnerem pro iOS a cloudovým runnerem pro Android.

Krok 1: Instalace a konfigurace CI serveru

Vyberte platformu pro správu (Jenkins, GitLab, GitHub Actions). Nainstalujte master uzel, nakonfigurujte přístup k repozitáři přes SSH nebo personal access token. Nakonfigurujte webhook pro automatické spuštění sestavení při push oznámeních do repozitáře.

Krok 2: Přidání build agentů

Zaregistrujte jeden nebo více strojů jako agenty (slaves/runners). Pro Android sestavení může agent pracovat na Linuxu nebo Windows s nainstalovaným JDK, Android SDK, Gradle. Pro iOS — na macOS s Xcode Command Line Tools a CocoaPods.

Krok 3: Konfigurace pipeline

Definujte fáze: checkout, instalace závislostí, kompilace, testování, publikace artefaktu. Pro urychlení použijte caching závislostí (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

Porovnání nákladů na build servery

Volba mezi self-hosted a cloudovým build serverem není jen technické, ale také finanční rozhodnutí. Náklady se výrazně liší v závislosti na objemu sestavení, požadované době provádění a potřebě macOS pro iOS.

CAPEX vs OPEX

Self-hosted server vyžaduje kapitálové výdaje (CAPEX): nákup zařízení (Mac mini od $699, serverové racky, síťové vybavení), konfiguraci a údržbu. Cloudová řešení — provozní náklady (OPEX): platba za minuty sestavení. Pro malé týmy je OPEX výhodnější, pro velké projekty se stovkami sestavení denně se CAPEX vrátí za 6–12 měsíců.

Skryté náklady

Při výpočtu rozpočtu zohledněte skryté náklady: čas na aktualizaci softwaru, odstraňování poruch, zálohování konfigurací, síťové úložiště artefaktů. U self-hosted řešení přidejte 20–30% k základním nákladům na údržbu. U cloudových — ujistěte se, že limit minut pokrývá špičkové zatížení, zejména před vydáními.

Optimalizace nákladů

Snížit náklady na build server lze několika způsoby: použitím spot instancí v cloudu (až o 70% levnější), cachováním závislostí mezi sestaveními, omezením doby provádění neúspěšných pipelin a nastavením automatického vypínání neaktivních self-hosted agentů mimo pracovní dobu.

Nejlepší postupy pro build servery

Efektivní práce build serveru vyžaduje dodržování řady zásad. Optimalizace rychlosti sestavení a stabilita infrastruktury přímo ovlivňují produktivitu vývojového týmu.

Cachování a inkrementální sestavení

Gradle Build Cache, CCache pro C/C++, inkrementální kompilátor pro Kotlin a Swift — zapněte všechny dostupné mechanismy cachování. Nakonfigurujte vzdálený cache sestavení (přes HTTP nebo S3), aby různí vývojáři a agenti sdíleli výsledky kompilace.

Izolace prostředí

Každé sestavení by mělo být spuštěno v čistém prostředí. Použijte Docker kontejnery nebo dočasné virtuální stroje, abyste vyloučili vliv předchozích sestavení na aktuální. To odstraňuje problém „špinavého stavu“ (state pollution).

• Použijte Docker pro kontejnerizaci prostředí sestavení — to zaručuje opakovatelnost sestavení
• Nastavte monitorování build serveru — CPU, paměť, disk, čas sestavení, četnost chyb
• Automatizujte čištění starých artefaktů, aby nezabíraly místo na disku

Bezpečnost build serveru

Build server má přístup ke zdrojovým kódům, podepisovacím klíčům a tajemstvím. Minimalizujte útočnou plochu: používejte izolované agenty pro různé projekty, omezte přístup k master uzlu, používejte signed commity a kontrolujte závislosti na zranitelnosti.