Continuous Integration (CI) — was es ist, Prinzipien und Einrichtung der Automatisierung

Was ist Continuous Integration

Continuous Integration (CI) ist eine Entwicklungsmethodik, die den Prozess der Integration von Code mehrerer Mitwirkender in eine einzige Codebasis automatisiert. Der Begriff wurde Anfang der 2000er Jahre von Martin Fowler als eine Reihe von Praktiken zur Vermeidung der „Integrationshölle“ eingeführt — einer Situation, in der Entwickler wochenlang isoliert arbeiten und beim Zusammenführen von Änderungen zahlreiche Konflikte auftreten, deren manuelle Lösung Tage dauert.

Das Problem, das CI löst

Ohne CI beendet ein Entwickler eine Funktion, versucht seine Änderungen in den main-Branch zu mergen und stellt fest, dass Kollegen dieselben Dateien geändert haben. Die Behebung von Konflikten dauert Stunden und zerbricht oft funktionierenden Code. CI löst dieses Problem, indem es mehrmals täglich Integrationen erzwingt: Je häufiger die Integration, desto weniger Konflikte und desto einfacher ihre Lösung. Die Praxis zeigt, dass bei täglicher Integration die Konfliktlösung Minuten dauert, bei wöchentlicher Integration hingegen Stunden.

Wirtschaftliche Auswirkungen von CI

Laut IBM Systems Sciences Institute betragen die Kosten für die Behebung eines Fehlers in der Codierungsphase 25 $, in der Testphase 100 $ und in der Produktionsphase 2.500 $. CI verschiebt die Fehlererkennung so weit wie möglich nach links (Shift Left) und findet Fehler bereits in der Commit-Phase, wenn ihre Behebung praktisch kostenlos ist. Teams mit CI verbringen durchschnittlich 15 % ihrer Zeit mit Debugging, gegenüber 35 % bei Teams ohne CI.

Grundprinzipien von Continuous Integration

Martin Fowler definierte die wichtigsten CI-Praktiken, die unabhängig vom Technologie-Stack relevant bleiben. Die Befolgung dieser Prinzipien stellt sicher, dass CI einen Mehrwert bringt und nicht zur bürokratischen Belastung wird. Die mobile Entwicklung stellt zusätzliche Anforderungen, aber der Kern bleibt unverändert.

Einheitliches Repository

Der gesamte Projektcode wird in einem einzigen Repository mit einem einheitlichen Versionskontrollsystem (Git) gespeichert. Eine einzige Quelle der Wahrheit vermeidet die Situation, dass eine Funktion in einem Fork entwickelt und wochenlang nicht mit der Hauptcodebasis synchronisiert wird. In mobilen Projekten können Android-, iOS- und Backend-Teile in einem Repository (Monorepo) oder in separaten Repositorys mit einem gemeinsamen Versionierungsschema abgelegt werden.

Automatisierter Build

Der Projektbuild muss mit einem einzigen Befehl ausführbar sein. Für Android ist dies ./gradlew assembleDebug, für iOS — xcodebuild oder fastlane build. Das Build-Skript überprüft die Reproduzierbarkeit: Der Build auf dem CI-Server muss das gleiche Ergebnis liefern wie auf dem Entwicklerrechner. Unterschiede in der Umgebung werden durch Containerisierung oder IaC (Infrastructure as Code) beseitigt.

Automatisierte Tests

Nach dem Build werden alle Testebenen ausgeführt: Unit-, Integrations- und UI-Tests. Wenn Tests fehlschlagen, gilt der Commit als ungültig. Die Aufrechterhaltung des grünen Status ist eine gemeinsame Verantwortung des Teams. In mobilen Projekten werden schnelle Tests (Ausführung innerhalb von 5 Minuten pro Commit) oft von langsamen Tests (UI-Tests auf echten Geräten, seltener ausgeführt) getrennt.

// Beispiel für einen Unit-Test mit CI-freundlichem Bericht
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 und Transparenz

CI-Ergebnisse sind für das gesamte Team sichtbar: Jeder kann sehen, welcher Commit den Build kaputt gemacht hat. Transparenz schafft eine Kultur der Verantwortung: Entwickler überprüfen ihre Änderungen vor dem Push und beheben kaputte Builds außer der Reihe. Der CI-Server sendet Benachrichtigungen an Slack oder Telegram, wenn sich der Build-Status ändert.

Komponenten eines CI-Systems

Ein vollständiges CI-System besteht aus mehreren Komponenten, die miteinander interagieren. Jede Komponente ist für ihren Teil der Pipeline verantwortlich: vom Auslösen bis zum Bericht. Das Verständnis der CI-Architektur hilft bei der Diagnose von Problemen und der Optimierung der Leistung.

CI-Server

Die zentrale Komponente, die die Build-Warteschlange, die Ressourcenzuweisung und die Veröffentlichung von Ergebnissen verwaltet. Ein CI-Server kann cloudbasiert (GitHub Actions, GitLab CI, CircleCI) oder selbst gehostet (Jenkins, TeamCity) sein. Der Server überwacht Repository-Änderungen per Webhook oder Polling und löst bei jedem Push oder Pull Request die Pipeline aus.

Runner und Agents

Runner sind virtuelle oder physische Maschinen, die Build-Aufgaben ausführen. In der Cloud-CI werden Runner vom Anbieter bereitgestellt und nach Nutzungszeit abgerechnet. Selbst gehostete Runner werden auf der eigenen Infrastruktur installiert und erfordern Wartung. iOS-Builds benötigen macOS-Runner, Android-Builds Linux oder Windows.

Artefakte und Cache

Nach dem Build speichert das CI-System Artefakte (APK, IPA, Testberichte) im Speicher — sie stehen zum Download und Deployment zur Verfügung. Das Caching von Abhängigkeiten (Gradle-Cache, CocoaPods-Cache) zwischen den Läufen beschleunigt nachfolgende Builds um das 3- bis 5-fache.

Continuous Integration für mobile Anwendungen

Die mobile Entwicklung stellt besondere Anforderungen an CI, die sich von Web- oder Backend-Projekten unterscheiden. Lange Build-Zeiten (3–15 Minuten für Android, 5–20 Minuten für iOS), mehrere Artefakttypen (APK, AAB, IPA), die Notwendigkeit von Signierung und Verschleierung — all dies erfordert eine individuell angepasste CI-Pipeline-Konfiguration.

Android-CI-Pipeline

Eine typische CI für Android umfasst: Linting (ktlint, detekt) und statische Analyse, Unit-Tests mit JUnit und MockK, Build von Debug- und Release-APK/AAB, Instrumentierungstests auf einem Emulator innerhalb der CI und Veröffentlichung von Artefakten. Der Gradle-Cache beschleunigt wiederholte Builds — ohne ihn lädt jeder Build Abhängigkeiten neu herunter, was 3–5 Minuten kostet.

iOS-CI-Pipeline

iOS-CI benötigt einen macOS-Runner zum Kompilieren von Swift/Objective-C-Code. Die Pipeline umfasst: Installation von CocoaPods- oder SPM-Abhängigkeiten, SwiftLint zur Stilprüfung, Unit-Tests mit XCTest, IPA-Build, Codesignierung per Fastlane match und Upload zu TestFlight. Ein selbst gehosteter Runner auf Mac mini oder Mac in einem Rechenzentrum ist eine Alternative zu Cloud-macOS-Runnern.

Plattformübergreifende Projekte (Flutter, React Native)

Flutter und React Native werden in native Builds für beide Plattformen kompiliert. CI muss zwei Runner unterstützen: Linux für Android-Builds und macOS für iOS-Builds. Die optimale Strategie ist eine geteilte Pipeline: Android-Build auf einem Linux-Runner, iOS-Build auf einem macOS-Runner, wonach beide Artefakte in einem einzigen Release zusammengeführt werden.

Vergleich von CI-Tools

Die Wahl eines CI-Tools hängt von der Teamgröße, der erforderlichen Leistung, dem Budget und dem Technologie-Stack ab. Nachfolgend ein Vergleich beliebter Lösungen mit Fokus auf mobile Entwicklung. Selbst gehostete Lösungen bieten Kontrolle, erfordern aber Administration; Cloud-Lösungen bieten Komfort, schränken aber die Konfiguration ein.

GitHub Actions

Kostenlos für öffentliche Repositorys (2000 Minuten/Monat). GitHub Actions bietet ein Ökosystem vorgefertigter Aktionen für Android (gradle/actions) und iOS (apple-actions). Der Nachteil ist, dass macOS-Runner nur in kostenpflichtigen Tarifen verfügbar sind. Ideal für Open-Source-Projekte und kleine Teams, die bereits GitHub nutzen.

Jenkins

Ein selbst gehosteter Open-Source-CI-Server. Jenkins wird über Groovy Pipeline konfiguriert, unterstützt Hunderte von Plugins und läuft auf jeder Hardware. Erfordert einen DevOps-Ingenieur für Einrichtung und Wartung. Beliebt im Enterprise-Bereich, wo die Kontrolle über die Infrastruktur entscheidend ist.

GitLab CI

Integriertes CI/CD in GitLab mit offener Runner-Architektur. GitLab CI erlaubt die Verwendung eigener Runner (einschließlich macOS) im kostenlosen Tarif. Die YAML-Konfiguration ist leistungsfähiger als GitHub Actions, aber schwerer zu erlernen. Geeignet für Teams, die GitLab als einheitliche DevOps-Plattform nutzen.

CircleCI

Eine Cloud-CI mit Fokus auf Geschwindigkeit. CircleCI unterstützt Docker-, macOS- und Android-Images und cached Abhängigkeiten automatisch. Die Preisgestaltung erfolgt kreditbasiert — teurer als GitHub Actions für kleine Teams, aber schneller durch optimierte Runner. Empfohlen für Produktionsprojekte mit Geschwindigkeitsanforderungen.

Beispiel für die CI-Einrichtung

Betrachten wir die Einrichtung von CI für ein Android-Projekt mit GitHub Actions. Die Pipeline führt bei jedem Push und Pull Request in den main-Branch statische Analysen, Builds und Tests durch. Die minimale Konfiguration dauert 15 Minuten und erfordert keine externen Dienste.

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/

Die Pipeline besteht aus zwei parallelen Jobs: lint (führt statische Analysen durch) und unit-tests (abhängig von lint — wenn Linting fehlschlägt, werden Tests nicht ausgeführt). Der unit-tests-Job lädt den Testbericht als Artefakt hoch — das Team kann ihn in der GitHub Actions UI einsehen, ohne Dateien lokal herunterzuladen.

Lokale Prüfung vor CI

Um CI-Fehler aufgrund trivialer Fehler zu vermeiden, richten Sie einen Pre-Push-Hook in Git oder eine Gradle-Aufgabe ein, die dieselben Prüfungen lokal ausführt. Zum Beispiel: ./gradlew ktlintCheck detekt testDebugUnitTest. Wenn lokale Prüfungen länger als 3 Minuten dauern, teilen Sie sie in schnelle (Linter) und langsame (Tests) auf, wobei schnelle Prüfungen vor jedem Commit und langsame nur vor dem Push ausgeführt werden.