Continuous Integration (CI) — wat is het, principes en automatisering instellen

Wat is Continuous Integration

Continuous Integration (CI) — is een ontwikkelmethodologie die het proces van code-integratie van meerdere deelnemers in één codebase automatiseert. De term werd begin 2000 geïntroduceerd door Martin Fowler als een reeks praktijken die de „integratiehel” voorkomen — een situatie waarin ontwikkelaars wekenlang geïsoleerd werken en bij het samenvoegen van wijzigingen talloze conflicten ontstaan die dagen van handmatig oplossen vereisen.

Het probleem dat CI oplost

Zonder CI voltooit een ontwikkelaar een functie, probeert zijn wijzigingen samen te voegen met de main-branch en ontdekt dat collega's dezelfde bestanden hebben gewijzigd. Het oplossen van conflicten duurt uren en breekt vaak werkende code. CI lost dit probleem op door meerdere keren per dag geforceerde integratie: hoe vaker integratie plaatsvindt, hoe minder conflicten en hoe eenvoudiger het oplossen ervan. De praktijk leert dat bij dagelijkse integratie het oplossen van een conflict minuten duurt, bij wekelijkse integratie — uren.

Economisch effect van CI

Volgens IBM Systems Sciences Institute bedragen de kosten van het oplossen van een bug in de schrijffase $25, in de testfase — $100, in de productiefase — $2 500. CI verschuift foutdetectie zo ver mogelijk naar links (shift left), waardoor fouten in de commitfase worden ontdekt, wanneer het oplossen ervan vrijwel gratis is. Teams met CI besteden gemiddeld 15% van hun tijd aan debuggen, tegenover 35% bij teams zonder CI.

Basisprincipes van Continuous Integration

Martin Fowler definieerde de belangrijkste CI-praktijken die relevant blijven ongeacht de technologiestack. Het naleven van deze principes garandeert dat CI voordelen oplevert en geen bureaucratische last wordt. Mobiele ontwikkeling stelt extra eisen, maar de kern blijft onveranderd.

Eén repository

Alle code van het project wordt opgeslagen in één repository met één versiebeheersysteem (Git). Eén bron van waarheid sluit de situatie uit waarin een functie in een fork wordt ontwikkeld en wekenlang niet wordt gesynchroniseerd met de hoofdcodebase. In mobiele projecten betekent dit dat Android-, iOS- en backend-onderdelen in één repository (monorepository) of in afzonderlijke repositories met een gemeenschappelijk versieschema kunnen worden ondergebracht.

Automatische build

De build van het project moet met één commando worden uitgevoerd. Voor Android is dat ./gradlew assembleDebug, voor iOS — xcodebuild of fastlane build. Het buildscript controleert de reproduceerbaarheid: de build op de CI-server moet hetzelfde resultaat geven als op de machine van de ontwikkelaar. Eventuele omgevingsverschillen worden geëlimineerd door containerisatie of IaC (Infrastructure as Code).

Automatische tests

Na de build worden alle testniveaus uitgevoerd: modulair, integratie en UI. Als tests falen — wordt de commit als ongeldig beschouwd. Het groene status behouden is de gezamenlijke verantwoordelijkheid van het team. In mobiele projecten worden vaak snelle tests (uitgevoerd tot 5 minuten per commit) en langzame tests (UI-tests op echte apparaten, minder vaak uitgevoerd) gescheiden.

// Voorbeeld van unittest met CI-friendly rapport
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 en transparantie

CI-resultaten zijn openbaar voor het hele team: iedereen ziet wiens commit de build heeft verbroken. Transparantie creëert een cultuur van verantwoordelijkheid: ontwikkelaars controleren hun wijzigingen vóór de push en repareren de kapotte build buiten de volgorde om. De CI-server stuurt meldingen naar Slack of Telegram bij wijziging van de buildstatus.

Componenten van een CI-systeem

Een volwaardig CI-systeem bestaat uit verschillende componenten die met elkaar samenwerken. Elke component is verantwoordelijk voor zijn deel van de pijplijn: van lancering tot rapportage. Inzicht in de CI-architectuur helpt bij het diagnosticeren van problemen en het optimaliseren van prestaties.

CI-server

De centrale component die de buildwachtrij, resourceverdeling en publicatie van resultaten beheert. De CI-server kan cloud-gebaseerd zijn (GitHub Actions, GitLab CI, CircleCI) of self-hosted (Jenkins, TeamCity). De server volgt wijzigingen in de repository via webhook of polling en start de pijplijn bij elke push of pull request.

Runners en agents

Runners zijn virtuele of fysieke machines die buildtaken uitvoeren. In cloud-CI's worden runners door de provider geleverd en betaald op basis van gebruikstijd. Self-hosted runners worden op eigen infrastructuur geïnstalleerd en vereisen onderhoud. Voor iOS-builds zijn macOS-runners nodig, voor Android — Linux of Windows.

Artefacten en cache

Na de build slaat het CI-systeem artefacten op (APK, IPA, testrapporten) in een opslag — ze zijn beschikbaar voor download en implementatie. Caching van afhankelijkheden (Gradle-cache, CocoaPods-cache) tussen runs versnelt volgende builds met 3–5 keer.

Continuous Integration voor mobiele applicaties

Mobiele ontwikkeling stelt bijzondere eisen aan CI, anders dan web- of backend-projecten. Lange buildtijd (3–15 minuten voor Android, 5–20 minuten voor iOS), meerdere artefacttypes (APK, AAB, IPA), de noodzaak van ondertekening en obfuscatie — dit alles vereist een individuele configuratie van de CI-pijplijn.

Android CI-pijplijn

Typische CI voor Android omvat: linting (ktlint, detekt) en statische analyse, unittests met JUnit en MockK, build van debug- en release-APK/AAB, instrumentatietests op een emulator binnen CI en publicatie van artefacten. De Gradle-cache versnelt herhaalde builds — zonder deze downloadt elke build de afhankelijkheden opnieuw, wat 3–5 minuten kost.

iOS CI-pijplijn

iOS CI vereist een macOS-runner voor compilatie van Swift/Objective-C-code. De pijplijn omvat: installatie van CocoaPods- of SPM-afhankelijkheden, SwiftLint voor stijlcontrole, unittests met XCTest, IPA-build, ondertekening met certificaten via Fastlane match en upload naar TestFlight. Een self-hosted runner op Mac mini of Mac in een datacenter — een alternatief voor cloud macOS-runners.

Cross-platform projecten (Flutter, React Native)

Flutter en React Native worden gecompileerd naar native builds voor beide platforms. CI moet twee runners ondersteunen: Linux voor Android-builds en macOS voor iOS-builds. De optimale strategie is een gesplitste pijplijn: Android-build op een Linux-runner, iOS-build op een macOS-runner, waarna beide artefacten worden samengevoegd tot één release.

Vergelijking van CI-tools

De keuze van CI-tool hangt af van de teamgrootte, vereiste prestaties, budget en technologiestack. Hieronder vindt u een vergelijking van populaire oplossingen met de nadruk op mobiele ontwikkeling. Self-hosted oplossingen bieden controle, maar vereisen beheer; cloud-oplossingen bieden gemak, maar beperken de configuratie.

GitHub Actions

Gratis voor openbare repositories (2000 minuten/maand). GitHub Actions biedt een ecosysteem van kant-en-klare actions voor Android (gradle/actions) en iOS (apple-actions). Nadeel — macOS-runners zijn alleen beschikbaar in betaalde abonnementen. Ideaal voor Open Source en kleine teams die al GitHub gebruiken.

Jenkins

Self-hosted CI-server met open source code. Jenkins wordt geconfigureerd via Groovy Pipeline, ondersteunt honderden plugins en werkt op elke hardware. Vereist een DevOps-ingenieur voor installatie en onderhoud. Populair in het enterprise-segment waar controle over infrastructuur cruciaal is.

GitLab CI

Ingebouwde CI/CD in GitLab met open runner-architectuur. GitLab CI maakt het mogelijk eigen runners (inclusief macOS) te gebruiken in het gratis abonnement. YAML-configuratie is krachtiger dan GitHub Actions, maar moeilijker te leren. Geschikt voor teams die GitLab gebruiken als één DevOps-platform.

CircleCI

Cloud CI met nadruk op snelheid. CircleCI ondersteunt Docker-, macOS- en Android-images, cachet automatisch afhankelijkheden. Prijsstelling op basis van credits — duurder dan GitHub Actions voor kleine teams, maar sneller dankzij geoptimaliseerde runners. Aanbevolen voor productieprojecten met snelheidseisen.

Voorbeeld van CI-configuratie

Laten we de configuratie van CI voor een Android-project met GitHub Actions bekijken. De pijplijn voert statische analyse, build en testen uit bij elke push en pull request naar de main-branch. Minimale configuratie duurt 15 minuten en vereist geen externe services.

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/

De pijplijn bestaat uit twee parallelle jobs: lint (voert statische analyse uit) en unit-tests (hangt af van lint — als linting niet is geslaagd, worden tests niet uitgevoerd). De unit-tests-job uploadt het testrapport als artefact — het team kan het bekijken in de GitHub Actions-interface zonder bestanden lokaal te downloaden.

Lokale controle vóór CI

Om CI-falen door triviale fouten te voorkomen, stelt u een pre-push hook in Git of een Gradle-taak in die dezelfde controles lokaal uitvoert. Bijvoorbeeld: ./gradlew ktlintCheck detekt testDebugUnitTest. Als lokale controles langer dan 3 minuten duren — splits ze op in snel (linter) en langzaam (tests), voer de snelle uit vóór elke commit en de langzame alleen vóór de push.