GitLab CI: essentie, pipelines en continue integratie

Wat is GitLab CI?

GitLab CI maakt deel uit van de uniforme DevSecOps-applicatie GitLab, die continue integratie, levering en implementatie omvat. Het systeem verscheen in 2012 als een afzonderlijk project, maar werd vervolgens direct in GitLab geïntegreerd. Het basisprincipe is configuratie als code (Configuration as Code) via het .gitlab-ci.yml-bestand in de root van de repository. GitLab CI is zowel beschikbaar in de cloud SaaS-versie als in een self-managed installatie.

Voor mobiele ontwikkeling biedt GitLab CI automatisering van het bouwen van APK en IPA, het uitvoeren van instrumentele tests, statische code-analyse, het ondertekenen van apps en publicatie in winkels. Het platform ondersteunt Docker-images voor aangepaste omgevingen, waardoor Android SDK, NDK, Xcode en andere tools vooraf kunnen worden geïnstalleerd. De ingebouwde Container Registry vereenvoudigt het opslaan en distribueren van images binnen het team.

GitLab CI-architectuur: Runners, Pipelines en Stages

De GitLab CI-architectuur bestaat uit drie belangrijke componenten. GitLab Runner is de agent die jobs uitvoert. Runners kunnen shared (geleverd door GitLab), group (voor een groep projecten) en specific (voor één project) zijn. Elke runner registreert zich met opgave van executor: Shell, Docker, Kubernetes of VirtualBox. GitLab Runner ondersteunt auto-schalen voor het verwerken van piekbelastingen.

Een pipeline is een verzameling stages die sequentieel worden uitgevoerd. Binnen één stage worden jobs parallel uitgevoerd. Typische structuur voor een mobiel project: build → test → deploy. Als een job op stage test met een fout eindigt, wordt deploy niet gestart. Handmatige start (when: manual) kan worden geconfigureerd voor implementatie. Ook worden triggers voor multi-project pipelines ondersteund voor complexe CI/CD-scenario’s tussen repositories.

GitLab Runner Executors

Docker executor is de populairste voor CI/CD van mobiele applicaties. Elke job wordt gestart in een schone Docker-container, wat isolatie en reproduceerbaarheid garandeert. Voor Android-builds wordt de image android-sdk met vooraf geïnstalleerde SDK gebruikt, voor iOS — een macOS runner met Shell executor.

.gitlab-ci.yml-configuratie voor mobiele projecten

Het .gitlab-ci.yml-bestand definieert de pipeline in YAML-formaat. Belangrijkste secties: image (Docker-image), stages (lijst van fasen), variables (omgevingsvariabelen), before_script (commando’s voor elke job) en de jobs zelf met secties script, artifacts, cache. GitLab CI ondersteunt include — het koppelen van externe YAML-bestanden voor hergebruik van gedeelde configuraties tussen projecten.

Variables in GitLab CI kunnen op meerdere niveaus worden ingesteld: globaal in de UI, in het configuratiebestand, in groep- en projectinstellingen. Prioriteit van variabelen wordt bepaald door de hiërarchie: trigger variables hebben de hoogste prioriteit, daarna CI/CD variables uit de UI, dan uit .gitlab-ci.yml. Variabelen kunnen worden beveiligd (protected), waardoor ze alleen toegankelijk zijn voor beveiligde branches en tags.

Basisvariabelen en image

image: openjdk:17-jdk-slim

variables:
  ANDROID_SDK_VERSION: "35"
  GRADLE_OPTS: "-Dorg.gradle.daemon=false"

stages:
  - build
  - test
  - deploy

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/

Build-job met artefacten

De job generate-apk bouwt het Gradle-project en slaat APK op als artefact. Artefacten worden doorgegeven tussen stages — de deploy-job kan APK uit build gebruiken. De bewaartermijn van artefacten wordt geconfigureerd via expire_in.

generate-apk:
  stage: build
  script:
    - ./gradlew assembleRelease
  artifacts:
    paths:
      - app/build/outputs/apk/release/
    expire_in: 1 day

GitLab CI vs GitHub Actions: belangrijkste verschillen

Bij het kiezen tussen GitLab CI en GitHub Actions voor een mobiel project is het belangrijk rekening te houden met de infrastructuur van het team. GitLab CI biedt een ingebouwde Container Registry die kan worden gebruikt voor het opslaan van Docker-images met Android SDK. GitHub Actions vertrouwt op GitHub Packages of externe registries. GitLab heeft ook ingebouwde SAST (Static Application Security Testing) voor code-analyse op kwetsbaarheden.

GitLab CI biedt een flexibeler model voor runners — ondersteunt Kubernetes executor, auto-schalen en aangepaste images. GitHub Actions wint in integratie met het GitHub-ecosysteem en de actions-marktplaats. GitLab CI vereist handmatige configuratie voor veel taken die in GitHub Actions met een kant-en-klare action worden opgelost.

Vanuit CI/CD-perspectief voor mobiele projecten: GitLab CI is geschikter voor bedrijven die al GitLab Self-Managed gebruiken en self-hosted runners met Docker/Kubernetes nodig hebben. GitHub Actions is handiger voor kleine teams op cloud-GitHub die kant-en-klare actions en eenvoudige configuratie waarderen.

Vergelijking van mogelijkheden

Voorbeeld van een pipeline voor een Android-project

De volledige pipeline voor Android omvat: lint, unittesten, bouwen en implementeren in Firebase App Distribution. De pipeline gebruikt een Docker-image met Android SDK, Gradle-caching en parallelle uitvoering van lint en tests in één stage. Deze aanpak verkort de totale pipelinetijd, omdat lint- en testtaken niet van elkaar afhankelijk zijn.

Voor iOS-projecten verschilt de pipelinestructuur vanwege de noodzaak van een macOS runner en code-ondertekening. Een typische iOS-pipeline omvat: installatie van CocoaPods of SPM, uitvoeren van tests op de simulator, archiveren van het Xcode-project, exporteren van IPA en uploaden naar TestFlight. GitLab CI voor iOS gebruikt macOS runners — of GitLab SaaS macOS runners met tijdsbeperkingen, of een self-hosted runner op Mac mini of MacStadium.

image: androidsdk/android-35:latest

stages:
  - lint
  - test
  - build
  - deploy

lint-check:
  stage: lint
  script: ./gradlew lint

unit-tests:
  stage: test
  script: ./gradlew test

assemble-release:
  stage: build
  script: ./gradlew assembleRelease
  artifacts:
    paths: [app/build/outputs/apk/release/]

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute
    --app $FIREBASE_APP_ID
    --token $FIREBASE_TOKEN
    --groups testers

Optimalisatie van de bouwtijd in GitLab CI

Optimalisatie van mobiele build-pipelines in GitLab CI vereist aandacht voor detail. Correcte configuratie van cache en artifacts kan de bouwtijd meerdere keren verkorten. Voor prestatieanalyse biedt GitLab CI/CD Analytics — een dashboard met metrieken over pipelineduur, runnerbelasting en knelpunten. Analyseer deze metrieken regelmatig om optimalisatiemogelijkheden te vinden. De instelling resource_group blokkeert parallelle uitvoering van één pipeline — dit is handig om conflicten tijdens implementatie te voorkomen.

De branchstrategie voor CI is ook belangrijk. Het wordt aanbevolen de volledige pipeline alleen voor main- en release-branches te draaien, en voor feature-branches alleen lint en unittesten. Dit bespaart minuten van runners en versnelt feedback voor ontwikkelaars. GitLab CI ondersteunt workflow:rules — voorwaardelijke regels voor het in- of uitschakelen van jobs op basis van branch, gewijzigde bestanden of omgevingsvariabelen.

Caching van afhankelijkheden is de belangrijkste manier van versnellen. GitLab CI cacht .gradle, Pods en node_modules tussen uitvoeringen. De cachesleutel bevat $CI_COMMIT_REF_SLUG of de hash van het lock-bestand. De bouwtijd van een Android-project wordt met correcte caching teruggebracht van 10–15 naar 2–4 minuten. Cache kan gedistribueerd zijn — GitLab ondersteunt cache:key met fallback naar vorige sleutels.

Een Docker-image met vooraf geïnstalleerde tools bespaart installatietijd. Het wordt aanbevolen een aangepaste image te maken met Android SDK, NDK en het benodigde API-niveau. Parallelle uitvoering van jobs (lint, test, assemble) in verschillende stages verkort de totale pipelinetijd. Pull policies voor images (if-not-present) versnellen het starten van jobs. Ook kan dependency proxy worden gebruikt voor het cachen van images op GitLab-instantieniveau.

Een ander belangrijk aspect van optimalisatie is het gebruik van artefacten tussen fasen. Zware bestanden APK en IPA kunnen beter via dependency worden doorgegeven dan opnieuw worden gebouwd in elke job. Voor grote projecten met tientallen modules wordt aanbevolen Gradle Build Cache op pipelineniveau in te schakelen en remote cache op een gedeelde opslag te configureren. Timeout voor elke job moet worden ingesteld op basis van de verwachte bouwtijd — dit voorkomt vastgelopen processen.

Voorbeeld met caching en pull policy

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/
    - app/build/

image:
  name: registry.example.com/android-builder:3.5
  pull_policy: if-not-present