CI/CD Pipeline — wat is het, automatiseringsfasen en tools

Wat is CI/CD Pipeline

CI/CD Pipeline — is een geformaliseerde en geautomatiseerde set processen die code doorloopt van het moment van vastleggen van wijzigingen in de repository tot implementatie in productie. De term combineert twee praktijken: Continuous Integration (continue integratie) en Continuous Delivery (continue levering), die samen de pijplijn voor softwarelevering vormen.

Geschiedenis van CI/CD

Het concept van Continuous Integration werd in 1991 beschreven door Grady Booch en in de jaren 2000 gepopulariseerd door Martin Fowler. Continuous Delivery als term vestigde zich na het boek van Jez Humble en David Farley „Continuous Delivery” (2010). Moderne CI/CD Pipeline werd na 2015 de de facto standaard in mobiele ontwikkeling — met de opkomst van cloud CI-servers en automatisering van app-winkels.

Waarom is CI/CD Pipeline nodig in mobiele ontwikkeling

Mobiele apps hebben specifieke vereisten voor bouwen en publiceren: ondertekening met certificaten, meerdere configuraties (debug, release, staging), ProGuard/R8 obfuscatie, meerdere build-typen (APK, AAB, IPA) en integratie met app-winkels. Handmatig uitvoeren van deze stappen duurt uren en is foutgevoelig — CI/CD Pipeline automatiseert de routine.

Fasen van CI/CD Pipeline voor mobiele apps

Een standaard CI/CD Pipeline voor een Android- of iOS-app bestaat uit zeven belangrijke fasen. Sommige fasen worden parallel uitgevoerd, andere sequentieel. De exacte samenstelling van fasen hangt af van de technologiestack en de volwassenheid van het team, maar de kern blijft onveranderd.

1. Checkout en installatie van afhankelijkheden

De pijplijn begint met het klonen van de repository en het installeren van afhankelijkheden: Gradle/Maven voor Android, CocoaPods of SPM voor iOS. Cachen van afhankelijkheden tussen runs verkort de installatietijd van 3–5 minuten tot enkele seconden — deze optimalisatie wordt ondersteund door alle moderne CI-diensten.

2. Statische analyse en linting

Voor het bouwen wordt code gecontroleerd door linters (ktlint, detekt voor Android, SwiftLint voor iOS) en statische analyzers (Android Lint, SonarQube). Linting detecteert potentiële bugs, schendingen van codestijl en verouderde API’s voordat tests worden uitgevoerd — het fail-fast principe bespaart teamtijd.

3. Project bouwen

In de bouwfase wordt het hele project gecompileerd en worden artefacten gegenereerd: APK en AAB voor Android, IPA voor iOS. Voor Android worden Gradle-taken gebruikt (assembleDebug, bundleRelease), voor iOS — xcodebuild of xcrun. Het bouwen vindt plaats in de geïsoleerde omgeving van de CI-server, wat reproduceerbaarheid garandeert.

# Voorbeeld CI/CD Pipeline voor Android op 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. Automatisch testen

Na het bouwen worden unittesten, integratietesten en UI-tests uitgevoerd. JUnit en MockK voor modulaire tests, Espresso en Compose Test voor UI op Android, XCTest en XCUITest op iOS. Resultaten worden gepubliceerd in een rapport en blokkeren de pijplijn bij falen van kritieke tests.

5. Ondertekening en obfuscatie

Voor release-builds wordt ondertekening met een digitaal certificaat (APK Signer voor Android, codesign voor iOS) en code-obfuscatie uitgevoerd. ProGuard of R8 voor Android verkleint de APK-grootte met 15–30%. Ondertekeningssleutels worden opgeslagen in de geheimen van de CI-server — ze worden nooit in de repository gecommitteerd.

6. Levering en implementatie

De laatste fase van de pijplijn — publicatie van artefacten: uploaden van APK naar intern testen van Google Play Console, verzenden van IPA naar TestFlight of publicatie in Firebase Distribution. Continuous Delivery houdt in dat deze stap handmatige bevestiging vereist, terwijl Continuous Deployment automatisch wordt uitgevoerd.

7. Meldingen en rapporten

Na voltooiing van de pijplijn ontvangt het team een melding met resultaten: succes/falen, uitvoeringstijd, link naar artefacten. Slack, Telegram of e-mail — meldingskanalen worden gekozen op basis van de behoeften van het team. Bij falen van een fase wordt in de melding een link naar de specifieke foutlog opgenomen.

Wat is het verschil tussen CI en CD

De termen CI en CD worden vaak gebruikt als één concept CI/CD, maar er is een fundamenteel verschil tussen hen. CI (Continuous Integration) is verantwoordelijk voor kwaliteitscontrole bij elke code-integratie, terwijl CD (Continuous Delivery) de gereedheid van deze code voor release garandeert. Het begrijpen van het verschil is van cruciaal belang bij het ontwerpen van de pijplijn.

Continuous Integration — kwaliteitscontrole

CI wordt uitgevoerd bij elke push of pull request en omvat bouwen, statische analyse en testen. Doel van CI — problemen zo vroeg mogelijk detecteren, wanneer de kosten van het oplossen minimaal zijn. Als CI niet slaagt — komt de code niet in de hoofdtak. De gemiddelde uitvoeringstijd van CI voor een mobiel project is 5–15 minuten.

Continuous Delivery — gereedheid voor release

CD voegt aan CI de fasen van releasevoorbereiding toe: ondertekening, obfuscatie, maken van releasenotities, licenticontrole, publicatie in opslag voor testers. CD garandeert dat elke commit in de hoofdtak met één klik naar productie kan worden geïmplementeerd, maar de release zelf vereist handmatige goedkeuring.

Tools voor het bouwen van CI/CD Pipeline

Het ecosysteem van CI/CD-tools voor mobiele ontwikkeling omvat clouddiensten, self-hosted oplossingen en gespecialiseerde platforms. De keuze van de tool hangt af van de teamgrootte, het budget en de beveiligingseisen. Hieronder worden de populairste opties gepresenteerd.

GitHub Actions

Ingebouwde CI/CD in GitHub met een gratis limiet van 2000 minuten per maand voor openbare repositories. GitHub Actions is populair vanwege het enorme ecosysteem van kant-en-klare actions (marketplace), de eenvoud van configuratie via YAML en de naadloze integratie met de GitHub-repository. Beperking — geen ondersteuning voor Windows-runners voor iOS-builds in het gratis abonnement.

GitLab CI/CD

Self-hosted en cloud-oplossing met een krachtige YAML-configurator. GitLab CI ondersteunt parallelle jobs, caching, artefacten en omgevingen (environments). Populair in het enterprise-segment vanwege de mogelijkheid om op eigen infrastructuur te implementeren en volledige controle over gegevens.

Jenkins

Klassieke CI-server met open source. Jenkins wordt geconfigureerd via plugins (meer dan 1800), ondersteunt Declarative Pipeline in Groovy-formaat en werkt in elke omgeving: Windows, macOS, Linux. Vereist dedicated beheer, maar biedt maximale configuratie-flexibiliteit.

CircleCI

Cloud CI-service met nadruk op snelheid en eenvoud. CircleCI cached automatisch afhankelijkheden, ondersteunt Docker-images voor geïsoleerde builds en integratie met macOS voor iOS-builds. Prijsstelling is gebaseerd op het aantal credits — geschikt voor teams die prestaties waarderen.

Voorbeeld van CI/CD Pipeline configuratie

Laten we een volledige CI/CD Pipeline voor een iOS-app bekijken met GitHub Actions en Fastlane. Fastlane is een automatiseringstool voor mobiele projecten die complexe bouw-, ondertekenings- en publicatieoperaties abstraheert in eenvoudige commando’s.

# Fastfile — Fastlane-configuratie voor iOS CI/CD
default_platform(:ios)

platform :ios do
  desc "Tests en linting uitvoeren"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "Release bouwen en uploaden naar 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 beheert certificaten en provisioning profiles, build_app bouwt IPA, pilot uploadt de build naar TestFlight. Het commando fastlane release voert alle fasen sequentieel uit: haalt certificaten op, bouwt, ondertekent, uploadt naar App Store Connect voor bèta-testers.

CI/CD Pipeline voor iOS met GitHub Actions

Integratie van Fastlane met GitHub Actions maakt automatische uitvoering van de volledige pijplijn mogelijk bij een pull request naar de main-tak. Self-hosted runner op macOS is noodzakelijk voor het compileren van iOS-code — GitHub biedt geen macOS-runners in het gratis abonnement.

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 }}

Beste praktijken voor CI/CD Pipeline

Het bouwen van een effectieve CI/CD Pipeline vereist niet alleen de keuze van tools, maar ook het volgen van bewezen praktijken. Zonder goede organisatie kan de pijplijn een knelpunt worden dat de ontwikkeling vertraagt in plaats van versnelt. Hieronder — belangrijke aanbevelingen op basis van ervaring van volwassen mobiele teams.

Fail fast

De snelste controles (linting, unittesten) worden eerst uitgevoerd. Als ze falen — eindigt de pijplijn zonder lange UI-tests of release-bouw uit te voeren. Fail fast bespaart minuten CI-tijd en versnelt feedback naar de ontwikkelaar. De gemiddelde tijd tot de eerste fout mag niet meer dan 2–3 minuten bedragen.

Cachen van afhankelijkheden

Gradle-cache, CocoaPods-cache en SPM-cache moeten tussen runs worden hersteld. GitHub Actions ondersteunt caching via actions/cache, GitLab CI — via het cache-keyword. Zonder caching downloadt elke build alle afhankelijkheden opnieuw — dit voegt 3–10 minuten toe aan de pijplijntijd.

Parallelle uitvoering

Onafhankelijke fasen (linter voor Android en iOS, unittesten van verschillende modules) worden uitgevoerd als parallelle jobs. Parallelisatie verkort de totale pijplijntijd van 20–30 minuten tot 5–10 minuten. De meeste CI-diensten tellen parallelle jobs apart — houd hier rekening mee bij het kiezen van een tariefplan.

Omgevingsisolatie

Elke uitvoering van de pijplijn vindt plaats in een schone omgeving: Docker-container, virtuele machine of ephemeral runner. Isolatie voorkomt invloed van eerdere builds op de huidige build. Vermijd het gebruik van gedeelde runners tussen projecten — kruisprojectvervuiling van de omgeving leidt tot niet-deterministische storingen.

Beveiliging van geheimen

API-sleutels, ondertekeningscertificaten en toegangstokens tot app-winkels worden opgeslagen in de versleutelde opslag van de CI-server. Nooit geheimen opnemen in logs, artefacten of omgevingsvariabelen zonder voorvoegsel SECRET_. Gebruik tools zoals Fastlane match voor het beheren van iOS-certificaten.