Environment-Strategien: Dev, Staging, Production

Lernziele

Nach dieser Lektion kannst du eine Environment-Strategie für eine Plattform entwerfen: wie viele Umgebungen es braucht, wie Promotion zwischen ihnen funktioniert und wie du Environment-Sprawl verhinderst. Du kennst das Muster der ephemeren Preview-Umgebungen, verstehst, warum Daten — nicht Compute — das schwierige Environment-Problem sind, und kannst „Staging ist nie wie Prod” als Trade-off statt als Versäumnis diskutieren.

Das Problem: Umgebungen vermehren sich, Vertrauen nicht

Jede Organisation startet mit Dev, Staging, Production. Fünf Jahre später existieren: dev, dev2, integration, qa, staging, preprod, hotfix-env und eine Umgebung namens demo-alt, die niemand abschalten traut. Jede kostet Geld und Pflege — und trotzdem ist das Vertrauen nicht gewachsen: Releases scheitern in Production an Dingen, die keine der sieben Vorstufen gezeigt hat. Das ist Environment-Sprawl: Umgebungen entstehen als Antwort auf einzelne Vorfälle („wir brauchen eine Stufe, wo X getestet wird”), aber niemand definiert, welche Frage jede Stufe beantwortet — also beantwortet irgendwann keine mehr verlässlich irgendwas.

Der Gegenentwurf beginnt mit einer Regel: Jede Umgebung existiert, um eine bestimmte Klasse von Fehlern zu finden. Kann sie das nicht (mehr), wird sie verändert oder gelöscht.

Das Grundgerüst: wenige feste Stufen mit klarem Zweck

Ein tragfähiges Minimalmodell für die meisten Plattformen hat drei feste Stufen plus eine dynamische Klasse:

• Development — beantwortet: „Funktioniert mein Code grundsätzlich im Cluster-Kontext?” Geteilte, günstige Infrastruktur, synthetische Daten, lockere Policies. Schnelligkeit schlägt Realismus.
• Staging/Pre-Production — beantwortet: „Funktioniert das Zusammenspiel unter produktionsähnlichen Bedingungen?” So prod-nah wie bezahlbar: gleiche Kubernetes-Version, gleiche Policies (Lektionen 20–22!), gleiche Deployment-Mechanik, realistische Datenform. Hier gehören Integrationstests, Last-Stichproben und Upgrade-Proben hin.
• Production — beantwortet keine Testfrage, sondern verdient Geld. Aber: Moderne Strategien testen auch hier, kontrolliert — Canary-Releases und Feature Flags verschieben einen Teil der Verifikation dorthin, wo die Realität ist. Das relativiert den Druck, Staging perfekt zu machen.
• Ephemere Preview-Umgebungen — die dynamische Klasse: pro Pull Request entsteht automatisch eine Kurzzeit-Umgebung (Namespace oder vCluster, Lektion 20), die CI deployt den PR-Stand, Reviewer klicken eine echte URL, nach dem Merge wird alles gelöscht. Das beantwortet „funktioniert diese Änderung?” früher und billiger als jede feste Integrationsumgebung — und ersetzt in vielen Organisationen zwei bis drei der gewucherten festen Stufen.

Aus Plattform-Sicht ist entscheidend: Umgebungen sind ein Plattform-Produkt mit Lifecycle — Self-Service-Erzeugung (Lektion 16), TTL und automatisches Aufräumen, Kostenzuordnung (Lektion 21). Eine Umgebung, die niemand löschen kann, ist ein Plattform-Versäumnis, kein Team-Versäumnis.

Promotion: dieselbe Artefakt-Identität wandert durch die Stufen

Wie kommt eine Änderung von Dev nach Production? Zwei Prinzipien tragen den ganzen Mechanismus:

Build once, deploy many. Das Container-Image wird genau einmal gebaut und per Digest (nicht per beweglichem Tag wie latest oder gar Neu-Build pro Stufe) durch die Umgebungen promoted. Nur dann ist „in Staging getestet” eine Aussage über das, was in Production läuft.

Promotion ist ein Git-Commit. Im GitOps-Modell (Lektion 25 vertieft das) hat jede Umgebung ihren deklarierten Zustand im Repo — pro Umgebung ein Verzeichnis (oder Branch, Verzeichnisse sind meist die einfachere Wahl) mit umgebungsspezifischen Werten über einer gemeinsamen Basis (Kustomize-Overlays oder Helm-Values):

deploy/
├── base/                  # gemeinsame Manifeste
├── envs/
│   ├── dev/values.yaml        # image: app@sha256:abc..., replicas: 1
│   ├── staging/values.yaml    # image: app@sha256:abc..., replicas: 3
│   └── prod/values.yaml       # image: app@sha256:abc..., replicas: 6

Promotion = ein Commit/PR, der den Image-Digest (und ggf. Config) von staging/ nach prod/ überträgt — automatisiert durch die Pipeline nach bestandenen Checks, mit menschlichem Approval nur dort, wo es Governance verlangt. Damit ist die gesamte Release-Historie ein Git-Log: auditierbar, diffbar, per Revert rückrollbar.

Die Gates pro Stufe sollten so automatisiert wie möglich sein: Tests und Policy-Checks vor Staging, Smoke-Tests und Metrik-Verifikation (im Canary-Fall automatisiert ausgewertet) vor und nach Prod. Ein manuelles Approval ist legitim als bewusste Governance-Entscheidung — aber nicht als Ersatz für fehlende automatische Verifikation.

Daten: das eigentlich schwere Environment-Problem

Compute und Konfiguration zu duplizieren ist gelöst — Daten nicht. Drei Probleme, drei Strategien:

Realismus: Tests gegen eine leere Datenbank finden keine Mengen- oder Datenform-Probleme. Optionen mit steigendem Aufwand: synthetische Generatoren (gut für Form, schwach für Verteilungs-Realismus), maskierte/anonymisierte Produktionskopien (realistisch, aber die Anonymisierung muss nachweisbar sein — bei personenbezogenen Daten ist eine unmaskierte Prod-Kopie in Staging ein DSGVO-Verstoß, kein Pragmatismus), und Subset-Verfahren (referenziell konsistente Ausschnitte statt Vollkopien — schneller und billiger).

Isolation: Nicht-Prod-Umgebungen dürfen niemals auf Produktionsdaten oder Produktions-Endpunkte zeigen. Das klingt selbstverständlich und ist die Ursache erstaunlich vieler Incidents („der Lasttest lief gegen die Prod-Queue”). Technisch absichern, nicht nur dokumentieren: getrennte Credentials, getrennte Netzwerkrouten (Lektion 22), Egress-Policies, die Cross-Environment-Zugriffe blockieren.

Stateful-Promotion: Schema-Migrationen wandern mit dem Code durch die Stufen (Migrations-Tools, expand-contract-Muster), aber die Inhalte wandern nie aufwärts. Preview-Umgebungen brauchen deshalb eine Seed-Strategie — ein kleiner, versionierter Beispieldatensatz im Repo ist oft wertvoller als jede Kopier-Maschinerie.

Praxis: Promotion-Struktur und Preview-Konzept bauen

1. Promotion-Repo aufsetzen: Baue die Verzeichnisstruktur von oben mit Kustomize nach (Base plus drei Overlays, Image per Digest referenziert). Simuliere eine Promotion als Commit und prüfe das Diff:

kustomize build deploy/envs/staging > staging.yaml
kustomize build deploy/envs/prod > prod.yaml
diff <(kustomize build deploy/envs/staging) <(kustomize build deploy/envs/prod)
# Erwartung: Unterschiede NUR in Replicas/Ressourcen/Hostnamen — nicht im Image-Digest

Genau dieses Diff ist im Betrieb dein Review-Artefakt: Es macht sichtbar, dass Umgebungen sich nur in deklarierten Parametern unterscheiden.

2. Environment-Inventur (Papierübung): Liste für eine reale oder fiktive Organisation alle Umgebungen mit je einem Satz: „Diese Umgebung findet Fehlerklasse X.” Jede Umgebung ohne überzeugenden Satz ist ein Lösch- oder Merge-Kandidat — und die Liste selbst ist ein starkes Interview-Artefakt.

3. Preview-Design: Skizziere den Lebenszyklus einer PR-Umgebung: Trigger (PR open), Erzeugung (Namespace oder vCluster? Begründe anhand Lektion 20), Daten-Seed, URL-Schema, Abriss (PR merged/closed plus TTL als Fangnetz), Kosten-Label.

Typische Stolperfallen

Staging als Müllhalde: Wenn Staging dauerhaft kaputt, überbucht oder konfigurativ Jahre hinter Prod ist, testet dort niemand mehr ernsthaft — die Stufe kostet, ohne ihre Fehlerklasse zu finden. Staging braucht denselben Konfigurationsstand (Policies, Versionen, Mechanik) wie Prod, sonst lieber ehrlich abschaffen und in Preview-Umgebungen plus Canary investieren.

Pro Stufe neu bauen: Wer pro Umgebung neu kompiliert oder Images per latest-Tag zieht, testet in jeder Stufe ein anderes Artefakt. Digest-Pinning ist die billigste Maßnahme mit der größten Vertrauenswirkung.

Preview-Umgebungen ohne Abriss-Automatik: Ohne TTL und Merge-Trigger sammeln sich hunderte Zombie-Namespaces — der Sprawl kehrt dynamisch zurück, nur schneller. Aufräumen ist Teil des Features, nicht Nacharbeit.

Config-Drift zwischen den Stufen: Wenn Prod-Werte direkt in Prod editiert werden statt durch die Promotion zu wandern, divergieren die Umgebungen unbemerkt — und Staging-Grün wird bedeutungslos. Alle Umgebungs-Unterschiede gehören als deklarierte Overlay-Parameter ins Repo.

Interview-Vorbereitung

Auf „Wie würdest du die Environment-Strategie einer Plattform gestalten?” antwortest du: Prinzip (jede Stufe findet eine definierte Fehlerklasse — sonst weg damit; Sprawl entsteht durch zwecklose Stufen) → Gerüst (Dev geteilt und schnell, Staging prod-gleich in Mechanik und Policies, Prod mit Canary/Flags als kontrollierte letzte Teststufe, Preview-Umgebungen pro PR als dynamische Klasse) → Promotion (build once, Digest-Promotion als Git-Commit durch Umgebungs-Overlays, automatisierte Gates) → Daten (anonymisierte Subsets statt Prod-Kopien, harte Isolation zwischen Stufen, Seeds für ephemere Umgebungen).

Wahrscheinliche Follow-ups:

• „Wie identisch muss Staging mit Production sein?” — identisch in Mechanik, Versionen und Policies; skaliert in Kapazität. Die verbleibende Lücke ehrlich benennen und durch Canary-Verifikation in Prod kompensieren.
• „Umgebungen als Namespaces oder als Cluster?” — Prod von Non-Prod auf Cluster-Ebene trennen (Blast Radius, Upgrade-Proben); innerhalb Non-Prod sind Namespaces/vCluster meist ausreichend und billiger — Verweis auf die Isolations-Dimensionen aus Lektion 20.
• „Wie funktioniert Rollback in diesem Modell?” — Git-Revert des Promotion-Commits, der GitOps-Controller stellt den vorherigen Zustand her; Daten-Rollback ist separat und der eigentlich schwere Teil (Migrations-Strategie).
• „Was bringt eine Preview-Umgebung gegenüber einer festen Integrationsumgebung?” — Isolation pro Änderung (keine gegenseitige Störung), automatischer Lifecycle, Kosten nur bei Bedarf — und sie verschiebt Feedback an den frühestmöglichen Punkt.

Zusammenfassung

Eine Environment-Strategie ist Zweck-Architektur: wenige feste Stufen, jede mit definierter Fehlerklasse, ergänzt um ephemere Preview-Umgebungen mit automatischem Lifecycle. Promotion heißt: ein einmal gebautes Artefakt wandert per Digest und Git-Commit durch deklarierte Umgebungs-Overlays — auditierbar, diffbar, revertierbar. Das harte Problem sind Daten: realistisch durch anonymisierte Subsets, sicher durch technische Isolation zwischen den Stufen.

Wie viele Umgebungen du auch betreibst — sie alle brauchen Kapazität, und zwar geplant statt geraten. Die nächste Lektion behandelt Capacity Planning: Forecasting, Headroom und Cluster-Sizing auf Plattform-Ebene.