Development, Staging und Production: Umgebungen erklärt

"Warum nicht einfach direkt auf dem Live-Server testen?" – diese Frage stellt sich am Anfang jeder. Die Antwort: Ein Fehler in der Produktion trifft echte Nutzer und kann teuer werden. Deshalb arbeitet man mit mehreren Umgebungen. In diesem Beitrag erkläre ich dir, was Development, Staging und Production unterscheidet und wie du sie sauber trennst.

Was ist eine Umgebung?

Eine Umgebung (englisch environment) ist ein abgegrenzter Bereich, in dem deine Anwendung läuft – mit eigener Datenbank, eigener Konfiguration und eigenen Zugängen. Dieselbe Software läuft in jeder Umgebung, aber mit unterschiedlichen Einstellungen. So kannst du gefahrlos entwickeln und testen, bevor echte Nutzer betroffen sind.

Die drei klassischen Umgebungen

In den meisten Projekten findest du diese drei Stufen:

• Development: deine lokale Umgebung zum Entwickeln. Hier darf alles kaputtgehen.
• Staging: ein möglichst exaktes Abbild der Produktion zum finalen Testen.
• Production: die Live-Umgebung, die echte Nutzer verwenden.

Code wandert immer in dieselbe Richtung: von Development über Staging nach Production. Niemals andersherum.

Warum Staging so wichtig ist

Development läuft auf deinem Laptop – mit Testdaten und oft anderen Versionen als der Live-Server. Genau deshalb gibt es Staging: eine Umgebung, die der Produktion so ähnlich wie möglich ist. Hier testest du mit realistischen Daten und Konfigurationen, bevor du live gehst. Viele Probleme, die lokal nie auftreten, zeigen sich erst hier – und das ist gut so.

Konfiguration über Umgebungsvariablen

Der Schlüssel zu sauberen Umgebungen sind Umgebungsvariablen. Statt Werte im Code festzuschreiben, liest deine Anwendung sie aus der Umgebung. So nutzt jede Umgebung dieselbe Code-Basis, aber andere Einstellungen. Für jede Umgebung legst du eine eigene Datei an:

# .env.development
DATABASE_URL=postgres://localhost:5432/app_dev
LOG_LEVEL=debug

# .env.production
DATABASE_URL=postgres://db.example.com:5432/app_prod
LOG_LEVEL=error

In der Anwendung liest du die Werte dann aus, hier ein Beispiel in Node.js:

# Umgebung beim Start setzen
NODE_ENV=production node server.js

Im Code greifst du über process.env.DATABASE_URL darauf zu. So bleibt deine Code-Basis identisch, egal wo sie läuft.

Umgebungen mit Docker abbilden

Mit Docker Compose lassen sich Umgebungen elegant unterscheiden. Du nutzt eine Basis-Datei und überschreibst Werte je Umgebung. Beim Start gibst du an, welche Variablendatei gelten soll:

# Mit der Staging-Konfiguration starten
docker compose --env-file .env.staging up -d

# Mit der Production-Konfiguration starten
docker compose --env-file .env.production up -d

So startest du dieselbe Anwendung in verschiedenen Umgebungen, ohne den Code anzufassen – nur die Konfiguration ändert sich.

Best Practices für saubere Umgebungen

Ein paar Regeln ersparen dir viel Ärger:

• Niemals mit Produktionsdaten lokal arbeiten: nutze anonymisierte Testdaten.
• Staging muss der Produktion ähneln: gleiche Versionen, gleiche Konfiguration.
• Geheimnisse trennen: jede Umgebung hat eigene Zugänge und Schlüssel.
• Automatisch deployen: nutze eine Pipeline, statt Dateien von Hand zu kopieren.

Besonders die letzte Regel zahlt sich aus: Ein automatischer Ablauf vergisst keinen Schritt.

Fazit

Getrennte Umgebungen schützen deine Nutzer vor halbfertigem Code. In Development entwickelst du frei, in Staging testest du unter realistischen Bedingungen, und Production ist der geschützte Live-Bereich. Der Schlüssel sind Umgebungsvariablen, die dieselbe Code-Basis je nach Umgebung anders konfigurieren. Richte als Nächstes für eines deiner Projekte eine getrennte Development- und Staging-Umgebung ein – du wirst entspannter deployen, wenn du weißt, dass alles vorher geprüft wurde.