Continuous Integration (CI) — co to je, principy a nastavení automatizace

Co je Continuous Integration

Continuous Integration (CI) — je metodologie vývoje, která automatizuje proces integrace kódu od více účastníků do jediné kódové základny. Termín zavedl Martin Fowler na začátku 21. století jako soubor praktik zabraňujících „integračnímu peklu“ — situaci, kdy vývojáři pracují izolovaně celé týdny a při slučování změn vzniká mnoho konfliktů vyžadujících dny ručního řešení.

Problém, který CI řeší

Bez CI vývojář dokončí funkci, pokusí se sloučit své změny s main větví a zjistí, že kolegové změnili stejné soubory. Řešení konfliktů trvá hodiny a často rozbije fungující kód. CI řeší tento problém vynucenou integrací několikrát denně: čím častější integrace, tím méně konfliktů a snadnější jejich řešení. Praxe ukazuje, že při denní integraci trvá řešení konfliktu minuty, při týdenní — hodiny.

Ekonomický efekt CI

Podle IBM Systems Sciences Institute stojí oprava chyby ve fázi psaní kódu 25 $, ve fázi testování 100 $, ve fázi produkce 2 500 $. CI posouvá detekci defektů co nejvíce doleva (shift left) a odhaluje chyby ve fázi commitu, kdy je jejich oprava prakticky zdarma. Týmy s CI tráví laděním v průměru 15 % času oproti 35 % u týmů bez CI.

Základní principy Continuous Integration

Martin Fowler definoval klíčové praktiky CI, které zůstávají aktuální bez ohledu na technologický stack. Dodržování těchto principů zaručuje, že CI přináší užitek, nikoli byrokratickou zátěž. Mobilní vývoj klade další požadavky, ale jádro zůstává nezměněno.

Jednotný repozitář

Veškerý kód projektu je uložen v jednom repozitáři s jednotným systémem správy verzí (Git). Jednotný zdroj pravdy vylučuje situaci, kdy je funkce vyvíjena ve forku a týdny se nesynchronizuje s hlavní kódovou základnou. V mobilních projektech to znamená, že Android, iOS a backendové části mohou být v jednom repozitáři (monorepozitář) nebo v samostatných repozitářích se společným schématem verzování.

Automatické sestavení

Sestavení projektu musí být provedeno jedním příkazem. Pro Android je to ./gradlew assembleDebug, pro iOS — xcodebuild nebo fastlane build. Skript sestavení kontroluje reprodukovatelnost: sestavení na CI serveru musí dávat stejný výsledek jako na počítači vývojáře. Případné rozdíly v prostředí se odstraňují kontejnerizací nebo IaC (Infrastructure as Code).

Automatické testy

Po sestavení se provádějí všechny úrovně testů: modulové, integrační a UI. Pokud testy selžou — commit je považován za neplatný. Udržování zeleného statusu je společnou odpovědností týmu. V mobilních projektech se často oddělují rychlé testy (prováděné do 5 minut na každý commit) a pomalé testy (UI testy na skutečných zařízeních, spouštěné méně často).

// Příklad unit testu s CI-friendly zprávou
class LoginViewModelTest {

    private val repository = mock<AuthRepository>()
    private val viewModel = LoginViewModel(repository)

    @Test
    fun loginWithValidCredentials_success() {
        val email = "test@example.com"
        val password = "ValidPass123"

        whenever(repository.login(email, password))
            .thenReturn(Result.success(User("token-xyz")))

        val result = viewModel.login(email, password)

        assertEquals(LoginState.Success, result)
        verify(repository).login(email, password)
    }
}

Fail fast a transparentnost

Výsledky CI jsou veřejné pro celý tým: každý vidí, čí commit rozbil sestavení. Transparentnost vytváří kulturu odpovědnosti: vývojáři kontrolují své změny před pushem a opravují rozbité sestavení mimo pořadí. CI server odesílá oznámení do Slacku nebo Telegramu při změně stavu sestavení.

Komponenty CI systému

Plnohodnotný CI systém se skládá z několika vzájemně spolupracujících komponent. Každá komponenta odpovídá za svou část pipeline: od spuštění po zprávu. Porozumění architektuře CI pomáhá diagnostikovat problémy a optimalizovat výkon.

CI server

Centrální komponenta spravující frontu sestavení, distribuci zdrojů a publikaci výsledků. CI server může být cloudový (GitHub Actions, GitLab CI, CircleCI) nebo self-hosted (Jenkins, TeamCity). Server sleduje změny v repozitáři pomocí webhooku nebo pollingu a spouští pipeline při každém pushi nebo pull requestu.

Runnery a agenti

Runnery jsou virtuální nebo fyzické stroje provádějící úlohy sestavení. V cloudových CI poskytuje runnery poskytovatel a platí se podle času použití. Self-hosted runnery se instalují na vlastní infrastrukturu a vyžadují údržbu. Pro iOS sestavení jsou potřeba macOS runnery, pro Android — Linux nebo Windows.

Artefakty a cache

Po sestavení CI systém ukládá artefakty (APK, IPA, zprávy o testech) do úložiště — jsou k dispozici ke stažení a nasazení. Kešování závislostí (Gradle cache, CocoaPods cache) mezi spuštěními urychluje následující sestavení 3–5krát.

Continuous Integration pro mobilní aplikace

Mobilní vývoj klade zvláštní požadavky na CI, odlišné od webových nebo backendových projektů. Dlouhé sestavení (3–15 minut pro Android, 5–20 minut pro iOS), několik typů artefaktů (APK, AAB, IPA), nutnost podepisování a obfuskace — to vše vyžaduje individuální nastavení CI pipeline.

Android CI pipeline

Typické CI pro Android zahrnuje: linting (ktlint, detekt) a statickou analýzu, unit testy s JUnit a MockK, sestavení debug a release APK/AAB, instrumentační testy na emulátoru uvnitř CI a publikaci artefaktů. Gradle cache urychluje opakovaná sestavení — bez ní každé sestavení stahuje závislosti znovu a ztrácí 3–5 minut.

iOS CI pipeline

iOS CI vyžaduje macOS runner pro kompilaci Swift/Objective-C kódu. Pipeline zahrnuje: instalaci závislostí CocoaPods nebo SPM, SwiftLint pro kontrolu stylu, unit testy s XCTest, sestavení IPA, podepisování certifikátů přes Fastlane match a nahrání do TestFlight. Self-hosted runner na Mac mini nebo Macu v datovém centru — alternativa ke cloudovým macOS runnerům.

Cross-platform projekty (Flutter, React Native)

Flutter a React Native se kompilují do nativních buildů pro obě platformy. CI musí podporovat dva runnery: Linux pro Android sestavení a macOS pro iOS sestavení. Optimální strategie — oddělená pipeline: Android sestavení na Linux runneru, iOS sestavení na macOS runneru, po čemž jsou oba artefakty sloučeny do jednoho release.

Srovnání CI nástrojů

Výběr CI nástroje závisí na velikosti týmu, požadovaném výkonu, rozpočtu a technologickém stacku. Níže je uvedeno srovnání populárních řešení s důrazem na mobilní vývoj. Self-hosted řešení poskytují kontrolu, ale vyžadují správu, cloudová — pohodlí, ale omezují konfiguraci.

GitHub Actions

Zdarma pro veřejné repozitáře (2000 minut/měsíc). GitHub Actions nabízí ekosystém hotových akcí pro Android (gradle/actions) a iOS (apple-actions). Nevýhoda — macOS runnery jsou dostupné pouze v placených tarifech. Ideální pro Open Source a malé týmy již používající GitHub.

Jenkins

Self-hosted CI server s otevřeným zdrojovým kódem. Jenkins se konfiguruje přes Groovy Pipeline, podporuje stovky pluginů a funguje na jakémkoli hardwaru. Vyžaduje DevOps inženýra pro instalaci a údržbu. Populární v enterprise segmentu, kde je kontrola nad infrastrukturou kritická.

GitLab CI

Vestavěné CI/CD v GitLabu s otevřenou runner architekturou. GitLab CI umožňuje používat vlastní runnery (včetně macOS) v bezplatném tarifu. Konfigurace YAML je výkonnější než GitHub Actions, ale hůře se učí. Vhodné pro týmy používající GitLab jako jedinou DevOps platformu.

CircleCI

Cloudové CI s důrazem na rychlost. CircleCI podporuje Docker, macOS a Android obrazy, automaticky kešuje závislosti. Ceny jsou na bázi kreditů — dražší než GitHub Actions pro malé týmy, ale rychlejší díky optimalizovaným runnerům. Doporučeno pro produkční projekty s požadavky na rychlost.

Příklad nastavení CI

Podívejme se na nastavení CI pro Android projekt pomocí GitHub Actions. Pipeline provádí statickou analýzu, sestavení a testování při každém pushi a pull requestu do main větve. Minimální konfigurace trvá 15 minut a nevyžaduje externí služby.

name: Android CI
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - run: ./gradlew ktlintCheck detekt

  unit-tests:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew testDebugUnitTest
      - uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: app/build/reports/tests/

Pipeline se skládá ze dvou paralelních jobů: lint (provádí statickou analýzu) a unit-tests (závisí na lintu — pokud linting neprošel, testy se nespouští). Job unit-tests nahrává zprávu o testech jako artefakt — tým ji může zobrazit v rozhraní GitHub Actions bez stahování souborů lokálně.

Lokální kontrola před CI

Aby se předešlo selhání CI kvůli triviálním chybám, nastavte pre-push hook v Gitu nebo Gradle úlohu spouštějící stejné kontroly lokálně. Například: ./gradlew ktlintCheck detekt testDebugUnitTest. Pokud lokální kontroly trvají déle než 3 minuty — rozdělte je na rychlé (linter) a pomalé (testy), rychlé spouštějte před každým commitem a pomalé pouze před pushem.