CI/CD Pipeline — co to je, fáze automatizace a nástroje

Co je CI/CD Pipeline

CI/CD Pipeline — je formalizovaný a automatizovaný soubor procesů, kterými kód prochází od okamžiku potvrzení změn v repozitáři až po nasazení do produkce. Termín spojuje dvě praktiky: Continuous Integration (průběžná integrace) a Continuous Delivery (průběžná dodávka), které dohromady tvoří potrubí dodávky softwaru.

Historie vzniku CI/CD

Koncepci Continuous Integration popsal Grady Booch v roce 1991 a zpopularizoval Martin Fowler v 2000. letech. Continuous Delivery jako termín se upevnil po knize Jeze Humbla a Davida Farleyho „Continuous Delivery“ (2010). Moderní CI/CD Pipeline se stal de facto standardem ve vývoji mobilních aplikací po roce 2015 — s nástupem cloudových CI serverů a automatizace obchodů s aplikacemi.

Proč je CI/CD Pipeline potřebný ve vývoji mobilních aplikací

Mobilní aplikace mají specifické požadavky na sestavení a publikování: podepisování certifikáty, více konfigurací (debug, release, staging), obfuskace ProGuard/R8, více typů buildů (APK, AAB, IPA) a integrace s obchody s aplikacemi. Ruční provádění těchto kroků trvá hodiny a je náchylné k chybám — CI/CD Pipeline automatizuje rutinu.

Fáze CI/CD Pipeline pro mobilní aplikace

Standardní CI/CD Pipeline pro aplikaci Android nebo iOS se skládá ze sedmi klíčových fází. Některé fáze se provádějí paralelně, jiné sekvenčně. Konkrétní složení fází závisí na technologickém stacku a vyspělosti týmu, ale jádro zůstává nezměněné.

1. Checkout a instalace závislostí

Potrubí začíná klonováním repozitáře a instalací závislostí: Gradle/Maven pro Android, CocoaPods nebo SPM pro iOS. Ukládání závislostí do mezipaměti mezi spuštěními zkracuje dobu instalace z 3–5 minut na několik sekund — tuto optimalizaci podporují všechny moderní CI služby.

2. Statická analýza a linting

Před sestavením je kód kontrolován lintery (ktlint, detekt pro Android, SwiftLint pro iOS) a statickými analyzátory (Android Lint, SonarQube). Linting odhaluje potenciální chyby, porušení stylu kódu a zastaralá API před spuštěním testů — princip fail-fast šetří čas týmu.

3. Sestavení projektu

Ve fázi sestavení je celý projekt zkompilován a jsou generovány artefakty: APK a AAB pro Android, IPA pro iOS. Pro Android se používají úkoly Gradle (assembleDebug, bundleRelease), pro iOS — xcodebuild nebo xcrun. Sestavení probíhá v izolovaném prostředí CI serveru, což zaručuje reprodukovatelnost.

# Příklad CI/CD Pipeline pro Android na GitHub Actions
name: Android CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew ktlintCheck detekt
      - run: ./gradlew assembleDebug
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/*.apk

4. Automatické testování

Po sestavení se spouštějí jednotkové testy, integrační testy a UI testy. JUnit a MockK pro modulární testy, Espresso a Compose Test pro UI na Androidu, XCTest a XCUITest na iOS. Výsledky jsou publikovány ve zprávě a blokují potrubí v případě selhání kritických testů.

5. Podepisování a obfuskace

Pro release buildy se provádí podepisování digitálním certifikátem (APK Signer pro Android, codesign pro iOS) a obfuskace kódu. ProGuard nebo R8 pro Android snižuje velikost APK o 15–30%. Klíče k podpisu jsou uloženy v tajemstvích CI serveru — nikdy nejsou commitovány do repozitáře.

6. Doručení a nasazení

Závěrečná fáze potrubí — publikování artefaktů: nahrání APK do interního testování Google Play Console, odeslání IPA do TestFlight nebo publikování ve Firebase Distribution. Continuous Delivery předpokládá, že tento krok vyžaduje ruční potvrzení, zatímco Continuous Deployment se provádí automaticky.

7. Oznámení a zprávy

Po dokončení potrubí obdrží tým oznámení s výsledky: úspěch/neúspěch, doba provádění, odkaz na artefakty. Slack, Telegram nebo email — kanály oznámení se vybírají podle potřeb týmu. Při selhání fáze je do oznámení zahrnut odkaz na konkrétní log chyby.

Čím se CI liší od CD

Termíny CI a CD jsou často používány jako jediný pojem CI/CD, ale je mezi nimi zásadní rozdíl. CI (Continuous Integration) odpovídá za kontrolu kvality při každé integraci kódu, zatímco CD (Continuous Delivery) zajišťuje připravenost tohoto kódu k vydání. Pochopení rozdílu je kriticky důležité při navrhování potrubí.

Continuous Integration — kontrola kvality

CI se provádí při každém push nebo pull request a zahrnuje sestavení, statickou analýzu a testování. Cíl CI — odhalit problémy co nejdříve, když jsou náklady na jejich opravu minimální. Pokud CI neprojde — kód se nedostane do hlavní větve. Průměrná doba provádění CI pro mobilní projekt je 5–15 minut.

Continuous Delivery — připravenost k vydání

CD přidává k CI fáze přípravy vydání: podepisování, obfuskaci, vytváření poznámek k vydání, kontrolu licencí, publikování do úložiště pro testery. CD zaručuje, že každý commit v hlavní větvi může být nasazen do produkce jediným kliknutím, ale samotné vydání vyžaduje ruční schválení.

Nástroje pro stavbu CI/CD Pipeline

Ekosystém CI/CD nástrojů pro vývoj mobilních aplikací zahrnuje cloudové služby, self-hosted řešení a specializované platformy. Výběr nástroje závisí na velikosti týmu, rozpočtu a bezpečnostních požadavcích. Níže jsou uvedeny nejoblíbenější možnosti.

GitHub Actions

Vestavěný CI/CD v GitHub s bezplatným limitem 2000 minut měsíčně pro veřejné repozitáře. GitHub Actions je oblíbený díky obrovskému ekosystému hotových actions (marketplace), jednoduchosti konfigurace přes YAML a bezproblémové integraci s repozitářem GitHub. Omezení — chybějící podpora Windows runnerů pro iOS buildy v bezplatném plánu.

GitLab CI/CD

Self-hosted a cloudové řešení s výkonným YAML konfigurátorem. GitLab CI podporuje paralelní joby, ukládání do mezipaměti, artefakty a prostředí (environments). Oblíbený v enterprise segmentu díky možnosti nasazení na vlastní infrastruktuře a plné kontrole nad daty.

Jenkins

Klasický CI server s otevřeným zdrojovým kódem. Jenkins se konfiguruje pomocí pluginů (přes 1800), podporuje Declarative Pipeline ve formátu Groovy a pracuje v jakémkoli prostředí: Windows, macOS, Linux. Vyžaduje vyhrazenou správu, ale poskytuje maximální flexibilitu konfigurace.

CircleCI

Cloudová CI služba s důrazem na rychlost a jednoduchost. CircleCI automaticky ukládá závislosti do mezipaměti, podporuje Docker obrazy pro izolované buildy a integraci s macOS pro iOS buildy. Ceny jsou založeny na počtu kreditů — vhodné pro týmy, které oceňují výkon.

Příklad konfigurace CI/CD Pipeline

Podívejme se na úplný CI/CD Pipeline pro iOS aplikaci pomocí GitHub Actions a Fastlane. Fastlane je automatizační nástroj pro mobilní projekty, který abstrahuje složité operace sestavení, podepisování a publikování do jednoduchých příkazů.

# Fastfile — konfigurace Fastlane pro iOS CI/CD
default_platform(:ios)

platform :ios do
  desc "Spuštění testů a lintingu"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "Sestavení releasu a nahrání do TestFlight"
  lane :release do
    match(type: "appstore")
    build_app(scheme: "MyApp", export_method: "app-store")
    pilot(skip_waiting_for_build: true)
  end
end

Fastlane match spravuje certifikáty a provisioning profiles, build_app sestavuje IPA, pilot nahrává build do TestFlight. Příkaz fastlane release provádí všechny fáze sekvenčně: získává certifikáty, sestavuje, podepisuje, nahrává do App Store Connect pro beta testery.

CI/CD Pipeline pro iOS s GitHub Actions

Integrace Fastlane s GitHub Actions umožňuje automatické spuštění úplného potrubí při pull request do hlavní větve. Self-hosted runner na macOS je nezbytný pro kompilaci iOS kódu — GitHub neposkytuje macOS runnery v bezplatném plánu.

name: iOS CI/CD Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  ci-checks:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.3
      - run: bundle install
      - run: bundle exec fastlane ci
      - if: github.ref == 'refs/heads/main'
        run: bundle exec fastlane release
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          FASTLANE_APPLE_ID: ${{ vars.APPLE_ID }}

Nejlepší postupy CI/CD Pipeline

Stavba efektivního CI/CD Pipeline vyžaduje nejen výběr nástrojů, ale také dodržování osvědčených postupů. Bez správné organizace se může potrubí stát úzkým místem, které zpomaluje vývoj místo aby ho zrychlovalo. Níže — klíčová doporučení založená na zkušenostech vyspělých mobilních týmů.

Fail fast

Nejrychlejší kontroly (linting, jednotkové testy) se provádějí jako první. Pokud selžou — potrubí končí bez spuštění dlouhých UI testů nebo sestavení vydání. Fail fast šetří minuty času CI a zrychluje zpětnou vazbu vývojáři. Průměrná doba do prvního selhání by neměla přesáhnout 2–3 minuty.

Ukládání závislostí do mezipaměti

Cache Gradle, cache CocoaPods a cache SPM by měly být obnovovány mezi spuštěními. GitHub Actions podporuje ukládání do mezipaměti pomocí actions/cache, GitLab CI — pomocí klíčového slova cache. Bez ukládání do mezipaměti každé sestavení stahuje všechny závislosti znovu — to přidává 3–10 minut k času potrubí.

Paralelní provádění

Nezávislé fáze (linter pro Android a iOS, jednotkové testy různých modulů) se spouštějí jako paralelní joby. Paralelizace zkracuje celkový čas potrubí z 20–30 minut na 5–10 minut. Většina CI služeb počítá paralelní joby zvlášť — zohledněte to při výběru tarifního plánu.

Izolace prostředí

Každé spuštění potrubí probíhá v čistém prostředí: Docker kontejneru, virtuálním stroji nebo dočasném runneru. Izolace zabraňuje ovlivnění aktuálního sestavení předchozími buildy. Vyhněte se používání sdílených runnerů mezi projekty — křížová kontaminace prostředí vede k nedeterministickým selháním.

Bezpečnost tajemství

API klíče, certifikáty pro podepisování a tokeny pro přístup k obchodům s aplikacemi jsou uloženy v šifrovaném úložišti CI serveru. Nikdy nezahrnujte tajemství do logů, artefaktů nebo proměnných prostředí bez předpony SECRET_. Používejte nástroje jako Fastlane match pro správu iOS certifikátů.