Continuous Delivery (CD): Was es ist und der Unterschied zu Continuous Deployment

Was ist Continuous Delivery

Continuous Delivery (CD) ist eine Erweiterung von Continuous Integration, die Automatisierung für alle Phasen der Release-Vorbereitung hinzufügt: Erstellung des Release-Builds, Signierung mit Zertifikaten, Verschleierung, Überprüfung der App-Store-Metadaten und Deployment in der Staging-Umgebung. Der Begriff wurde von Jez Humble und David Farley in ihrem Buch „Continuous Delivery“ (2010) eingeführt, wo sie die Praxis formalisierten, die es Teams ermöglicht, Releases vorhersehbar und risikoarm zu gestalten.

Entwicklung der Softwareauslieferung

Vor der Einführung von CD waren Releases ein Ereignis: Das Team versammelte sich in einem Raum, arbeitete eine 20-Punkte-Checkliste ab, führte Skripte manuell aus und hoffte, dass nichts kaputtgeht. Continuous Delivery verwandelt ein Release von einem Ereignis in einen Prozess: Eine kleine Codeänderung kann innerhalb von Minuten an Benutzer ausgeliefert werden, nicht in Wochen. Amazon, Netflix und Etsy führten CD in den 2010er Jahren als erste ein — heute ist es der Standard für Produktteams.

Geschäftswert von CD

Die schnelle Auslieferung von Funktionen ist ein Wettbewerbsvorteil. Wenn ein Wettbewerber neue Funktionalität in Tagen ausliefert, während Sie Monate brauchen, wählt der Markt den Wettbewerber. Die DORA-Metriken zeigen: Elite-Teams (mit CD) haben eine Deployment-Vorlaufzeit von unter 1 Stunde, niedrige Teams (ohne CD) — von 1 Woche bis 1 Monat. CD reduziert auch das Risiko radikal: Kleine Änderungen sind schwerer zu kaputt zu machen als ein großes vierteljährliches Release.

CD vs CI vs Continuous Deployment

Die Begriffe CI, CD und Continuous Deployment werden oft verwechselt, aber es gibt eine klare Grenze zwischen ihnen. Das Verständnis der Unterschiede hilft, die Pipeline richtig zu entwerfen und den Automatisierungsgrad zu wählen, der der Teamreife und den Geschäftsanforderungen entspricht.

Continuous Integration

CI ist das Fundament, auf dem CD aufbaut. CI stellt sicher, dass jeder Commit Build und Tests durchläuft. Ohne CI ist CD unmöglich: Wenn Code nicht verifiziert ist, kann er nicht veröffentlicht werden. CI überprüft die Korrektheit, CD überprüft die Bereitschaft für den Geschäftseinsatz.

Continuous Delivery

CD fügt CI die Phasen der Erstellung eines Release-Builds, Überprüfung von Metadaten, Signierung und Deployment in der Staging-Umgebung oder im App-Store für Beta-Tests hinzu. Der Hauptunterschied — die Entscheidung, in die Produktion zu veröffentlichen, trifft eine Person (Manager, Product Owner). CD macht das Release „einen Klick entfernt“ — einfach und sicher.

Continuous Deployment

Continuous Deployment ist vollständige Automatisierung: Jede Änderung, die alle Phasen der CD-Pipeline durchläuft, wird automatisch in die Produktion gesendet ohne manuelle Bestätigung. Continuous Deployment ist für SaaS-Produkte und Webdienste anwendbar, wird aber in der mobilen Entwicklung aufgrund der App-Store-Richtlinien (App Store Review, Google Play Review erfordert manuelle Einreichung) selten verwendet.

Continuous Delivery für mobile Anwendungen

CD für mobile Anwendungen hat Merkmale, die es von Web- und Backend-Pipelines unterscheiden. Mobile Releases durchlaufen App-Stores (App Store Review, Google Play Review), was eine zeitliche und verfahrenstechnische Hürde darstellt. CD automatisiert alles, was vor der Einreichung zur Überprüfung automatisiert werden kann, um die Wahrscheinlichkeit des Bestehens der Überprüfung beim ersten Versuch zu maximieren.

Vorbereitung für die Veröffentlichung im Google Play Store

Die Android-CD-Pipeline umfasst: Erstellung von AAB (Android App Bundle), Signierung mit einem Release-Schlüssel, Verschleierung durch R8/ProGuard, Überprüfung der APK-Größe und Multidex-Klassen, Generierung von Release-Notes. Die Verwendung von Gradle Product Flavors (free/paid, dev/staging/prod) ermöglicht die Verwaltung mehrerer Konfigurationen aus einer einzigen Pipeline.

Vorbereitung für die Veröffentlichung im App Store

iOS-CD erfordert Signierung mit Zertifikaten über Fastlane match, Überprüfung der Icon-Konformität (App Store-Anforderung — 1024×1024 px), Validierung von Metadaten (Name, Beschreibung, Schlüsselwörter), Überprüfung auf das Fehlen privater APIs. Die technische Validierung erfolgt über altool --validate-app ohne Hochladen in App Store Connect, was schnelles Feedback ermöglicht.

# Fastfile — vollständige CD-Pipeline für iOS und Android
platform :ios do
  desc "iOS CD — Release-Vorbereitung und Upload zu TestFlight"
  lane :deliver_to_testflight do
    capture_screenshots
    match(type: "appstore")
    build_app(
      scheme: "MyApp",
      export_method: "app-store",
      workspace: "MyApp.xcworkspace"
    )
    pilot(skip_waiting_for_build: true)
  end
end

platform :android do
  desc "Android CD — AAB-Build und Upload zur Google Play Console"
  lane :deliver_to_internal do
    gradle(
      task: "bundleRelease",
      build_type: "Release",
      print_command: true
    )
    upload_to_play_store(
      track: "internal",
      skip_upload_metadata: true
    )
  end
end

Fastlane deliver_to_testflight sammelt Screenshots, holt Zertifikate über match, erstellt IPA und lädt es in TestFlight hoch. Die deliver_to_internal Lane für Android erstellt Release AAB über Gradle und lädt es in die interne Spur der Google Play Console hoch. Beide Pipelines werden nach bestandenen Tests von CI aus gestartet.

Komponenten der CD-Pipeline

Eine CD-Pipeline besteht aus aufeinanderfolgenden Phasen, die jeweils das Vertrauen stärken, dass das Release für die Benutzer bereit ist. Die Phasen werden in technische (Build, Signierung) und produktbezogene (Metadaten, Screenshots, Beschreibungsprüfung) unterteilt. Das Überspringen einer Phase erhöht das Risiko, dass das Release vom App-Store abgelehnt wird.

Versionsverwaltung

Ein kritischer Bestandteil von CD ist die automatische Versionsverwaltung. Der Version-Bump (versionCode und versionName für Android, CFBundleVersion und CFBundleShortVersionString für iOS) wird basierend auf Git-Tags oder der vorherigen Version im Store durchgeführt. Fastlane increment_version_number und Gradle-Befehle (versionCode auto-increment) automatisieren diesen Schritt.

Store-Metadaten

Google Play Console und App Store Connect erfordern: App-Beschreibung, Schlüsselwörter, Kategorie, Bewertung, Datenschutzrichtlinien-Links. CD umfasst die Überprüfung der Vollständigkeit und Richtigkeit der Metadaten. Fastlane deliver und supply automatisieren das Hochladen von Beschreibungen, Screenshots und Icons zusammen mit dem Build.

Gate-Prüfungen

Vor der Einreichung zur Überprüfung führt die Pipeline Gate-Prüfungen durch: Build-Größenprüfung (APK > 200 MB wird von Google Play abgelehnt), Vorhandensein aller Lokalisierungen, Fehlen von Debug-Symbolen im Release-Build, Prüfung der ProGuard-Mapping-Datei zum Dekodieren von Crash-Logs. Wenn eine Prüfung fehlschlägt — blockiert die Pipeline das Release.

Automatisierte Tests für CD

Das Vertrauensniveau in CD ist direkt proportional zur Qualität der automatisierten Tests. Wenn Tests keine Regressionen erkennen — kann das Release die Produktion beeinträchtigen und das Team verliert das Vertrauen in CD. Mobiles CD erfordert eine dreistufige Testpyramide, die an die Besonderheiten der Plattform angepasst ist.

Unit-Tests

Unit-Tests überprüfen die Geschäftslogik isoliert. Die Codeabdeckung sollte für kritische Module (Authentifizierung, Zahlungen, Netzwerk) mindestens 70% betragen. CI führt Unit-Tests bei jedem Push aus, und wenn sie fehlschlagen — wird die CD-Pipeline bis zur Behebung blockiert.

Integrationstests

Sie überprüfen die Interaktion von Komponenten: Netzwerkschicht mit echter API (oder Mock-Server), Datenbank, Dateisystem. Room-DAO-Tests für Android, Core-Data-Tests für iOS sind Beispiele für Integrationstests. Sie sind langsamer als Unit-Tests (1–5 Minuten) und werden in der CD-Phase ausgeführt, nicht bei jedem Commit in CI.

UI- und Screenshot-Tests

Screenshot-Tests (Snapshottests) vergleichen App-Bildschirme mit Referenzbildern. Wenn eine Codeänderung die UI verändert hat — schlägt der Test fehl, und der Entwickler prüft, ob die Änderung erwartet wird. Android unterstützt Roborazzi und Paparazzi, iOS — SnapshotTesting von Point-Free. Screenshot-Tests werden vor dem Release als Teil der CD-Pipeline ausgeführt.

Bewährte Verfahren für Continuous Delivery

Die Einführung von Continuous Delivery erfordert nicht nur Werkzeuge, sondern auch eine Änderung der Teamkultur. Die folgenden Praktiken basieren auf jahrelanger Erfahrung mobiler Teams von Google, Spotify und Uber und sind für Projekte jeder Größe angepasst.

Feature Flags

Der Code einer neuen Funktion wird in die Produktion ausgeliefert, aber hinter einem Flag versteckt. Feature Flags ermöglichen es, Code bereitzustellen, bevor die Funktion für Benutzer bereit ist, und sie bei Problemen sofort zu deaktivieren. Bibliotheken: LaunchDarkly, Firebase Remote Config, Unleash. Feature Flags sind eine zwingende Voraussetzung für CD in mobilen Projekten.

Staging-Umgebung

Vor der Auslieferung in die Produktion wird der Build in Staging deployed — einer Umgebung, die identisch mit der Produktion ist, aber mit Testdaten. QA-Ingenieure überprüfen die Funktion auf einem Staging-Build, der über TestFlight oder die Internal-Testing-Spur installiert wurde. Wenn Staging besteht – erhält der Build die Freigabe zur Einreichung zur Store-Überprüfung.

Release-Notes und Changelog

CD generiert automatisch Release-Notes basierend auf Commit-Nachrichten. Conventional Commits (feat:, fix:, chore:) und Git-Tags im Semantic-Versioning-Format ermöglichen das Parsen des Änderungsverlaufs. Fastlane changelog_from_git_commits sammelt Änderungen zwischen den letzten beiden Tags und formatiert sie für den App-Store.

Überwachung nach dem Release

CD endet nicht mit der Veröffentlichung — nach dem Release beginnt die Überwachung: Crash-Rate, ANR-Rate für Android, Startzeit, Zahlungsfehlerrate. Wenn Metriken die normalen Grenzen überschreiten — sollte die CD-Pipeline das Release automatisch zurücksetzen oder das Team benachrichtigen. Tools: Firebase Crashlytics, Sentry, New Relic.

// Beispiel für Feature Flag mit Firebase Remote Config für CD
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

    fun getRecommendedVersion(): String {
        return remoteConfig.getString("minimum_app_version")
    }
}

// Verwendung im Code
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}