Was ist CI/CD (Continuous Integration und Delivery)?

CI/CD ist eine Praxis, die Build, Tests und Auslieferung von Code automatisiert, sodass jede Änderung in kleinen Schritten in die Produktion gelangt. Der Name verdichtet zwei Ideen – Continuous Integration (ständig zusammenführen und prüfen) und Continuous Delivery (jede Änderung releasefähig halten) – plus eine berühmte Mehrdeutigkeit: Das zweite “D” kann auch Continuous Deployment bedeuten, wo nichts außer einem fehlgeschlagenen Test zwischen einem Commit und der Produktion steht.

Das Wichtigste in Kürze

Wie eine Pipeline tatsächlich aussieht

Die ganze Praxis passt in eine Konfigurationsdatei – das Artefakt, das jede Seite “CI/CD erklärt” beschreibt und fast keine zeigt:

# pipeline.yml — die Automatisierung, die den "Deploy-Tag" ersetzt
on: push to main

jobs:
  build:
    steps:
      - checkout
      - run: npm ci && npm run build
  test:
    needs: build
    steps:
      - run: npm test            # Unit + Integration, bei jedem Commit
      - run: npm run lint        # statische Analyse
  deploy:
    needs: test
    approval: manual             # diese Zeile löschen → Continuous Deployment
    steps:
      - run: npm run deploy

Minuten nachdem dieser letzte Schritt gelaufen ist, rufen alle Clients bereits die neue Backend-Version auf – und genau darum geht es:

// JavaScript / Node.js — Back4app JS SDK
// Seconds after `b4a deploy`, every client is calling the new version
const version = await Parse.Cloud.run('version');
console.log(`API version: ${version}`); // no pipeline YAML, no runners

// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('version');
final response = await function.execute();
if (response.success) {
  print('API version: ${response.result}'); // fresh from the deploy
}

// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("version") { result in
  if case .success(let version) = result {
    print("API version: \(version)") // fresh from the deploy
  }
}

// Android / Kotlin — Back4app Android SDK
ParseCloud.callFunctionInBackground<String>("version", hashMapOf()) { version, e ->
  if (e == null) Log.d("API", "version: $version") // fresh from the deploy
}

CI vs. Continuous Delivery vs. Continuous Deployment

Die Herkunft ist einen Satz wert: Martin Fowlers kanonischer Artikel definierte CI im Jahr 2000, das Buch Continuous Delivery von 2010 dehnte sie auf den Release-Prozess aus, und DevOps machte das Paar zu seinem Automatisierungsrückgrat. Eine scharfe Kante von Fowler schneidet bis heute: Einen Build-Server gegen langlebige Feature-Branches laufen zu lassen, ist “Halb-Integration” – echtes CI heißt, dass der Hauptzweig die Arbeit aller mindestens täglich integriert.

Die Pipeline, Stufe für Stufe

• Quelle. Ein Commit oder Merge löst alles aus. Niemals manuelle Builds – was nicht ausgelöst wird, ist kein CI.
• Build. Kompilieren, Abhängigkeiten auflösen, das Artefakt erzeugen (Bundle, Container-Image), das jede spätere Stufe wiederverwendet – einmal bauen, überall weiterreichen.
• Test. Schnelle Prüfungen zuerst: Unit-Tests und Linting bei jedem Commit; danach Integrationstests gegen echte Abhängigkeiten; End-to-End-, Performance- und Sicherheitsprüfungen in späteren oder geplanten Läufen. Die Feedback-Geschwindigkeit bestimmt die Reihenfolge der Stufen.
• Ausliefern. Das Artefakt landet in einer produktionsnahen Staging-Umgebung. Bei Continuous Delivery wartet es dort – releasefähig – auf ein menschliches Ja.
• Deployen. Produktion. Ausgereifte Pipelines deployen schrittweise – ein Canary-Anteil oder eine parallele Blue-Green-Umgebung –, damit eine schlechte Änderung ein eingegrenzter Rollback bleibt und kein Ausfall wird.

Die Messung: die DORA-Metriken

“Sind wir gut in der Auslieferung?” hat eine Standardantwort: die fünf Metriken des DORA-Forschungsprogramms – Deployment-Frequenz, Vorlaufzeit von Änderungen, Fehlerrate von Änderungen, Wiederherstellungszeit nach einem fehlgeschlagenen Deployment und Nacharbeitsquote bei Deployments. Der meistzitierte Befund der Forschung lautet, dass der klassische Trade-off zwischen Tempo und Stabilität nicht existiert: Teams, die am häufigsten deployen, verursachen auch die wenigsten Defekte, weil kleine häufige Änderungen einzeln risikoarm und schnell zu diagnostizieren sind. Bewegt Ihre Pipeline-Arbeit keine der fünf Zahlen, ist sie Installation, kein Fortschritt.

Typische Anwendungsfälle

• Web- und API-Backends – die natürliche Heimat von vollem Continuous Deployment: hohes Änderungsvolumen, sofortiger Rollback, kein Installationsschritt.
• Mobile Apps – CI plus Continuous Delivery: Pipelines bauen, testen und stagen jede Änderung, während die Store-Prüfung den letzten Schritt ohnehin mit einem Tor versieht.
• Teams, die über eine deployende Person hinauswachsen – die Pipeline ersetzt den einen Menschen, der “weiß, wie man released”, durch einen Prozess, den jeder ausführen kann.
• Regulierte Umgebungen – das Freigabetor wird zum Feature: volle Automatisierung bis zur Linie, eine prüfbare menschliche Entscheidung an ihr.
• Open-Source-Projekte – jeder automatisch gebaute und getestete Pull Request ist CI als Eingangstür des Projekts.

Sollten Sie die Produktion mit einem Tor sichern? Eine Entscheidungsmatrix

Die ehrliche Reihenfolge: Verdienen Sie sich Deployment, indem Sie Delivery praktizieren – automatisieren Sie alles bis zum Tor, beobachten Sie die Fehlerrate und entfernen Sie das Tor dann, wenn es ohnehin nichts mehr tut.

Grenzen und Trade-offs

• Die Pipeline ist Code, der Ihnen gehört. Runner, YAML, Caches, Secrets – alles will gepflegt werden, und ab einer gewissen Teamgröße wird die Pipeline ein eigenes Produkt mit eigener Rufbereitschaft.
• Instabile Tests vergiften alles. Eine Suite, die zufällig fehlschlägt, erzieht Menschen dazu, auf “erneut versuchen” zu klicken – und verwandelt Continuous Deployment still zurück in manuelles Deployment mit Zusatzschritten.
• Kultur ist Voraussetzung, nicht Nebenprodukt. Kleine Merges, Entwicklung am Hauptzweig und rote Builds sofort reparieren sind Gewohnheiten; eine gekaufte Pipeline installiert sie nicht mit.
• Tempo ohne Observability ist Glücksspiel. Ständiges Deployen ist nur sicher, wenn Sie Fehler schnell sehen – Monitoring und Alarmierung gehören zur Praxis, sie sind kein Zubehör.
• Die letzte Meile ist unterschiedlich. Datenbanken, Migrationen und zustandsbehaftete Dienste widersetzen sich dem “einfach neu deployen”; die Pipeline braucht Strategien (Expand-Contract-Migrationen, Feature Flags), die kein YAML für Sie schreibt.

CI/CD mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die Wirkung der Plattform auf CI/CD ist Subtraktion auf der Delivery-Seite: Cloud Code wird mit einem einzigen CLI-Befehl oder direkt aus einem Git-Repository deployt, und das Standard-Backend – Datenbank, Authentifizierung, APIs – taucht in Ihrer Pipeline überhaupt nicht auf, weil es dort nichts zu bauen oder zu releasen gibt. Übrig bleibt die Hälfte, die Sie behalten sollten: Ihre Tests, bei jedem Commit ausgeführt, vor einem Deploy-Schritt, der jetzt eine Zeile lang ist.