CI/CD Pipeline — was es ist, Automatisierungsphasen und Werkzeuge

Was ist CI/CD Pipeline

CI/CD Pipeline ist eine formalisierte und automatisierte Reihe von Prozessen, die der Code vom Committen von Änderungen im Repository bis zum Deployment in die Produktion durchläuft. Der Begriff vereint zwei Praktiken: Continuous Integration (kontinuierliche Integration) und Continuous Delivery (kontinuierliche Auslieferung), die zusammen eine Softwarebereitstellungs-Pipeline bilden.

Geschichte von CI/CD

Das Konzept der Continuous Integration wurde 1991 von Grady Booch beschrieben und in den 2000er Jahren von Martin Fowler popularisiert. Continuous Delivery als Begriff etablierte sich nach dem Buch „Continuous Delivery“ von Jez Humble und David Farley (2010). Die moderne CI/CD Pipeline wurde ab 2015 mit dem Aufkommen von Cloud-CI-Servern und der Automatisierung von App-Stores zum De-facto-Standard in der mobilen Entwicklung.

Warum CI/CD Pipeline in der mobilen Entwicklung notwendig ist

Mobile Anwendungen haben spezifische Anforderungen an Build und Veröffentlichung: Zertifikatssignierung, mehrere Konfigurationen (Debug, Release, Staging), ProGuard/R8-Verschleierung, mehrere Build-Typen (APK, AAB, IPA) und Integration mit App-Stores. Die manuelle Ausführung dieser Schritte dauert Stunden und ist fehleranfällig — die CI/CD Pipeline automatisiert die Routine.

CI/CD Pipeline-Phasen für mobile Apps

Eine standardmäßige CI/CD Pipeline für Android- oder iOS-Apps besteht aus sieben Hauptphasen. Einige Phasen laufen parallel, andere sequenziell. Die genaue Zusammensetzung der Phasen hängt vom Technologie-Stack und der Teamreife ab, aber der Kern bleibt gleich.

1. Checkout und Abhängigkeitsinstallation

Die Pipeline beginnt mit dem Klonen des Repositorys und der Installation von Abhängigkeiten: Gradle/Maven für Android, CocoaPods oder SPM für iOS. Abhängigkeits-Caching zwischen Läufen reduziert die Installationszeit von 3–5 Minuten auf wenige Sekunden — alle modernen CI-Dienste unterstützen diese Optimierung.

2. Statische Analyse und Linting

Vor dem Build wird der Code von Lintern (ktlint, detekt für Android, SwiftLint für iOS) und statischen Analysewerkzeugen (Android Lint, SonarQube) überprüft. Linting erkennt potenzielle Fehler, Code-Stil-Verstöße und veraltete APIs vor der Testausführung — das Fail-Fast-Prinzip spart Teamzeit.

3. Projekt-Build

In der Build-Phase wird das gesamte Projekt kompiliert und Artefakte werden erzeugt: APK und AAB für Android, IPA für iOS. Für Android werden Gradle-Tasks verwendet (assembleDebug, bundleRelease), für iOS — xcodebuild oder xcrun. Der Build wird in einer isolierten CI-Server-Umgebung ausgeführt, was Reproduzierbarkeit gewährleistet.

# Beispiel einer CI/CD-Pipeline für Android in 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. Automatisierte Tests

Nach dem Build werden Unit-Tests, Integrationstests und UI-Tests ausgeführt. JUnit und MockK für Unit-Tests, Espresso und Compose Test für UI auf Android, XCTest und XCUITest auf iOS. Die Ergebnisse werden in einem Bericht veröffentlicht und blockieren die Pipeline bei Fehlschlag kritischer Tests.

5. Signierung und Verschleierung

Für Release-Builds werden die digitale Zertifikatssignierung (APK Signer für Android, codesign für iOS) und Code-Verschleierung durchgeführt. ProGuard oder R8 für Android reduziert die APK-Größe um 15–30%. Signaturschlüssel werden in den Geheimnissen des CI-Servers gespeichert — niemals in das Repository committet.

6. Auslieferung und Deployment

Die letzte Phase der Pipeline ist die Veröffentlichung von Artefakten: Hochladen von APK in Google Play Console internes Testen, Senden von IPA an TestFlight oder Veröffentlichung in Firebase Distribution. Continuous Delivery bedeutet, dass dieser Schritt eine manuelle Bestätigung erfordert, während Continuous Deployment automatisch ausgeführt wird.

7. Benachrichtigungen und Berichte

Nach Abschluss der Pipeline erhält das Team eine Benachrichtigung mit den Ergebnissen: Erfolg/Fehlschlag, Ausführungszeit, Link zu den Artefakten. Slack, Telegram oder E-Mail — die Benachrichtigungskanäle werden je nach Team-Bedarf ausgewählt. Wenn eine Phase fehlschlägt, enthält die Benachrichtigung einen Link zum spezifischen Fehlerprotokoll.

Unterschied zwischen CI und CD

Die Begriffe CI und CD werden oft als einheitliches Konzept CI/CD verwendet, aber es gibt einen grundlegenden Unterschied zwischen ihnen. CI (Continuous Integration) ist für die Qualitätsprüfung bei jeder Code-Integration verantwortlich, während CD (Continuous Delivery) die Release-Bereitschaft des Codes sicherstellt. Das Verständnis des Unterschieds ist bei der Planung einer Pipeline entscheidend.

Continuous Integration — Qualitätsprüfung

CI wird bei jedem Push oder Pull Request ausgeführt und umfasst Build, statische Analyse und Tests. Das Ziel von CI ist es, Probleme so früh wie möglich zu erkennen, wenn die Kosten für deren Behebung minimal sind. Wenn CI fehlschlägt — gelangt der Code nicht in den Hauptzweig. Die durchschnittliche CI-Ausführungszeit für ein mobiles Projekt beträgt 5–15 Minuten.

Continuous Delivery — Release-Bereitschaft

CD fügt zu CI die Phasen der Release-Vorbereitung hinzu: Signierung, Verschleierung, Erstellung von Release-Notes, Lizenzprüfung, Veröffentlichung im Speicher für Tester. CD garantiert, dass jeder Commit im Hauptzweig mit einem Klick in die Produktion ausgeliefert werden kann, aber das Release selbst erfordert eine manuelle Freigabe.

Werkzeuge zum Aufbau einer CI/CD Pipeline

Das Ökosystem der CI/CD-Werkzeuge für die mobile Entwicklung umfasst Cloud-Dienste, selbst gehostete Lösungen und spezialisierte Plattformen. Die Wahl des Werkzeugs hängt von der Teamgröße, dem Budget und den Sicherheitsanforderungen ab. Nachfolgend sind die beliebtesten Optionen aufgeführt.

GitHub Actions

Integriertes CI/CD in GitHub mit einem kostenlosen Limit von 2000 Minuten pro Monat für öffentliche Repositorys. GitHub Actions ist dank des riesigen Ökosystems vorgefertigter Aktionen (Marktplatz), der einfachen YAML-Konfiguration und der nahtlosen Integration mit GitHub-Repositorys beliebt. Einschränkung — keine Unterstützung für Windows-Runner für iOS-Builds im kostenlosen Tarif.

GitLab CI/CD

Selbst gehostete und Cloud-Lösung mit einem leistungsstarken YAML-Konfigurator. GitLab CI unterstützt parallele Jobs, Caching, Artefakte und Umgebungen. Beliebt im Enterprise-Segment aufgrund der Möglichkeit, auf eigener Infrastruktur zu deployen und der vollständigen Datenkontrolle.

Jenkins

Klassischer Open-Source-CI-Server. Jenkins wird über Plugins (über 1800) konfiguriert, unterstützt Declarative Pipeline im Groovy-Format und läuft in jeder Umgebung: Windows, macOS, Linux. Erfordert dedizierte Administration, bietet aber maximale Konfigurationsflexibilität.

CircleCI

Cloud-CI-Dienst mit Fokus auf Geschwindigkeit und Einfachheit. CircleCI cached Abhängigkeiten automatisch, unterstützt Docker-Images für isolierte Builds und integriert sich mit macOS für iOS-Builds. Die Preisgestaltung basiert auf Credits — geeignet für Teams, die Leistung schätzen.

Beispiel einer CI/CD Pipeline-Einrichtung

Betrachten wir eine vollständige CI/CD Pipeline für eine iOS-App mit GitHub Actions und Fastlane. Fastlane ist ein Automatisierungswerkzeug für mobile Projekte, das komplexe Build-, Signier- und Veröffentlichungsvorgänge in einfache Befehle abstrahiert.

# Fastfile — Fastlane-Konfiguration für iOS CI/CD
default_platform(:ios)

platform :ios do
  desc "Tests und Linting ausführen"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "Release-Build und Upload in 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 verwaltet Zertifikate und Provisioning-Profile, build_app erstellt IPA, pilot lädt den Build zu TestFlight hoch. Der Befehl fastlane release führt alle Phasen sequenziell aus: holt Zertifikate, baut, signiert, lädt zu App Store Connect für Beta-Tester hoch.

CI/CD Pipeline für iOS mit GitHub Actions

Die Integration von Fastlane mit GitHub Actions ermöglicht die automatische Ausführung der gesamten Pipeline bei Pull-Requests in den Hauptzweig. Ein selbst gehosteter Runner auf macOS ist für die iOS-Code-Kompilierung erforderlich — GitHub stellt keine macOS-Runner im kostenlosen Tarif bereit.

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

Bewährte Praktiken für CI/CD Pipeline

Der Aufbau einer effektiven CI/CD Pipeline erfordert nicht nur die Auswahl von Werkzeugen, sondern auch die Befolgung bewährter Praktiken. Ohne richtige Organisation kann die Pipeline zu einem Engpass werden, der die Entwicklung verlangsamt statt beschleunigt. Nachfolgend sind die wichtigsten Empfehlungen basierend auf der Erfahrung reifer mobiler Teams.

Fail Fast

Die schnellsten Prüfungen (Linting, Unit-Tests) werden zuerst ausgeführt. Wenn sie fehlschlagen — wird die Pipeline ohne Ausführung langer UI-Tests oder Release-Builds beendet. Fail Fast spart Minuten an CI-Zeit und beschleunigt das Feedback an den Entwickler. Die durchschnittliche Zeit bis zum ersten Fehlschlag sollte 2–3 Minuten nicht überschreiten.

Abhängigkeits-Caching

Gradle-Cache, CocoaPods-Cache und SPM-Cache sollten zwischen Läufen wiederhergestellt werden. GitHub Actions unterstützt Caching über actions/cache, GitLab CI über das cache-Keyword. Ohne Caching lädt jeder Build alle Abhängigkeiten neu herunter — dies fügt 3–10 Minuten zur Pipeline-Zeit hinzu.

Parallele Ausführung

Unabhängige Phasen (Linter für Android und iOS, Unit-Tests verschiedener Module) werden als parallele Jobs ausgeführt. Die Parallelisierung reduziert die gesamte Pipeline-Zeit von 20–30 Minuten auf 5–10 Minuten. Die meisten CI-Dienste berechnen parallele Jobs separat — beachten Sie dies bei der Tarifwahl.

Umgebungsisolierung

Jeder Pipeline-Lauf wird in einer sauberen Umgebung ausgeführt: Docker-Container, virtuelle Maschine oder ephemerer Runner. Die Isolierung verhindert, dass vorherige Builds den aktuellen beeinflussen. Vermeiden Sie die Verwendung gemeinsamer Runner zwischen Projekten — projektübergreifende Umgebungsverschmutzung führt zu nicht-deterministischen Fehlern.

Geheimnissicherheit

API-Schlüssel, Signierzertifikate und App-Store-Zugriffstoken werden im verschlüsselten Tresor des CI-Servers gespeichert. Schließen Sie niemals Geheimnisse in Protokolle, Artefakte oder Umgebungsvariablen ohne das Präfix SECRET_ ein. Verwenden Sie Werkzeuge wie Fastlane match für die iOS-Zertifikatsverwaltung.