CI/CD-Pipelines und Deployment-Strategien

Vom Commit bis in die Produktion: wozu eine Pipeline da ist

Abschnitt 0.8 (Wie Software entsteht) hat Continuous Integration (jede Änderung wird automatisch zusammengeführt und geprüft), Continuous Delivery (der Hauptbranch ist jederzeit releasefähig) und Continuous Deployment (jede Änderung, die die Prüfungen besteht, geht ohne menschliche Entscheidung in Produktion) eingeführt. Dieser Abschnitt behandelt sie als Architektur: als Gestaltung des Wegs, den eine Änderung nimmt, und der Strategien, die sie in Produktion bringen, ohne Nutzern zu schaden.

Die zentrale Idee ist die Deployment-Pipeline, beschrieben von Jez Humble und David Farley in Continuous Delivery (2010). Jeder Commit löst eine automatisierte Folge von Stufen aus. Frühe Stufen sind schnell und günstig und fangen die meisten Probleme ab; spätere Stufen sind langsamer, realistischer und teurer. Eine Änderung gelangt nur dann in die nächste Stufe, wenn die vorige bestanden wurde; je weiter ein Build kommt, desto mehr Vertrauen hat er sich also verdient. Ein Fehlschlag an beliebiger Stelle stoppt diesen Build und geht direkt an die Person zurück, die die Änderung gemacht hat, solange sie ihr noch frisch im Gedächtnis ist.

Für Architekten ist die Pipeline aus drei Gründen wichtig. Erstens wird hier die Deploybarkeit, ein Qualitätsmerkmal aus Abschnitt 2.6, tatsächlich erreicht oder verspielt. Zweitens begrenzt ihre Geschwindigkeit, wie schnell die Organisation auf eine Marktveränderung oder eine Sicherheitslücke reagieren kann: Braucht ein einzeiliger Fix zwei Tage bis in die Produktion, ist die Architektur zwei Tage langsam, wie auch immer der Code aussieht. Drittens bestimmt die Gestalt des Systems die Gestalt der Pipeline: Unabhängig deploybare Services können unabhängige Pipelines haben, aber ein verteilter Monolith erzwingt koordinierte Releases, wie clever die Werkzeuge auch sein mögen.

Build once, deploy many und das Artefakt-Repository

Eine Regel aus Continuous Delivery, die noch immer erstaunlich oft verletzt wird, lautet Build once, deploy many: Jede Änderung genau einmal kompilieren und verpacken und dann dasselbe Artefakt durch jede Umgebung weiterreichen. Baut ein Team für Staging und noch einmal für die Produktion, ist das Getestete nicht das Ausgelieferte. Ein anderer Compiler-Patch, eine über Nacht auf eine neuere Version aufgelöste Abhängigkeit oder ein geändertes Basis-Image können die beiden Builds unterscheiden, und die Tests beweisen nichts über den zweiten.

Was sich zwischen Umgebungen unterscheidet, ist die Konfiguration, die beim Deployment oder beim Start übergeben wird (Datenbankadressen, Zugangsdaten, Feature-Flag-Einstellungen) und nie in das Artefakt eingebacken ist. Das ist der Konfigurationsfaktor der Twelve-Factor App. Ein Container-Image mit dem Tag orders:4f1c2ab (dem Commit-Hash) wird in Test, Staging und Produktion deployt; nur seine Umgebungsvariablen und eingebundenen Secrets ändern sich.

Das Artefakt-Repository ist der Speicher zwischen Build und Deployment: eine Container-Registry (Amazon ECR, Azure Container Registry, Google Artifact Registry, GitHub Container Registry, Harbor) oder ein universelles Repository wie JFrog Artifactory oder Sonatype Nexus für Pakete und Binärdateien. Behandeln Sie es als kritische Infrastruktur. Deployen Sie über einen unveränderlichen Digest (sha256:...) statt über ein veränderliches Tag wie latest, das auf ein anderes Image umgesetzt werden kann; bewahren Sie Artefakte, die in Produktion sind oder waren, so lange auf, wie Sie womöglich auf sie zurückrollen oder sie untersuchen müssen; und halten Sie die Herkunft (Provenance) fest, also welcher Commit, welcher Pipeline-Lauf und welche Abhängigkeiten jedes Artefakt erzeugt haben.

Trunk-Based Development und kleine Batches

Wie Code verzweigt wird, entscheidet, wie oft er wirklich integriert wird. Beim Trunk-Based Development integrieren alle mindestens täglich kleine Änderungen in einen Hauptbranch (den Trunk), entweder durch direkte Commits oder über kurzlebige Branches und Pull Requests, die Stunden statt Wochen leben. Das DORA-Forschungsprogramm hat kurzlebige Branches und häufiges Mergen wiederholt mit höherer Lieferleistung in Verbindung gebracht, und es ist eine Voraussetzung für Continuous Integration im wörtlichen Sinn: Code, der drei Wochen auf einem Branch liegt, wird nicht kontinuierlich integriert.

Langlebige Feature-Branches fühlen sich sicherer an, weil unfertige Arbeit getrennt bleibt, doch das Risiko wird nur aufgeschoben: Je länger zwei Branches auseinanderlaufen, desto größer und riskanter wird der spätere Merge und desto länger sieht die Pipeline Code, der nicht der Code ist, der ausgeliefert wird. GitFlow, ein Branching-Modell mit langlebigen Develop- und Release-Branches, das Vincent Driessen 2010 veröffentlichte, wurde breit übernommen; 2020 ergänzte Driessen einen Hinweis, dass Teams, die kontinuierlich ausliefern, etwa bei Webanwendungen, einen einfacheren Workflow erwägen sollten. Teams, die große Änderungen im Trunk vornehmen müssen, nutzen zwei Techniken: Feature-Flags, die unfertiges Verhalten verbergen, und Branch by Abstraction, das eine Schnittstelle vor die alte Implementierung setzt, die neue dahinter baut und umschaltet, sobald sie bereit ist.

An den Rändern sind sich Praktiker wirklich uneinig. Open-Source-Projekte mit vielen nicht vertrauenswürdigen Beitragenden setzen auf längerlebige Pull Requests und Reviews, und regulierte Teams brauchen für Audits manchmal explizite Release-Branches. Das Prinzip, das diese Uneinigkeit übersteht, ist die Batchgröße: Je kleiner jede Änderung, desto leichter lässt sie sich prüfen, testen, deployen, diagnostizieren und rückgängig machen.

name: delivery
on:
  push:
    branches: [main]
env:
  IMAGE: registry.example.com/food/orders:${{ github.sha }}
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make lint test              # fast feedback first
      - run: docker build -t "$IMAGE" . && docker push "$IMAGE"
  staging:
    needs: build
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh staging "$IMAGE" && ./smoke-test.sh staging
  production:
    needs: staging
    runs-on: ubuntu-latest
    environment: production            # can require an approval
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh production "$IMAGE" --canary 5

Deployment-Strategien

Eine Deployment-Strategie entscheidet, wie die neue Version die alte in der Produktion ersetzt, und damit, wie vielen Nutzern eine schlechte Version schaden kann, bevor sie gestoppt wird. Die Strategien unterscheiden sich in der zusätzlichen Infrastruktur, die sie brauchen, darin, wie schnell sie zurückrollen, und ob zwei Versionen gleichzeitig laufen. Wann immer zwei Versionen gleichzeitig laufen, müssen sie mit den Daten und Nachrichten der jeweils anderen kompatibel sein; das ist der Preis jeder Strategie außer Recreate.

Das Blue-Green-Deployment beschrieb Martin Fowler 2010 und nannte Dan North und Jez Humble als Urheber; das Canary Release, benannt nach den Kanarienvögeln, die Bergleute zum Aufspüren von Gas mitnahmen, beschrieb Danilo Sato 2014 auf derselben Website. In Kubernetes sind Rolling Updates eingebaut; Blue-Green- und Canary-Releases kommen meist von einem Progressive-Delivery-Controller (Argo Rollouts, Flagger) oder von einem Service Mesh und dem gewichteten Routing der Gateway API. Auf verwalteten Plattformen heißen die entsprechenden Funktionen Traffic Splitting oder Deployment Slots.

Deployment und Release mit Feature-Flags trennen

Deployment installiert eine neue Version der Software in einer Umgebung; Release macht ein Verhalten für Nutzer verfügbar. Behandelt man beides als ein Ereignis, wird jedes Deployment zu einem Geschäftsereignis, mit all der Nervosität, die das mit sich bringt. Feature-Flags (Feature Toggles) trennen die beiden: Der neue Code wird ausgeschaltet deployt, und das Verhalten wird später durch eine Konfigurationsänderung freigegeben, schrittweise und umkehrbar. Pete Hodgsons Artikel Feature Toggles (aka Feature Flags) auf martinfowler.com (2017) unterscheidet vier Kategorien danach, wie lange sie leben und wie dynamisch sie entscheiden.

Flags verursachen laufende Kosten. Jedes Flag verdoppelt die Pfade durch den Code, den es schützt, erhöht die Zahl der Testkombinationen und hinterlässt toten Code, sobald seine Entscheidung feststeht. Hodgson empfiehlt, Flags wie einen Lagerbestand zu behandeln: Beim Anlegen eines Release-Toggles eine Aufgabe zum Entfernen anlegen, Flags ein Ablaufdatum geben, Tests ergänzen, die fehlschlagen, sobald ein Flag sein Datum überschritten hat, und begrenzen, wie viele gleichzeitig existieren dürfen. Der Verlust von Knight Capital im Jahr 2012, beschrieben in Abschnitt 1.3, ging auf ein umfunktioniertes Flag zurück, das alten Code auf einem Server reaktivierte, der bei einem manuellen Deployment übersehen worden war: eine Mahnung, Flag-Namen nie wiederzuverwenden und toten Code hinter entschiedenen Flags zu löschen. Im großen Maßstab werden Flags von einem eigenen Dienst bereitgestellt (Open-Source-Optionen wie Unleash und Flagsmith, kommerzielle wie LaunchDarkly oder die herstellerneutrale OpenFeature-API), damit sich eine Änderung in Sekunden verbreitet und protokolliert wird.

Datenbankänderungen in der Pipeline

Code lässt sich in Sekunden zurückrollen, Daten nicht. Ein Deployment, das eine Spalte umbenennt und dann zurückgerollt wird, lässt den alten Code vor einem Schema zurück, das er nicht versteht. Die Antwort, ausführlich behandelt unter Schemaevolution, besteht darin, jede Schemaänderung abwärtskompatibel zur gerade laufenden Codeversion zu machen, mit Expand and Contract: zuerst die neue Struktur hinzufügen, Code deployen, der beide schreibt und jede liest, Daten nachfüllen (Backfill), die Leser umstellen und die alte Struktur erst in einem späteren Release entfernen, wenn nichts sie mehr nutzt.

In der Pipeline heißt das: Migrationen sind versionierte Artefakte, die als eigener Schritt laufen, bevor der Code deployt wird, der sie braucht, und sie werden an einer Kopie der Daten in Produktionsgröße getestet, damit eine Sperre auf einer großen Tabelle im Staging entdeckt wird statt zur Mittagszeit. Destruktive Schritte (Spalten oder Tabellen löschen) werden verzögert und separat ausgeführt, weil sie die einzige Art von Änderung sind, die ein Rollback nicht rückgängig machen kann. Eine nützliche Pipeline-Prüfung lässt den Build fehlschlagen, wenn eine Migration nicht additiv ist, es sei denn, sie ist ausdrücklich als Contract-Schritt gekennzeichnet.

Progressive Delivery und automatisierte Canary-Analyse

Progressive Delivery, ein Begriff, den James Governor vom Analystenhaus RedMonk 2018 populär machte, verbindet Canaries, Feature-Flags und automatisierte Prüfung: Eine Änderung erreicht schrittweise größere Zielgruppen, und bei jedem Schritt entscheidet das System, nicht eine Person vor Dashboards, ob es weitergeht. Die Entscheidung nutzt die automatisierte Canary-Analyse: Die Metriken des Canary (Fehlerrate, Latenzperzentile, Sättigung, Geschäftssignale wie aufgegebene Bestellungen) werden statistisch mit einer Baseline verglichen. Netflix und Google haben ihre Analyse-Engine Kayenta 2018 als Open Source veröffentlicht; Argo Rollouts und Flagger bieten in Kubernetes ähnliche Analyseschritte.

Drei Details entscheiden, ob man der Analyse trauen kann. Vergleichen Sie Gleiches mit Gleichem: Eine frische Baseline der alten Version, die denselben Traffic-Anteil erhält, verhindert, dass der neuen Version Unterschiede angelastet werden, die von kalten Caches oder kürzlichen Neustarts herrühren. Sorgen Sie für genug Traffic: Bei 5 % eines Service mit zehn Anfragen pro Minute sieht eine Stunde Canary dreißig Anfragen, zu wenige, um eine Fehlerrate von 1 % zu erkennen; Services mit wenig Traffic brauchen daher längere Schritte, synthetische Last oder eine andere Strategie. Wählen Sie Metriken, die an die Service Level Objectives und an Geschäftsergebnisse gebunden sind, denn eine Version kann schnell und fehlerfrei sein und dabei still die falsche Liefergebühr berechnen.

Rollback oder Roll-forward

Wenn ein Release schiefgeht, gibt es zwei Auswege. Ein Rollback kehrt zum vorherigen Artefakt zurück; das ist schnell und braucht keinen neuen Code, sofern die vorherige Version noch mit den aktuellen Daten und den Versionen anderer Services funktioniert. Ein Roll-forward liefert eine Korrektur über die Pipeline aus; das ist langsamer, aber manchmal die einzige Option, etwa nach einer nicht umkehrbaren Datenmigration oder einer Änderung, von der andere Services bereits abhängen.

Eine vernünftige Grundregel lautet erst zurückrollen, später diagnostizieren: den Dienst mit der schnellsten sicheren Maßnahme wiederherstellen und dann ohne Druck untersuchen. Ein Roll-forward unter Druck umgeht tendenziell die Prüfungen der Pipeline, und eine überhastete Korrektur eines Produktionsincidents ist eine klassische Quelle des nächsten Incidents. Ein Rollback ist nur dann eine echte Option, wenn er eingeplant ist: frühere Artefakte aufbewahrt, Schemaänderungen für mindestens eine Version in beide Richtungen kompatibel, Nachrichten für alte und neue Consumer lesbar und der Rollback-Pfad selbst regelmäßig geübt. Ein Team, das noch nie zurückgerollt hat, sollte davon ausgehen, dass es das nicht kann.

Die Pipeline messen

Die in Abschnitt 2.6 eingeführten DORA-Metriken für die Softwareauslieferung (Change Lead Time, Deployment-Häufigkeit, Change Fail Rate, Wiederherstellungszeit nach fehlgeschlagenem Deployment und Deployment-Rework-Rate) sind größtenteils Eigenschaften von Pipeline und Architektur zusammen. Kleine Batches und Trunk-Based Development verkürzen die Lead Time und erhöhen die Häufigkeit; automatisierte Tests und Canary-Analyse senken die Change Fail Rate; schnelles Rollback und Flags verkürzen die Wiederherstellungszeit. Messen Sie sie pro Service, beobachten Sie Trends statt Einzelwerte, und machen Sie sie nie zu Zielvorgaben für Einzelpersonen; das lädt nur zum Schönen der Zahlen ein.