06 — Continuous Delivery und Deployment

Teil C — Wie man ausliefert. Zurück zur Übersicht.

Continuous Integration
  Code wird laufend zusammengeführt, gebaut und getestet.
  Ergebnis: ein geprüftes Artefakt.
         │
         ▼
Continuous Delivery
  Das Artefakt ist jederzeit auslieferbar.
  Der Weg in die Produktion ist automatisiert und erprobt.
  Ausgelöst wird er durch einen Menschen.
         │
         ▼
Continuous Deployment
  Jede Änderung, die alle Prüfungen besteht, geht automatisch
  in Produktion. Ohne Knopfdruck.

Das vielleicht wichtigste technische Prinzip dieses Kapitels.

   FALSCH                              RICHTIG

   Code ──► Build ──► Test-Umgebung    Code ──► Build ──► Artefakt
   Code ──► Build ──► Abnahme                             │
   Code ──► Build ──► Produktion                          ├──► Test
                                                          ├──► Abnahme
   Drei verschiedene Ergebnisse.                          └──► Produktion
   Getestet wurde nie das,
   was produktiv läuft.                 Ein Artefakt. Überall dasselbe.

Wird für jede Umgebung neu gebaut, hat man drei verschiedene Artefakte. Zwischen dem Bauen für die Abnahme und dem Bauen für die Produktion kann sich eine Abhängigkeit aktualisiert haben, ein Basis-Image geändert, ein Zeitstempel unterschieden. Getestet wurde dann streng genommen etwas anderes als das, was in Produktion läuft — und genau dieser Unterschied ist die Sorte Fehler, die man am Freitagabend sucht.

Die Konsequenz: Die Konfiguration darf nicht im Artefakt stecken. Sie kommt von außen.

# Dasselbe Image, drei Umgebungen
podman run -e DB_HOST=db-test.intern    kfz-rechner:2.4.0
podman run -e DB_HOST=db-abnahme.intern kfz-rechner:2.4.0
podman run -e DB_HOST=db-prod.intern    kfz-rechner:2.4.0

Dieses Prinzip stammt aus der Zwölf-Faktoren-Methodik, deren dritter Punkt genau das fordert: Konfiguration gehört in die Umgebung, nicht in den Code.

Zwei Begriffe, die im Alltag synonym gebraucht werden, obwohl ihre Trennung eine der wirkungsvollsten Techniken überhaupt ist.

Solange beides zusammenfällt, ist jede Auslieferung ein Ereignis mit Publikum. Entkoppelt man sie, wird das Deployment zum Nichtereignis:

# Die Funktion ist ausgerollt, aber abgeschaltet
if feature_aktiv("wenigfahrer_rabatt"):
    beitrag = wende_wenigfahrer_rabatt_an(beitrag)

Der Code geht am Dienstag in Produktion, ohne dass ihn jemand bemerkt. Am Donnerstag schaltet der Fachbereich die Funktion frei — für zunächst fünf Prozent der Anfragen. Fällt etwas auf, wird sie ausgeschaltet. Das dauert Sekunden und braucht kein Deployment, kein Wartungsfenster und keine Nachtschicht.

Mehr zu Feature Flags in Kapitel 8.

Vollständige Umgebungsparität ist dabei eine Illusion — die Produktion hat mehr Last, mehr Daten, echte Netzwerke und echte Anwender. Ziel ist nicht Gleichheit, sondern kontrollierte, bekannte Unterschiede. Ein Unterschied, den man kennt und dokumentiert hat, ist beherrschbar. Einer, den man erst im Störungsfall entdeckt, nicht.

Anwendungscode lässt sich in Sekunden austauschen und ebenso schnell zurückrollen. Bei Datenbanken gilt das nicht: Eine gelöschte Spalte ist gelöscht, und die Daten darin sind es auch.

Das ist der Punkt, an dem Continuous Delivery in der Praxis am häufigsten scheitert.

Die Lösung besteht darin, Schemaänderungen in mehrere rückwärtskompatible Schritte zu zerlegen.

Aufgabenstellung: Die Spalte sf_klasse soll in schadenfreiheitsklasse umbenannt werden.

Schritt 1 — Erweitern (expand)
  Neue Spalte ergänzen. Die alte bleibt.
  ALTER TABLE vertrag ADD COLUMN schadenfreiheitsklasse INT;
  → Alte und neue Anwendungsversion funktionieren beide.

Schritt 2 — Doppelt schreiben
  Anwendung schreibt in beide Spalten, liest aus der alten.
  → Ausrollbar und zurückrollbar.

Schritt 3 — Daten übertragen
  UPDATE vertrag SET schadenfreiheitsklasse = sf_klasse
   WHERE schadenfreiheitsklasse IS NULL;

Schritt 4 — Umschalten
  Anwendung liest aus der neuen Spalte, schreibt weiter beide.
  → Immer noch zurückrollbar.

Schritt 5 — Zusammenziehen (contract)
  Erst wenn keine alte Version mehr läuft:
  ALTER TABLE vertrag DROP COLUMN sf_klasse;

Fünf Auslieferungen statt einer. Dafür ist jede einzelne davon gefahrlos und jederzeit zurücknehmbar.

Migrationen gehören dabei genauso in die Versionsverwaltung wie der Code — mit Werkzeugen wie Flyway, Liquibase oder Alembic, die durchnummerierte, einmalig ausgeführte Skripte verwalten.

.gitlab-ci.yml

stages:
  - pruefen
  - testen
  - bauen
  - ausrollen-test
  - ausrollen-prod

variables:
  IMAGE: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
 
# ... Stufen aus Kapitel 5 ...

ausrollen-test:
  stage: ausrollen-test
  environment:
    name: test
    url: https://kfz-test.intern
  script:
    - ./scripts/deploy.sh test "$IMAGE"
    - ./scripts/smoketest.sh https://kfz-test.intern
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

ausrollen-prod:
  stage: ausrollen-prod
  environment:
    name: produktion
    url: https://kfz.intern
  script:
    - ./scripts/deploy.sh produktion "$IMAGE"
    - ./scripts/smoketest.sh https://kfz.intern
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual            # <- genau hier liegt der Unterschied
  allow_failure: false

Beachte die Zeile when: manual. Sie ist der gesamte Unterschied zwischen Continuous Delivery und Continuous Deployment. Nimmt man sie heraus, rollt jede geprüfte Änderung automatisch aus.

Der Rauchtest danach ist keine Formalie, sondern die Zusage, dass die neue Version tatsächlich antwortet:

scripts/smoketest.sh

#!/usr/bin/env bash
set -euo pipefail
 
URL="$1"
VERSUCHE=30
 
for i in $(seq 1 "$VERSUCHE"); do
    if curl -fsS --max-time 5 "${URL}/health" > /dev/null; then
        echo "Dienst antwortet nach ${i} Versuch(en)."
 
        # Fachliche Stichprobe: bekannter Eingabewert, bekanntes Ergebnis
        ergebnis=$(curl -fsS "${URL}/api/praemie?sf=5&alter=3" | jq -r '.betrag')
        if [[ "$ergebnis" != "288.00" ]]; then
            echo "FEHLER: Erwartet 288.00, erhalten ${ergebnis}"
            exit 1
        fi
        echo "Fachliche Prüfung bestanden."
        exit 0
    fi
    sleep 2
done
 
echo "FEHLER: Dienst antwortet nach ${VERSUCHE} Versuchen nicht."
exit 1

Aufgaben:

1. Ergänze eine Abnahmeumgebung zwischen Test und Produktion.
2. Sorge dafür, dass in allen Umgebungen dasselbe Image mit unterschiedlicher Konfiguration läuft.
3. Lass den Rauchtest absichtlich fehlschlagen und prüfe, dass die Pipeline rot wird.
4. Formuliere in einem Satz, was passieren muss, damit ihr when: manual streichen könnt.

Wenn ihr euer Produktivsystem heute Abend verlieren würdet — wie lange bräuchtet ihr, um es aus dem Repository heraus neu aufzubauen? Und wisst ihr das aus Erfahrung oder aus Vermutung?

Weiter mit Kapitel 07 — Pipeline in der Praxis