Continuous Integration (CI) — mi ez, elvek és az automatizálás beállítása

Mi az a Continuous Integration

Continuous Integration (CI) — egy olyan fejlesztési módszertan, amely automatizálja a kód integrációjának folyamatát több résztvevőtől egyetlen kódbázisba. A kifejezést Martin Fowler vezette be a 2000-es évek elején olyan gyakorlatok gyűjteményeként, amelyek megakadályozzák az „integrációs poklot” — azt a helyzetet, amikor a fejlesztők hetekig elszigetelten dolgoznak, és a változtatások összevonásakor számos konfliktus keletkezik, amelyek napokig tartó manuális megoldást igényelnek.

A probléma, amit a CI megold

CI nélkül a fejlesztő befejez egy funkciót, megpróbálja összevonni a változtatásait a main ággal, és felfedezi, hogy a kollégák ugyanazokat a fájlokat módosították. A konfliktusok feloldása órákig tart, és gyakran elrontja a működő kódot. A CI megoldja ezt a problémát napi többszöri kötelező integrációval: minél gyakoribb az integráció, annál kevesebb a konfliktus és annál könnyebb a megoldásuk. A gyakorlat azt mutatja, hogy napi integráció esetén a konfliktus megoldása percekig tart, heti integráció esetén pedig órákig.

A CI gazdasági hatása

Az IBM Systems Sciences Institute szerint egy hiba javításának költsége a kódírás szakaszában 25 dollár, a tesztelés szakaszában 100 dollár, a termelési szakaszban 2500 dollár. A CI balra tolja a hibák felderítését (shift left), a commit szakaszában fedi fel a hibákat, amikor a javításuk gyakorlatilag ingyenes. A CI-vel rendelkező csapatok átlagosan idejük 15%-át töltik hibakereséssel, szemben a CI nélküli csapatok 35%-ával.

A Continuous Integration alapelvei

Martin Fowler meghatározta a CI kulcsfontosságú gyakorlatait, amelyek a technológiai veremtól függetlenül érvényesek maradnak. Ezen elvek betartása garantálja, hogy a CI előnyöket hoz, nem pedig bürokratikus teherré válik. A mobilfejlesztés további követelményeket támaszt, de a mag változatlan marad.

Egységes repository

A projekt összes kódja egyetlen repository-ban tárolódik egyetlen verziókezelő rendszerrel (Git). Az egyetlen igazságforrás kizárja azt a helyzetet, amikor egy funkció fork-ban fejlesztődik és hetekig nem szinkronizálódik a fő kódbázissal. Mobil projektekben ez azt jelenti, hogy az Android, iOS és backend részek lehetnek egy repository-ban (monorepository) vagy külön repository-kban közös verziózási sémával.

Automatikus build

A projekt build-jét egyetlen paranccsal kell végrehajtani. Android esetén ez ./gradlew assembleDebug, iOS esetén — xcodebuild vagy fastlane build. A build szkript ellenőrzi a reprodukálhatóságot: a CI-szerveren végzett build-nek ugyanazt az eredményt kell adnia, mint a fejlesztő gépén. Bármilyen környezeti különbséget konténerizációval vagy IaC-vel (Infrastructure as Code) szüntetünk meg.

Automatikus tesztek

A build után minden teszt szint lefut: modul-, integrációs és UI. Ha a tesztek meghiúsulnak — a commit érvénytelennek minősül. A zöld állapot fenntartása a csapat közös felelőssége. Mobil projektekben gyakran különválasztják a gyors teszteket (legfeljebb 5 perc minden commit-nál) és a lassú teszteket (UI tesztek valós eszközökön, ritkábban futnak).

// Példa egységtesztre CI-friendly jelentéssel
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 és átláthatóság

A CI eredményei nyilvánosak az egész csapat számára: mindenki látja, hogy ki commit-je törte el a build-et. Az átláthatóság felelősségi kultúrát teremt: a fejlesztők ellenőrzik változtatásaikat push előtt, és soron kívül javítják az eltört build-et. A CI-szerver értesítéseket küld Slackbe vagy Telegramba a build állapotának változásakor.

A CI-rendszer összetevői

Egy teljes CI-rendszer több egymással kölcsönhatásban lévő összetevőből áll. Minden összetevő a csővezeték saját részéért felel: az indítástól a jelentésig. A CI architektúrájának megértése segít a problémák diagnosztizálásában és a teljesítmény optimalizálásában.

CI-szerver

A központi összetevő, amely a build sorát, az erőforrás-elosztást és az eredmények publikálását kezeli. A CI-szerver lehet felhő alapú (GitHub Actions, GitLab CI, CircleCI) vagy self-hosted (Jenkins, TeamCity). A szerver webhook vagy polling segítségével követi a repository változásait, és minden push vagy pull request esetén elindítja a csővezetéket.

Runnerek és ágensek

A runnerek virtuális vagy fizikai gépek, amelyek a build feladatokat hajtják végre. Felhő CI-kben a runnereket a szolgáltató biztosítja, és használati idő alapján fizetjük őket. A self-hosted runnerek a saját infrastruktúránkon telepítendők és karbantartást igényelnek. iOS build-ekhez macOS runner szükséges, Androidhoz — Linux vagy Windows.

Artefaktumok és gyorsítótár

A build után a CI-rendszer elmenti az artefaktumokat (APK, IPA, tesztjelentések) a tárhelyre — letölthetők és telepíthetők. A függőségek gyorsítótárazása (Gradle cache, CocoaPods cache) a futtatások között 3–5-ször felgyorsítja a későbbi build-eket.

Continuous Integration mobilalkalmazásokhoz

A mobilfejlesztés különleges követelményeket támaszt a CI-vel szemben, amelyek eltérnek a webes vagy backend projektektől. Hosszú build (3–15 perc Android esetén, 5–20 perc iOS esetén), többféle artefaktum típus (APK, AAB, IPA), aláírás és obfuszkáció szükségessége — mindez a CI csővezeték egyedi beállítását igényli.

Android CI csővezeték

Tipikus CI Android esetén magában foglalja: linting (ktlint, detekt) és statikus elemzés, egységtesztek JUnit és MockK segítségével, debug és release APK/AAB build, instrumentációs tesztek emulátoron a CI-n belül és artefaktumok publikálása. A Gradle gyorsítótár felgyorsítja az ismételt build-eket — nélküle minden build újra letölti a függőségeket, 3–5 percet veszítve.

iOS CI csővezeték

Az iOS CI macOS runner igényel a Swift/Objective-C kód fordításához. A csővezeték magában foglalja: CocoaPods vagy SPM függőségek telepítése, SwiftLint a stílus ellenőrzéséhez, egységtesztek XCTest segítségével, IPA build, tanúsítványok aláírása Fastlane match segítségével és feltöltés TestFlight-ba. Self-hosted runner Mac mini-n vagy Mac-en egy adatközpontban — alternatíva a felhő macOS runnerekkel szemben.

Cross-platform projektek (Flutter, React Native)

A Flutter és React Native natív build-ekké fordulnak mindkét platformra. A CI-nek két runner kell támogatnia: Linux az Android build-hez és macOS az iOS build-hez. Az optimális stratégia — külön csővezeték: Android build Linux runner-en, iOS build macOS runner-en, majd mindkét artefaktum egyetlen release-be egyesül.

CI-eszközök összehasonlítása

A CI-eszköz kiválasztása a csapat méretétől, a szükséges teljesítménytől, a költségvetéstől és a technológiai veremtől függ. Az alábbiakban a népszerű megoldások összehasonlítása található a mobilfejlesztésre összpontosítva. A self-hosted megoldások irányítást adnak, de adminisztrációt igényelnek, a felhő alapúak — kényelmet, de korlátozzák a konfigurációt.

GitHub Actions

Ingyenes nyilvános repository-k számára (2000 perc/hó). GitHub Actions kész action-ök ökoszisztémáját kínálja Android (gradle/actions) és iOS (apple-actions) számára. Hátrány — a macOS runnerek csak fizetős csomagokban érhetők el. Ideális Open Source és kis csapatok számára, akik már használják a GitHub-ot.

Jenkins

Self-hosted CI-szerver nyílt forráskóddal. Jenkins Groovy Pipeline segítségével konfigurálható, több száz bővítményt támogat és bármilyen hardveren működik. DevOps mérnököt igényel a telepítéshez és karbantartáshoz. Népszerű az enterprise szegmensben, ahol az infrastruktúra feletti ellenőrzés kritikus.

GitLab CI

Beépített CI/CD a GitLab-ban nyílt runner architektúrával. GitLab CI lehetővé teszi saját runnerek (beleértve a macOS-t) használatát az ingyenes csomagban. A YAML konfiguráció erősebb, mint a GitHub Actions, de nehezebben tanulható. Alkalmas olyan csapatok számára, akik a GitLab-ot használják egyetlen DevOps platformként.

CircleCI

Felhő CI a sebességre összpontosítva. CircleCI támogatja a Docker, macOS és Android képeket, automatikusan gyorsítótárazza a függőségeket. Az árazás kredit alapú — drágább, mint a GitHub Actions kis csapatok számára, de gyorsabb az optimalizált runnereknek köszönhetően. Termelési projektekhez ajánlott sebességi követelményekkel.

CI beállítási példa

Tekintsük át a CI beállítását egy Android projekthez GitHub Actions használatával. A csővezeték statikus elemzést, build-et és tesztelést végez minden push és pull request esetén a main ágba. A minimális konfiguráció 15 percet vesz igénybe, és nem igényel külső szolgáltatásokat.

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/

A csővezeték két párhuzamos feladatból áll: lint (statikus elemzést végez) és unit-tests (függ a lint-től — ha a linting nem sikerült, a tesztek nem futnak). A unit-tests feladat feltölti a tesztjelentést artefaktumként — a csapat megtekintheti a GitHub Actions felületén anélkül, hogy helyileg letöltené a fájlokat.

Helyi ellenőrzés CI előtt

A CI triviális hibák miatti meghiúsulásának elkerülése érdekében állítson be egy pre-push hook-ot Git-ben vagy egy Gradle feladatot, amely ugyanazokat az ellenőrzéseket futtatja helyileg. Például: ./gradlew ktlintCheck detekt testDebugUnitTest. Ha a helyi ellenőrzések több mint 3 percig tartanak — ossza fel őket gyorsra (linter) és lassúra (tesztek), a gyorsakat minden commit előtt, a lassúakat csak push előtt futtassa.