Build Pipeline v mobilním vývoji — podstata, fáze a nastavení

Co je Build Pipeline

Build Pipeline (potrubí sestavení) — je formalizovaná sekvence kroků, které se automaticky provádějí při každé změně kódu. Každý krok kontroluje určitý aspekt kvality: kompilovatelnost, správnost testů, absenci zranitelností, soulad s code style. Pokud některý krok skončí chybou, pipeline se zastaví.

Koncept pipeline pochází z výrobní linky — jako v továrně, kde každá stanice přidává hodnotu produktu. Ve vývoji softwaru každá fáze přidává jistotu, že kód je připraven k vydání. Moderní pipeline jsou definovány jako kód (Pipeline as Code) a ukládány do Git repozitáře společně s projektem.

Podle Continuous Delivery Foundation, 2025, zralý build pipeline zkracuje čas od commitu k vydání z týdnů na minuty. Toho je dosaženo plnou automatizací a paralelním prováděním nezávislých fází.

Pipeline as Code

Místo konfigurace přes webové rozhraní je moderní pipeline popsán v YAML nebo Groovy souborech. Jenkinsfile, `.gitlab-ci.yml`, `.github/workflows/build.yml` — příklady Pipeline as Code. Výhody: verzování, code review, reprodukovatelnost.

Deklarativní vs Scripted Pipeline

V Jenkins existují dvě syntaxe. Deklarativní — jednodušší, s jasnou strukturou stages/steps. Scripted — flexibilnější, založený na Groovy. Pro většinu projektů se doporučuje deklarativní přístup jako čitelnější a předvídatelnější.

Fáze typického pipeline

Typický build pipeline pro mobilní aplikaci zahrnuje několik klíčových fází. Každá fáze plní svou funkci a filtruje potenciální problémy v rané fázi.

Checkout a instalace závislostí

Pipeline začíná klonováním repozitáře. Poté jsou nainstalovány závislosti: balíčky Gradle/Maven, CocoaPods, SPM (Swift Package Manager), npm balíčky. Použití cache v této fázi urychluje následující sestavení o 50-70%.

Linting a statická analýza

Před kompilací jsou spuštěny nástroje pro kontrolu kvality kódu: Detekt nebo ktlint pro Kotlin, SwiftLint pro Swift, ESLint pro JavaScript. Kontrolují soulad s code style a nacházejí potenciální chyby na úrovni analýzy kódu.

Kompilace a unit testy

Kód je kompilován do binární podoby, paralelně jsou spouštěny unit testy. Pro Android je to `./gradlew testDebugUnitTest`, pro iOS — `xcodebuild test -scheme App -destination 'platform=iOS Simulator'`. Selhání testů okamžitě zastaví pipeline.

name: Mobile Build Pipeline
on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew detekt

  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew jacocoTestReport

  build-release:
    needs: [lint, unit-tests]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/app-release.apk

Integrační a UI testy

Po úspěšné kompilaci jsou provedeny testy vyžadující spuštění aplikace: Espresso pro Android, XCTest/XCUITest pro iOS, Detox pro React Native. V této fázi je artefakt nasazen na simulátor nebo skutečné zařízení prostřednictvím farm služeb (Firebase Test Lab, BrowserStack, Sauce Labs).

Konfigurace pipeline

Správná konfigurace pipeline určuje efektivitu celého CI/CD procesu. Konfigurace zahrnuje výběr triggerů, definici paralelních a sekvenčních fází, parametrizaci a integraci s externími službami.

Triggers pipeline

Hlavní triggery: push do repozitáře, pull request (zejména pro code review s automatickými kontrolami), vytvoření Git tagu (pro release sestavení), plán (nightly build). Pull request trigger — nejpraktičtější pro týmovou práci, protože odhaluje problémy před sloučením kódu.

Paralelní a sekvenční fáze

Nezávislé fáze (linting, testování na různých verzích OS) by měly být prováděny paralelně pro urychlení. Závislé — sekvenčně. Moderní CI systémy automaticky spravují paralelní úkoly, rozdělují je mezi dostupné agenty.

• Fail-fast — nastavte okamžité selhání při chybě v jakékoli paralelní větvi
• Matrix build — spuštění jednoho sestavení na několika konfiguracích (úroveň API, verze Xcode)
• Conditional stages — některé fáze se provádějí pouze pro určité větve (např. nasazení pouze z main)

Optimalizace Build Pipeline

Dlouhý pipeline zpomaluje vývojový cyklus a snižuje motivaci týmu. Optimalizace doby sestavení — jeden z hlavních úkolů DevOps inženýra při práci s build pipeline.

Kešování závislostí

Gradle Build Cache ukládá výsledky předchozích kompilací. Pokud se zdrojový kód modulu nezměnil, není znovu kompilován. Podobně funguje inkrementální kompilace v Swift a Kotlin. Velikost cache může dosahovat gigabajtů, ale úspora času je 30% až 70%.

Paralelní provádění testů

Unit testy lze spouštět na několika agentech současně, rozdělením testovacích tříd. Sharding — technika dělení testů do skupin (shardů). GitHub Actions podporuje `strategy.matrix`, Jenkins — Parallel Test Executor, Gradle — `--parallel --max-workers`.

Minimalizace vrstev pipeline

Každá další fáze přidává čas. Analyzujte pipeline pravidelně: které fáze lze sloučit? Například linting lze spustit paralelně s kompilací, ne před ní. Integrační testy — pouze pro pull request, ne pro každý commit.

pipeline {
    agent any
    options {
        timestamps()
        timeout(time: 30, unit: 'MINUTES')
    }
    stages {
        stage('Parallel Checks') {
            parallel {
                stage('Lint') {
                    steps { sh './gradlew detekt' }
                }
                stage('Unit Tests') {
                    steps { sh './gradlew test' }
                }
            }
        }
        stage('Build') {
            steps { sh './gradlew assembleRelease' }
        }
    }
}

Bezpečnost Build Pipeline

Build pipeline je kritickým prvkem dodavatelského řetězce softwaru a jeho bezpečnost nelze ignorovat. Kompromitace pipeline může vést k vložení škodlivého kódu do release artefaktu, což ovlivní všechny uživatele aplikace.

Útoky na dodavatelský řetězec na pipeline

Známé útoky: SolarWinds (2020), Codecov (2021), 3CX (2023) — všechny zneužívaly zranitelnosti v CI/CD pipeline. Společný vektor — útočník získá přístup k přihlašovacím údajům build serveru a upraví kód ve fázi sestavení. Výsledek — škodlivé vydání podepsané legitimním certifikátem.

Ochrana přihlašovacích údajů

Nikdy neukládejte podpisové klíče, API tokeny a hesla v repozitáři nebo proměnných prostředí CI systému v otevřené podobě. Používejte tajemství CI systému (GitHub Secrets, GitLab CI Variables), HashiCorp Vault, AWS Secrets Manager. Minimalizujte přístup k tajemstvím — každý pipeline by měl dostávat pouze klíče potřebné pro jeho konkrétní kroky.

Ověřování artefaktů pipeline

Každý artefakt vycházející z pipeline by měl být kryptograficky podepsán a obsahovat atestaci — osvědčení o původu (provenance). Nástroje: SLSA framework, in-toto attestation, cosign pro podepisování kontejnerů. Ověření podpisu by mělo být provedeno před nasazením do jakéhokoli prostředí.

name: Secure Build Pipeline
on: [push]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Scan dependencies
        run: ./gradlew dependencyCheckAnalyze
      - name: SAST scan
        run: ./gradlew detekt

  sign-attest:
    needs: security-scan
    runs-on: ubuntu-latest
    steps:
      - run: ./gradlew assembleRelease
      - name: Sign APK
        run: jarsigner -keystore ${{ secrets.KEYSTORE }} \
          app-release.apk ${{ secrets.KEY_ALIAS }}
      - name: Generate provenance
        uses: actions/attest-build-provenance@v1

Monitorování a ladění pipeline

Build pipeline — komplexní systém vyžadující neustálé monitorování. Bez metrik nelze určit, zda se pipeline zpomalil a která fáze se stala úzkým hrdlem.

Metriky pipeline

Sledujte: dobu průchodu (total pipeline duration), čas každé fáze, četnost selhání (build failure rate), dobu čekání ve frontě (queue time). Pro velký tým (>20 vývojářů) se doporučuje nastavit dashboard v Grafana nebo Datadog s agregovanými statistikami za týden/měsíc.

Alerting při selháních

Každé selhání pipeline vyžaduje reakci. Nastavte oznámení v messengerech (Slack, Telegram, Discord) s odkazem na log chyby a uvedením autora commitu. Pro kritická selhání — PagerDuty nebo Opsgenie s eskalací.

Lokální ladění pipeline

Nástroje jako Act (pro GitHub Actions) nebo Jenkins Pipeline Unit Test umožňují spustit pipeline lokálně bez commitu. To urychluje vývoj a ladění pipeline, zejména při přidávání nových fází nebo změně konfigurace.