Umgebungen: Entwicklung, Test, Staging, Produktion

Software wird nicht direkt von „auf meinem Laptop programmiert" auf „läuft live für Millionen User" deployed. Dazwischen liegen mehrere Umgebungen (Environments), durch die der Code wandert: Development → Test → Staging → Production. Jede Umgebung hat einen eigenen Zweck, eigene Charakteristika und unterschiedliche Risiko-Profile.

Diese Lektion zeigt, wie man Umgebungen sauber organisiert: was gehört in welche Stufe, wie unterscheiden sie sich, wie wandert Code (Promotion) durch sie hindurch, wie verwaltet man die Konfiguration pro Umgebung. Plus: die wichtigsten Prinzipien der „Twelve-Factor App" für moderne Software.

1) Warum überhaupt mehrere Umgebungen?

Die naive Antwort: „Damit man's vorher testen kann, bevor man's auf Production deployed." Stimmt. Aber es geht um mehr. Verschiedene Umgebungen lösen verschiedene Probleme:

• Sicherheit für Production: Bugs sollen in Production nicht ankommen
• Realistische Tests: lokale Entwicklung simuliert die Wirklichkeit selten gut
• Isolation: Entwickler-Experimente beeinflussen nicht Tester oder Endkunden
• Lasttests: Performance unter Last prüfen ohne echte User zu beeinträchtigen
• Abnahme: Stakeholder können neue Features testen, bevor Release
• Schulung: User-Schulungen brauchen eine Umgebung ohne Echtdaten
• Disaster-Tests: Notfall-Übungen ohne echte Folgen

Daher gibt es typischerweise vier (manchmal mehr) Umgebungen, die wir uns gleich anschauen.

2) Die vier klassischen Umgebungen

Hier die typische Aufteilung – von der „Spielwiese" bis zum „Live-System":

3) Promotion: Code wandert durch die Umgebungen

Code geht nicht direkt von Dev nach Prod. Er wandert Stufe für Stufe – das nennt man Promotion. Bei jeder Stufe wird geprüft, ob alles passt, bevor die nächste Stufe folgt:

4) Konfiguration pro Umgebung

Code ist überall gleich, aber Konfiguration unterscheidet sich pro Umgebung. Datenbankverbindung, API-URLs, Lizenzschlüssel, Feature-Flags – alles muss pro Stufe richtig gesetzt sein:

5) Twelve-Factor App: Best Practices für moderne Apps

Heroku hat 2011 die Twelve-Factor App-Methodik vorgestellt – Best Practices für Cloud-native Apps. Zwei der 12 Faktoren sind direkt relevant für Umgebungen:

6) Beispiel: 12-Factor-Konfiguration

Hier ein konkretes Beispiel wie eine App die Twelve-Factor-Prinzipien umsetzt. In Node.js:

Pro Umgebung wird die App anders gestartet – mit anderen Werten:

7) Wo werden Konfigs verwaltet?

In der Praxis kommen die Environment-Variablen aus verschiedenen Quellen. Hier die wichtigsten:

Wichtigste Regel: Secrets nie in Git. Auch keine .env mit Passwörtern. Stattdessen ein Secret-Management-System nutzen.

8) Datenbank-Strategien pro Umgebung

Datenbanken sind heikel – sie haben Zustand. Wie organisiert man DBs pro Umgebung?

• Dev: lokale DB auf dem Laptop (z.B. SQLite, oder Postgres in Docker). Jeder Dev hat eigene Daten.
• Test: ephemere DB die für jeden Test-Run frisch aufgesetzt wird. TestContainers ist Standard.
• Staging: oft anonymisierte Kopie der Production-DB. Echte Strukturen, aber Namen/E-Mails maskiert (Datenschutz!).
• Production: die echte DB mit echten Daten. Hochverfügbar, regelmäßig gesichert.

Wichtig wegen DSGVO: niemals echte personenbezogene Daten in Test/Staging ohne Anonymisierung. Mehr in K05 DSGVO. Tools wie pg_dump + anonymizer oder kommerzielle Lösungen erledigen das.

9) Branch-Strategien und Umgebungen

Wie hängen Git-Branches und Umgebungen zusammen? Es gibt verschiedene Modelle:

• GitFlow-Stil: develop → DEV/TEST, release/* → STAGING, main → PROD
• Trunk-Based: jeder Commit auf main geht durch alle Stufen (mit Feature Flags steuerbar)
• Environment-Branches: ein Branch pro Stufe (dev, staging, main) – Merge promotet
• Tag-basiert: nur getaggte Versionen werden in Prod deployed (v1.2.3)

Heute am beliebtesten: Trunk-Based Development + Tags. Ein einziger Hauptbranch, Tags markieren was wo deployed wird. Mehr in K54 Git.

10) Ephemere Umgebungen: Preview-Deployments

Ein modernes Pattern: ephemere Umgebungen (auch „Preview Environments"). Für jeden Pull Request entsteht automatisch eine eigene Umgebung, in der die Änderungen testbar sind. Nach dem Merge wird sie gelöscht.

Vorteile:

• Reviewer können das Feature live ausprobieren, nicht nur Code lesen
• QA testet die exakten Änderungen, nicht nur die ganze Suite
• Stakeholder geben Feedback zur Funktionalität, nicht nur zu Mockups
• Bei Merge → Umgebung weg, keine Kosten mehr

Plattformen wie Vercel, Netlify, Render machen das automatisch für Webapps. In Kubernetes mit Tools wie Argo CD oder eigenen Pipelines möglich. Mit Terraform kannst du das auch selbst bauen – pro PR eine kleine Umgebung erstellen, am Ende destroy.

11) Best Practices

Aus der Praxis – was du beachten solltest:

• Mindestens 3 Umgebungen: Dev, Staging, Prod – weniger ist ein Sicherheitsrisiko
• Staging möglichst nah an Prod: gleiche Versionen, gleiche Größenordnung, gleiches OS
• Echte Daten anonymisieren wenn sie in niedrigere Stufen kopiert werden (DSGVO!)
• Dasselbe Artefakt promoten, nicht in jeder Stufe neu bauen (sonst Drift möglich)
• Konfiguration aus Env-Variablen, nicht hartkodiert
• Secrets in Secret-Manager, niemals in Git
• Smoke Tests nach jedem Deploy in jeder Stufe
• Rollback-Plan für jede Stufe – besonders Prod
• Klare Promotion-Kriterien: was muss erfüllt sein um eine Stufe weiter zu kommen?
• Monitoring & Alerting abgestuft (Prod most, Dev least)
• Kosten beachten: Staging-Umgebung kann viel Geld kosten – nachts runterfahren
• Dokumentation: was läuft wo? Welche Versionen? Welche URLs?

12) Beispiel-Workflow für ein neues Feature

Schauen wir uns konkret an, wie eine Code-Änderung den Weg durch die Umgebungen geht:

1. Dev: Anna entwickelt das Feature lokal auf ihrem Laptop. npm run dev, lokale DB, lokale APIs. Mock für Payment.
2. Pull Request: Anna pusht ihren Branch zu GitHub. Eröffnet PR.
3. Preview-Env: Pipeline baut automatisch eine ephemere Umgebung mit Annas Code. Reviewer können sie unter pr-1234.preview.firma.de erreichen.
4. Tests in CI: Pipeline läuft Unit/Integration-Tests, alle grün.
5. Code-Review: Kollegen reviewen Code und testen die Preview-URL.
6. Merge in main: PR ist approved. Wird gemerged. Preview-Umgebung wird automatisch zerstört.
7. Staging-Deploy: Pipeline deployt main automatisch nach Staging. UAT durch Product Owner.
8. Approval: Product Owner gibt grünes Licht in der Pipeline-UI.
9. Production-Deploy: Pipeline läuft Canary-Deploy – erst 5% Traffic, dann ausweiten.
10. Monitoring: Team beobachtet Metriken. Bei Problemen: Rollback. Bei Erfolg: 100% Traffic.

Dieser Workflow dauert je nach Komplexität wenige Minuten bis Stunden. Aber er garantiert: kein Bug kommt einfach so in Prod. Mehrere Schichten von Sicherheit.

Zusammenfassung

Mehrere Umgebungen (Dev, Test, Staging, Prod) trennen Entwicklung von Production-Betrieb. DEV: lokales Entwickeln, kann brechen. TEST: automatisierte Tests in CI. STAGING: Production-ähnlich, letzter Stopp, UAT. PROD: Live mit echten Usern. Promotion: Code wandert Stufe für Stufe durch Quality Gates. Konfiguration pro Umgebung via Environment-Variablen (Twelve-Factor App III). Secrets niemals in Git – Secret-Manager nutzen. Datenbanken: lokale DB in Dev, anonymisierte Kopie in Staging, echte in Prod (DSGVO!). Branch-Strategien: Trunk-Based heute am beliebtesten. Ephemere Umgebungen: pro PR eine eigene Preview-URL. Best Practices: dasselbe Artefakt promoten, klare Gates, Smoke Tests, Rollback-Pläne, Monitoring abgestuft. Sauberes Environment-Management ist ein zentrales DevOps-Skill.