GitLab CI: Pipelines und kontinuierliche Integration

Was ist GitLab CI?

GitLab CI ist Teil der einheitlichen DevSecOps-GitLab-Anwendung, die kontinuierliche Integration, Bereitstellung und Deployment umfasst. Das System begann 2012 als separates Projekt, wurde aber später direkt in GitLab integriert. Das Grundprinzip ist die Konfiguration als Code über eine .gitlab-ci.yml-Datei im Repository-Stammverzeichnis. GitLab CI ist sowohl als Cloud-SaaS-Version als auch als selbstverwaltete Installation verfügbar.

Für die mobile Entwicklung bietet GitLab CI die Automatisierung von APK- und IPA-Builds, die Ausführung instrumentierter Tests, statische Codeanalyse, App-Signierung und Store-Veröffentlichung. Die Plattform unterstützt Docker-Images für benutzerdefinierte Umgebungen, was die Vorinstallation von Android SDK, NDK, Xcode und anderen Tools ermöglicht. Die integrierte Container Registry vereinfacht die Speicherung und Verteilung von Images innerhalb des Teams.

GitLab CI-Architektur: Runners, Pipelines und Stages

Die GitLab CI-Architektur besteht aus drei Schlüsselkomponenten. GitLab Runner ist ein Agent, der Jobs ausführt. Runner können gemeinsam genutzt (von GitLab bereitgestellt), Gruppe (für eine Gruppe von Projekten) oder spezifisch (für ein Projekt) sein. Jeder Runner wird mit einem Executor registriert: Shell, Docker, Kubernetes oder VirtualBox. GitLab Runner unterstützt automatische Skalierung zur Bewältigung von Spitzenlasten.

Eine Pipeline ist eine Sammlung von Stages, die sequenziell ausgeführt werden. Innerhalb einer Stage werden Jobs parallel ausgeführt. Eine typische Struktur für ein mobiles Projekt ist: Build → Test → Deploy. Wenn ein Job in der Test-Stage fehlschlägt, wird Deploy nicht ausgelöst. Für das Deployment kann ein manueller Trigger (when: manual) konfiguriert werden. Multi-Projekt-Pipeline-Trigger werden ebenfalls für komplexe CI/CD-Szenarien zwischen Repositories unterstützt.

GitLab Runner-Executors

Docker-Executor ist der beliebteste für CI/CD mobiler Anwendungen. Jeder Job wird in einem sauberen Docker-Container ausgeführt, was Isolation und Reproduzierbarkeit gewährleistet. Für Android-Builds wird das Image android-sdk mit vorinstalliertem SDK verwendet; für iOS ein macOS-Runner mit Shell-Executor.

.gitlab-ci.yml-Konfiguration für mobile Projekte

Die .gitlab-ci.yml-Datei definiert eine Pipeline im YAML-Format. Die Hauptabschnitte umfassen: Image (Docker-Image), Stages (Stufenliste), Variables (Umgebungsvariablen), before_script (Befehle vor jedem Job) und die Jobs mit den Abschnitten Script, Artifacts, Cache. GitLab CI unterstützt Include — das Einbinden externer YAML-Dateien zur Wiederverwendung gemeinsamer Konfigurationen zwischen Projekten.

Variablen in GitLab CI können auf mehreren Ebenen festgelegt werden: global in der Benutzeroberfläche, in der Konfigurationsdatei, in Gruppen- und Projekteinstellungen. Die Variablenpriorität folgt einer Hierarchie: Trigger-Variablen haben die höchste Priorität, gefolgt von CI/CD-Variablen aus der UI, dann aus der .gitlab-ci.yml. Variablen können geschützt werden, sodass sie nur für geschützte Branches und Tags zugänglich sind.

Basisvariablen und 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 mit Artefakten

Der Job generate-apk erstellt ein Gradle-Projekt und speichert die APK als Artefakt. Artefakte werden zwischen Stages übergeben — ein Deploy-Job kann die APK aus der Build-Stage verwenden. Die Aufbewahrungsdauer von Artefakten wird über expire_in konfiguriert.

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

GitLab CI vs GitHub Actions: Hauptunterschiede

Bei der Wahl zwischen GitLab CI und GitHub Actions für ein mobiles Projekt ist die Team-Infrastruktur ein entscheidender Faktor. GitLab CI bietet eine integrierte Container Registry zum Speichern von Docker-Images mit Android SDK. GitHub Actions ist auf GitHub Packages oder externe Registries angewiesen. GitLab verfügt außerdem über eine integrierte SAST (Static Application Security Testing) zur Analyse von Code-Schwachstellen.

GitLab CI bietet ein flexibleres Runner-Modell — es unterstützt Kubernetes-Executor, automatische Skalierung und benutzerdefinierte Images. GitHub Actions punktet bei der Integration in das GitHub-Ökosystem und den Aktionsmarktplatz. GitLab CI erfordert für viele Aufgaben manuelle Konfiguration, die GitHub Actions mit vorgefertigten Aktionen löst.

Aus mobiler CI/CD-Perspektive: GitLab CI eignet sich besser für Unternehmen, die bereits GitLab Self-Managed nutzen und selbstgehostete Runner mit Docker/Kubernetes benötigen. GitHub Actions ist praktischer für kleine Teams in der GitHub-Cloud, die vorgefertigte Aktionen und einfache Einrichtung schätzen.

Funktionsvergleich

Beispiel-Pipeline für Android-Projekt

Eine vollständige Android-Pipeline umfasst: Lint, Unit-Tests, Build und Deployment in Firebase App Distribution. Die Pipeline verwendet ein Docker-Image mit Android SDK, Gradle-Caching und parallele Ausführung von Lint und Test in derselben Stage. Dieser Ansatz verkürzt die Gesamtzeit der Pipeline, da Lint- und Testaufgaben voneinander unabhängig sind.

Bei iOS-Projekten unterscheidet sich die Pipeline-Struktur aufgrund der Notwendigkeit eines macOS-Runners und der Codesignierung. Eine typische iOS-Pipeline umfasst: Installation von CocoaPods oder SPM, Ausführung von Tests auf dem Simulator, Archivierung des Xcode-Projekts, Export von IPA und Upload zu TestFlight. GitLab CI für iOS verwendet macOS-Runner — entweder GitLab-SaaS-macOS-Runner mit Zeitbeschränkungen oder einen selbstgehosteten Runner auf einem Mac Mini oder 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

Optimierung der Build-Zeit in GitLab CI

Die Optimierung mobiler Build-Pipelines in GitLab CI erfordert Liebe zum Detail. Die richtige Konfiguration von Cache und Artefakten kann die Build-Zeit um ein Vielfaches reduzieren. Für die Leistungsanalyse bietet GitLab CI/CD Analytics — ein Dashboard mit Metriken zur Pipeline-Dauer, Runner-Auslastung und Engpässen. Analysieren Sie diese Metriken regelmäßig, um Optimierungsmöglichkeiten zu finden. Die Konfiguration von resource_group blockiert parallele Pipeline-Läufe — nützlich zur Vermeidung von Bereitstellungskonflikten.

Die Branch-Strategie für CI ist ebenfalls wichtig. Es wird empfohlen, die vollständige Pipeline nur für Main- und Release-Branches auszuführen und für Feature-Branches nur Lint und Unit-Tests. Das spart Runner-Minuten und beschleunigt das Feedback für Entwickler. GitLab CI unterstützt workflow:rules — bedingte Regeln zum Ein- oder Ausschließen von Jobs basierend auf Branch, geänderten Dateien oder Umgebungsvariablen.

Abhängigkeits-Caching ist die primäre Beschleunigungsmethode. GitLab CI cached .gradle, Pods und node_modules zwischen Läufen. Der Cache-Schlüssel enthält $CI_COMMIT_REF_SLUG oder einen Hash der Lock-Datei. Die Build-Zeit eines Android-Projekts sinkt bei richtigem Caching von 10–15 auf 2–4 Minuten. Der Cache kann verteilt werden — GitLab unterstützt cache:key mit Fallback auf vorherige Schlüssel.

Ein Docker-Image mit vorinstallierten Werkzeugen spart Installationszeit. Es wird empfohlen, ein benutzerdefiniertes Image mit Android SDK, NDK und der erforderlichen API-Ebene zu erstellen. Die parallele Ausführung von Jobs (Lint, Test, Assemble) in verschiedenen Stages reduziert die Gesamt-Pipeline-Zeit. Pull-Richtlinien für Images (if-not-present) beschleunigen den Job-Start. Ein Abhängigkeits-Proxy kann ebenfalls zum Zwischenspeichern von Images auf GitLab-Instanzebene verwendet werden.

Ein weiterer wichtiger Optimierungsaspekt ist die Verwendung von Artefakten zwischen Stufen. Schwere Dateien wie APK und IPA sollten über dependency übergeben werden, anstatt in jedem Job neu erstellt zu werden. Für große Projekte mit Dutzenden von Modulen wird empfohlen, den Gradle Build Cache auf Pipeline-Ebene zu aktivieren und einen Remote-Cache auf gemeinsamem Speicher zu konfigurieren. Das Timeout für jeden Job sollte basierend auf der erwarteten Build-Zeit festgelegt werden — dies verhindert hängende Prozesse.

Beispiel mit Caching und Pull-Richtlinie

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

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