Best Practice: Staging-Umgebung in der Webentwicklung

Qualität durch mehrstufige System-Architektur sicherstellen

Die technische Architektur, mit der Software mit einem entsprechenden Qualitätsstandard entwickelt wird, umfasst mehrstufige, separate Umgebungen, die einzelne programmierte Komponenten durchlaufen. Angefangen von einer lokalen Umgebung, über eine Staging-Umgebung als Abbild des Produktivsystems bis zum Production System, auf dem die Software live geschaltet ist. In modernen Deployment-Prozessen gehört die Staging-Umgebung zwingend zur System-Architektur der Entwicklung dazu.

Warum Staging unverzichtbar ist

Die Einrichtung eines Staging-Systems erlaubt es, einzelne Komponenten und Features zu testen, bevor diese tatsächlich im produktiven Live-System eingespielt werden. So werden nur funktionierende Release-Pakete letztlich freigegeben und veröffentlicht. Das Staging gilt als ein so selbstverständlicher Teil der Architektur, dass es oftmals nicht die Aufmerksamkeit erhält, die dem Staging eigentlich zukommen sollte. Eine grundsätzliche Erklärung und Erläuterung kann dabei helfen, Fehler in der Handhabe zu vermeiden und auch zu einer für alle Beteiligten gewinnbringenden Anwendung dieses Entwicklungsschrittes beizutragen.

Wenn frisch entwickelte Features ausgerollt werden sollen, kann der Aufwand dies über ein Staging-System zu validieren, schnell als weniger wichtig angesehen werden. Soll der Code jedoch Teil einer ausgereiften und etablierten Software Applikation sein, wie eine individuell programmierte Website oder komplexe Web-Anwendung, ist eine Staging-Umgebung unverzichtbar. Dieses Best Practice hat ihre absolute Berechtigung, denn nur so können Fehler und Probleme im Produktivsystem verhindert werden - das spart Geld, Zeit und Nerven und zollt auch dem Nutzer den nötigen Respekt, der eine funktionierende Software erwartet.

Grundlagen der Staging-Umgebung

Vielfach wird „Staging“ in Relation zu „Production“ definiert und beschrieben. Aussagen wie „Auf dem Staging-System wird Code ausgerollt, bevor er im Produktionssystem implementiert wird.“ „Staging ist Production lite“ oder auch „Staging ist wie Production, aber ohne Kunden." Aber welchen Zweck verfolgt man in einem strukturierten Entwicklungsprozess mit einer Staging-Umgebung?

Das Staging-System dient vor allem dazu, bekannte Risiken der Applikation oder Website auszuräumen. Diese Risiken stellen erwartete Konsequenzen dar, die bereits vorher antizipiert werden aber nicht mithilfe vergangener Erfahrungen belegt werden können. Über das Validieren im Staging-System erlangt die Entwicklung auch immer wieder wichtige Erkenntnisse über die Applikation und die Sicherheit im Umgang mit der Software kann stetig ausgebaut werden. Unbekannte Variablen, wie viele Benutzer an einem Tag die Website besuchen oder welches Nutzerverhalten sie dort zeigen werden, sind Zustände, die sich auf der produktiven Website ablesen lassen. Diese unbekannten Szenarien können nur äußerst bedingt auf dem Staging-System simuliert und untersucht werden.

Staging vs. Testing

Die Frage, weshalb es sinnvoll ist, eine Staging-Umgebung einzurichten, mit „weil es Best Practice ist“ zu beantworten, wäre deutlich zu einfach. Denn auch Ansätze, die gemeinhin als Standard angesehen werden, lohnt es, auf ihre Zweckmäßigkeit im Hinblick auf die eigenen Bedürfnisse zu prüfen.

Das Ziel eines Entwicklungsprozesses und der dazugehörigen System-Infrastruktur ist die verbesserte Funktion und Stabilität der Applikation zu gewährleisten. Kann dieses Ziel auch ohne ein Staging-System erreicht werden? Das Hauptargument gegen den Einsatz einer Staging-Umgebung und vorgeschlagene Alternative: Tests.

In solchen Setups arbeitet die Entwicklung mit einem lokalen System, einem aufwendigen Testframework und dem Produktivsystem. Die Testumgebung ist in der Regel sehr robust aufgebaut und Fehler können relativ schnell behoben werden. Verifizierte Builds werden vermeintlich einem „Continous Integration“ Ansatz folgend im Live-System ausgerollt. In Wahrheit handelt es sich hier eher um „Wild West“-Entwicklung. Tests müssen von menschlicher Hand geschrieben werden und deren Qualität hängt von der individuellen, vorausschauenden Konzeption ab. Dieser Umstand wird vielfach noch dadurch verschärft, dass derjenige, der den Programm-Code live schalten möchte auch den dazugehörigen Test schreibt. Eine weitere Herausforderung ist den Test so aufzusetzen, dass alle möglichen Interaktionen des Codes in einer produktiven Umgebung abgebildet werden können.

Staging: Interaktion mit der Benutzeroberfläche

Verfügt die Anwendung über eine Benutzeroberfläche, wie eine Website, wird das Abbilden aller Eventualitäten mittels eines Testszenarios noch schwieriger. Denn Tests, die sicherstellen sollen, dass die Farbe einer Sidebar in der Benutzeroberfläche korrekt angezeigt wird, werden in der Regel nicht geschrieben. In einem Staging-System wiederum findet auch eine Interaktion mit dem Frontend statt, sodass dessen Handling und Design ebenfalls mit im Fokus der Entwicklung liegt. Fehler und Probleme, die die Optik und Bedienung der Benutzeroberfläche betreffen, werden so auch gesehen und behoben.

Aber auch ohne ein User Interface, können Tests nicht alle denkbaren Szenarien abbilden, da der Konzipierende nicht alle Interaktionen vorhersehen und somit prüfen kann. Aber eine Entwicklungsumgebung mit einem Staging-System, in der diese Interaktionen systemseitig gegeben sind und man den Code organisch laufen lassen kann, ist dies sehr gut möglich. Grundsätzlich können Tests vor einer Implementierung bekannte Probleme prüfen und beseitigen, bevor auf dem Staging-System unbekannte Risiken untersucht werden. Tests sparen Zeit beim Erstellen, Überprüfen und Bereitstellen des Codes für die Staging-Umgebung.

Staging-System effektiv aufsetzen

Im Idealfall gehört das Staging-System von Beginn an zur Architektur der Entwicklungsumgebung. Da das Staging-System das Produktivsystem spiegeln soll, muss es natürlich auf die gleiche Weise konstruiert werden. Die Infrastruktur sollte also entsprechend analog aufgesetzt werden und dann mit Programm-Code befüllt werden.

Während der Erstellung der Staging-Umgebung sollte auch ein konsistenter Bereitstellungsprozess (Deployement) und eine Betriebsplattform implementiert werden. Die Idee, Staging als Kopie auf einem kleineren Space zu betreiben, erscheint zunächst nahe liegend, aber das bedeutet, dass das Staging-System von vornherein begrenzt wird. Einige Programmier-Arbeiten können nicht einfach übertragen werden und es entstehen unnötige Reibungsverluste.

Eine Staging-Umgebung will mit Bedacht und so nah wie möglich am Produktivsystem aufgebaut werden. Es sollte der gleiche Code zwischen Staging und Produktion ausgetauscht werden. Dazu können entsprechende Umgebungsvariablen eingesetzt werden, um zwischen Netzwerk-Endpunkten und Datenbanken zu wechseln. Diese Netzwerk-Endpunkte und Datenbanken sollten die gleichen Konfigurationen und Schemas wie die Produktion haben und nur bedingt mit Dummy-Daten laufen.

Live-Traffic einer Anwendung simulieren?

Das vollständige Replizieren des realen Traffics des Produktivsystems in der Staging-Umgebung kann nicht vollständig dargestellt werden. Realistischer ist die Frage nach dem Mehrwert der Simulation und wie nah an der Realität die tatsächliche Nutzung der Anwendung oder der Website mit allen Rahmenbedingungen simuliert werden kann. Der Aufwand für das Setup und auch die Erkenntnis eines Traffic-Testings kommen sinnvoll zum Einsatz, wenn auch im Live-Betrieb mit entsprechend hohen Nutzerzahlen zu rechnen ist. Dies ist der Fall, entweder weil die Applikation aktuell schon stark frequentiert wird oder aufgrund von entsprechender Marketing-Maßnahmen mit einem Traffic-Peak zu rechnen ist.

Solche Lasttests im Staging-System können Sicherheit und Vertrauen in die Anwendung schaffen, sind aber in der Vorbereitung und Konzeption sehr aufwendig. Es muss immer abgewogen werden, ob der Mehrwert durch den Test der Performance diese Aufwände wirklich rechtfertigt oder A/B-Tests auf dem Produktivsystem besser geeignet sind.

Performantes Setup der Staging-Umgebung entscheidend

Der Staging-Umgebung sollte die notwendige Relevanz beigemessen werden, da diese sich sonst sogar nachteilig auf die Qualität der Anwendung auswirken kann. Wird das Staging-System auf alter, langsamer Hardware aufgesetzt, hinsichtlich der verfügbaren Performance beschränkt oder die Infrastruktur noch anderweitig verwendet, entstehen so zum einen Reibungsverluste im Deployment-Prozess und auch die Ergebnisse, die eine solche Staging-Umgebung liefert, sind qualitativ eingeschränkt.

Die Staging-Umgebung sollte im Verhältnis zur Produktion den gleichen Maßstab, Hardware und systemseitigen Rahmenbedingungen haben, um die volle Funktionalität und Nutzen auszuschöpfen. Ein Staging-System dient außerdem dem Erkennen von Fehlern und Problemen. Demnach treten diese auch auf und sollten dann möglichst schnell wieder zu beheben sein. Teamübergreifend verfügbare Tools und Abläufe, um schnell und einfach ein Rollback einzuspielen und so die Staging-Umgebung wieder in den letzten, einwandfreien Zustand zurückzuversetzen, sollten ebenfalls etabliert werden.

Investition in Staging steigert Qualität

Der Aufbau eines Deployment-Setups mit einer Staging-Instanz erscheint vielfach zu komplex und umständlich. Manche Entwickler verzichten so voreilig auf die wichtige Staging-Umgebung. Denn die Anstrengungen, die ein Entwicklungsprozess mit einem vorgeschalteten Staging-System verlangt, sind deutlich geringer als fehlerhaften Code im Produktivsystem zu finden und diesen ohne größeren Schaden wieder zurückzunehmen und zu korrigieren. Sowohl in der Entwicklung von klassischen Software-Produkten als auch bei der Web-Entwicklung entscheidet die stabile und einwandfreie Funktionalität des Produkts über dessen wirtschaftlichen Erfolg. Diese Qualität stellt eine mehrstufige Entwicklungsumgebung mit einem Staging-System sicher.