Staging-Umgebung einrichten: Sinnvoll für jedes Update, das Sie nicht zurückrollen wollen

Eine Staging-Umgebung ist eine von der Produktion getrennte Kopie Ihrer Anwendung, auf der jedes Update läuft, bevor es echte Nutzer trifft. Ohne sie ist jedes Release ein Blindflug, und der erste Fehler zeigt sich dort, wo er am teuersten ist: im Livebetrieb.

Was eine Staging-Umgebung ist und wozu sie dient

Eine Staging-Umgebung bildet die Produktion so genau wie möglich nach: gleiche Anwendungsversion, gleiche Datenbankstruktur, gleiche Serverkonfiguration, gleiche Anbindung an externe Schnittstellen. Sie dient ausschließlich dazu, Änderungen unter realistischen Bedingungen zu prüfen, bevor sie auf die Produktion übertragen werden. Das gilt für Codeänderungen genauso wie für Datenbankmigrationen und Konfigurationsänderungen am Server.

Der Unterschied zu einer gewöhnlichen Testumgebung liegt in der Nähe zur Produktion. Eine Entwicklungs- oder Testumgebung enthält oft nur die Anwendung mit Testdaten. Staging enthält den ganzen Stapel. Deshalb sind Fehler, die dort auftreten, mit hoher Wahrscheinlichkeit dieselben, die auch die Produktion treffen würden.

Sieben Regeln für eine Staging-Umgebung, die etwas taugt

Staging so nah wie möglich an der Produktion halten

Jede Abweichung zwischen Staging und Produktion ist ein blinder Fleck. Die Twelve-Factor App beschreibt dieses Prinzip als Dev/Prod Parity. Läuft Ihre Produktion auf mehreren Knoten hinter einem Lastverteiler, muss Staging das abbilden, sonst sagen Lasttests nichts aus. Läuft die Produktion mit einer bestimmten Datenbankversion, läuft Staging mit derselben. Das kostet Ressourcen. Es kostet weniger als ein Ausfall.

Denselben Auslieferungsweg für beide Umgebungen benutzen

Der Weg auf Staging und der Weg auf die Produktion müssen identisch sein und automatisiert laufen. Eine Pipeline baut die Anwendung, führt die Tests aus und stellt das Ergebnis auf Staging bereit. Nach der Abnahme wandert dasselbe Artefakt unverändert auf die Produktion. Sobald ein Mensch dazwischen von Hand eingreift, weichen die Umgebungen voneinander ab, und der Test auf Staging hat etwas anderes geprüft als das, was live geht.

Datenbankmigrationen zuerst auf Staging fahren

Datenbankänderungen sind eine der häufigsten Ursachen für Produktionsausfälle. Eine Migration, die auf einer kleinen Entwicklungsdatenbank in Sekunden durchläuft, kann auf der echten Datenmenge minutenlang Tabellen sperren. Auf Staging mit produktionsnahen Daten fällt das auf, bevor Kunden es merken. Darum gehört jede Migration, vom Hinzufügen einer Spalte bis zum Umbau einer Tabelle, zuerst dorthin.

Last- und Leistungstests auf Staging durchführen

Weil Staging die Produktion nachbildet, eignet es sich für Lasttests. Sie schicken simulierte Nutzerlast auf die Umgebung und sehen, wo es eng wird: zu wenige Datenbankverbindungen, zu kleiner Speicher, ein langsamer externer Dienst. Diese Engpässe vor einer Aktion oder einer Saisonspitze zu kennen, ist der Unterschied zwischen einem ruhigen und einem sehr langen Tag.

Freigaben klar regeln

Nach erfolgreichem Test auf Staging erteilt eine verantwortliche Person die Freigabe, und diese Freigabe wird festgehalten. Wer hat wann was abgenommen? Diese Frage muss auch Monate später beantwortbar sein. Auch die Technische Richtlinie TR-03185 des BSI zum sicheren Software-Lebenszyklus verlangt getrennte Test- und Produktivumgebungen und eine dokumentierte Freigabe. Ein einfaches Freigabeprotokoll mit Testergebnissen und Abnahme reicht dafür aus. Es braucht kein Werkzeug, es braucht Disziplin.

Staging regelmäßig mit der Produktion abgleichen

Testdaten veralten. Fehler, die nur mit bestimmten Datenkonstellationen auftreten, lassen sich auf Staging nicht reproduzieren, wenn die Daten dort ein Jahr alt sind. Ein regelmäßiger, anonymisierter Abzug der Produktionsdatenbank auf Staging hält die Tests aussagekräftig. Die Anonymisierung ist kein Zusatz, sondern Pflicht, sobald personenbezogene Daten im Spiel sind, denn Artikel 5 DSGVO bindet ihre Verarbeitung an Zweck und Datenminimierung.

Staging für nichts anderes verwenden

Staging ist keine Schulungsumgebung und keine Spielwiese für Entwicklung. Sobald dort jemand Daten anfasst oder Konfiguration verstellt, sind die Testergebnisse nichts mehr wert. Wer Schulungen braucht, bekommt eine eigene Umgebung.

Updates ohne Ausfallzeit einspielen: Was Staging dafür vorbereitet

Staging beantwortet die Frage, ob ein Update funktioniert. Ob es ohne Ausfallzeit live geht, entscheidet der Weg auf die Produktion, und der lässt sich auf Staging proben. Drei Dinge müssen dafür stimmen.

Die neue Version muss neben der alten laufen können. Ein Auslieferungsverfahren, das erst die neue Instanz startet, sie per Gesundheitsprüfung abfragt und dann den Verkehr umlenkt, kommt ohne Wartungsseite aus. Wenn die Prüfung fehlschlägt, bleibt die alte Version im Dienst. Auf Staging sehen Sie, ob die Gesundheitsprüfung wirklich prüft oder nur „ja“ sagt.

Datenbankänderungen müssen abwärtskompatibel sein. Eine Spalte wird erst hinzugefügt, dann von der neuen Version befüllt, und die alte Spalte erst in einem späteren Update entfernt. Wer Spalten umbenennt, während die alte Version noch läuft, produziert genau den Fehler, den er vermeiden wollte. Auf Staging mit produktionsnahen Daten fällt so etwas vorher auf.

Der Rückweg muss bekannt sein. Bevor ein Update auf die Produktion geht, steht fest, wie es zurückgenommen wird und wie lange das dauert. Ein Rückweg, der noch nie geprobt wurde, ist keiner. Auch das ist eine Aufgabe für Staging.

So läuft der Update-Ablauf im Betrieb durch dataso

Bei dataso ist die Staging-Umgebung fester Bestandteil des Betriebs von Webanwendungen. Jede Anwendung bekommt zwei getrennte Umgebungen, Produktion und Staging. Jedes Update, ob an der Anwendung, an der Laufzeit (Node.js oder PHP mit TYPO3) oder am Server, wird zuerst auf Staging eingespielt und dort geprüft. Erst nach Ihrer Freigabe geht es in einem vorher angekündigten Wartungsfenster auf die Produktion.

Dieser Ablauf ist dokumentiert und wird bei jedem Update eingehalten. Er verhindert nicht jeden Fehler. Er sorgt dafür, dass ein Fehler auf Staging auffällt und nicht bei Ihren Kunden. Welche Reaktionszeiten dabei gelten und was sie bedeuten, steht im Beitrag zu SLA-Reaktionszeiten.

Häufige Fragen zur Staging-Umgebung

Was ist eine Staging-Umgebung? Eine von der Produktion getrennte Umgebung, die den Produktivbetrieb nahezu identisch abbildet und ausschließlich dazu dient, Updates und Konfigurationsänderungen vor dem Livegang zu prüfen.

Wann ist eine Staging-Umgebung sinnvoll? Sobald eine Anwendung Kunden bedient oder Daten hält, deren Verlust weh tut. Der Aufwand für eine zweite Umgebung ist in fast jedem Fall kleiner als der erste Ausfall, den sie verhindert.

Worin unterscheidet sich Staging von einer Testumgebung? In der Nähe zur Produktion. Eine Testumgebung enthält meist nur die Anwendung; Staging enthält Datenbank, Serverkonfiguration und externe Schnittstellen in derselben Form wie die Produktion.

Der nächste Schritt: Ihren Update-Weg prüfen

Gehen Sie den Weg Ihres letzten Updates einmal nach: Wo wurde es getestet, wer hat es freigegeben, und wie sehr glich die Testumgebung der Produktion? Wenn eine der Antworten „gar nicht“ lautet, klären wir in eine halbe Stunde, wie eine Staging-Umgebung für Ihre Anwendung aussieht: Potenzial-Check buchen.