Warum brauche ich drei Umgebungen (Dev, Staging, Prod) und nicht nur zwei?
Du brauchst einen Ort, der aussieht wie Prod, aber wo niemand stirbt, wenn du etwas kaputt machst. Das ist Staging. Der Code ist in allen drei Welten gleich, nur die Konfiguration unterscheidet sich. Ohne Staging testest du entweder unrealistisch oder riskant.
Viele Nicht-Devs arbeiten am Anfang nur mit einer Umgebung: dort, wo sie gerade tippen, landen die Änderungen sofort beim Nutzer. Das funktioniert, bis das erste Mal etwas schiefgeht.
Drei Welten, drei Rollen
Dev ist zum Experimentieren. Du testest wild, machst kaputt, probierst aus. Läuft meist lokal auf deinem Laptop. Niemand merkt etwas, wenn du hier einen Fehler baust.
Staging ist die Generalprobe. Eine zweite Version unter einer Test-URL, die nur du und dein Team kennen. Sieht aus wie Prod, hat eine eigene Test-Datenbank. Hier prüfst du, ob neue Features wirklich durchlaufen.
Prod (Production) ist der echte Betrieb. Echte Nutzer, echte Daten, echte Haftung.
Warum drei und nicht zwei
Ohne Staging hast du zwei schlechte Optionen. Entweder testest du in Dev, dann ist der Test unrealistisch. Deine lokale Umgebung ist eine andere als die echte. Oder du testest direkt in Prod, dann hast du keine Generalprobe. Fehler merken die Nutzer.
Mit Staging hast du einen Ort, der aussieht wie Prod (gleiche Hosting-Konfiguration, gleiche Anbindungen, realistische Testdaten), aber nicht Prod ist. Du kannst kaputt machen, ohne dass jemand zahlt.
Umbau am bewohnten Haus
Ein Bild, das hilft: Prod ist ein bewohntes Haus. Entweder du ziehst aus und der Bagger darf rein (dann ist es nicht mehr Prod, sondern Baustelle). Oder du bleibst drin, und niemand mit einem Vorschlaghammer darf über die Schwelle. Staging ist das Zweithaus nebenan, in dem der Umbau geprobt wird, bevor er im bewohnten Haus stattfindet.
Was sich unterscheidet
Nicht der Code. Der ist in allen drei Welten identisch. Was sich unterscheidet, ist die Konfiguration: Welche Datenbank, welche API-Keys, welcher Mail-Dienst-Account. Alles über Umgebungsvariablen.
Echte Daten gehören nicht nach Dev
Nicht nur aus Risiko, auch aus DSGVO-Gründen. Eine Dev-Umgebung mit echten Kundendaten ist juristisch ein Problem, das niemand aus Versehen haben will.