Der CommitStrip bringt es auf den Punkt:
Bis zu welchem Grad ist der Aufbau von Staging Umgebungen nützlich, und ab wann ist die Stelle erreicht, ab der der Betrieb und die Komplexität zu viel kosten? Oder umgekehrt: Wann lohnt es sich eigentlich ein Staging einzuführen, wenn man – wie wir – bisher keines hat?
Warum wir (bisher) kein Staging haben
Tatsächlich haben wir in dem umfangreichen Softwareprojekt, welches ich leite, bisher gar kein echtes Staging, faktisch gibt es nur das produktive System und die jeweiligen Entwicklungssysteme. Warum das bei uns so funktioniert würde ich mit diesen Punkten erklären:
Softwarequalität
Das beste Argument gegen ein Staging ist sicher eine hohe Softwarequalität: Wenn (fast) nie Fehler passieren (oder sie niemand bemerkt, weil sie so schnell behoben werden), dann wird auch niemand nach zusätzlicher Qualitätssicherung rufen. Die Softwareentwicklung wird bei uns von einem kleinem Team geleistet, welches teilweise schon sehr lange im Thema ist und dementsprechend erfahren ist. Häufige Releases mit entsprechend kleinen Entwicklungsschritten vereinfachen die Qualitätssicherung, da sie die Komplexität der einzelnen Schritte deutlich reduzieren. Die häufigen Releasezyklen werden durch eine Aufteilung des Produkts (hier ein Campusmanagementsystem) in viele Teilmodule erreicht, die weitgehend unabhängig voneinander sind (trotz einer in weiten Teilen gemeinsamen Codebasis).
Agilität
Bei uns fallen Softwareentwicklung und Serverbetrieb zusammen. Wenn es tatsächlich Fehler in die Produktion schaffen sind wir handlungsfähig und machen meist gar kein Rollback, sondern erstellen direkt eine neue Version mit entsprechender Fehlerkorrektur. Möglich ist dies durch eine Serverstruktur, die es erlaubt zu jeder Zeit für die Benutzer unmerkliche Updates durchzuführen, die nicht lange geplant oder angekündigt werden müssen.
Freigabeprozesse
Die Zuständigkeiten für das Produkt und die inhaltlichen wie technischen Kompetenzen für die Weiterentwicklung sind bisher nahezu komplett im Team gebündelt. Bei neuen Releases müssen daher nur selten Freigaben durch Key User eingeholt werden. Und falls doch, so wird dies auf den Entwicklungssystemen in direktem Kontakt gemacht. Da wir ein hausinterner Dienstleister sind und sich unsere Ansprechpartner in räumlicher Nähe befinden können wir so vorgehen.
Java
Das ‚Java Versprechen‘, wonach eine auf einer Plattform entwickelte Software auch problemlos auf einer anderen laufen wird, hat sich für uns weitgehend erfüllt: Heute findet die Entwicklung unter Windows statt und verwendet eine PostgreSQL Datenbank, während das produktive System unter Solaris und einer anderen relationalen Datenbank betrieben wird. Insgesamt gab es in der langen bisherigen Projektlaufzeit nur extrem selten Probleme, die sich auf den Entwicklungssystemen nicht nachstellen ließen. Diese wenigen Probleme waren so komplex, dass eine Nachstellung in einer Staging Umgebung mit einem enormen Aufwand verbunden gewesen wäre.
Backup
Um das Risiko von fatalen Fehlern, die es in die Produktion schaffen sollten, zu minimieren, ist ein leistungsfähiges und zugreifbares (!) Datenbankbackup essentiell. Mit fatalen Fehlern meine ich dabei solche, die Datenbankinhalte vernichten oder unmerklich korrumpieren. Ein solches Backup muss bei einer komplexen Anwendung in der Lage sein ohne großen Aufwand jederzeit Teildaten in verschiedenen Versionsständen zu liefern.
Unittests
Man kann nie genug automatisierte Tests haben, aber an bestimmten entscheidenden Stellen haben wir sie und können damit auch nach Systemänderungen sicher sein, dass diese Programmierungen noch korrekt funktionieren.
Was einem das Staging verleiden kann
Es gibt viele Gründe Staging Konzepte einzusetzen, einen guten Teil nennt der Comic Strip bereits: Entwicklungssysteme, Testsysteme mit verschiedenen Zielsetzungen, Demosysteme, Freigabesysteme, etc. Und in den meisten Konstellationen wird man auch nicht ohne Staging auskommen. Was einem an der ganzen Sache den Spaß verderben (oder die Aufwandskalkulation für die entsprechenden IT Abteilungen nach oben treiben) kann, sind dann u. a. diese Punkte:
Wer kümmert sich um die Server?
Auch wenn es ‘nur’ ein interner Testserver ist: Irgendjemand muss ihn warten. Wird er nicht gewartet, so ist er ein zukünftiges Einfallstor für Angreifer, selbst wenn er sich tief in internen Netzen befindet. Mit jeder Stage wächst die Zahl der Server, um die sich irgendjemand kümmern muss. Falls man den Versuch unternimmt Stages aufzubauen, die der produktiven Umgebung sehr nahe sind, kann die Zahl der zusätzlichen Server enorm werden, vor allem wenn für verbundene Systeme wie Datenbanken, Identity Provider etc. ebenfalls entsprechende Staging Umgebung aufzubauen sind. Gut, wenn man hier schon eine Automatisierungslösung im Einsatz hat, die dies vereinfacht.
Echtdaten für Stages
Schnell wird man bei dem Wunsch landen in nicht-produktiven Stages die Daten des Produktivsystems zur Verfügung zu haben. Solche Daten(und ggf. Konfigurations-)kopien anzulegen erzeugt mindestens initial Aufwände für die Inbetriebnahme.
Wenn es sich um personenbezogene Daten handelt wird man sich zusätzlich den Fragen der Datenschutzbeauftragten stellen müssen. Und landet schnell bei einem Schutzbedarf der nicht-produktiven Stages, der dem Schutzbedarf der produktiven Stages in nichts nachsteht, denn auch von solchen Stages können sensible Unternehmensdaten abhanden können. Alternativ müssen Pseudonymisierungsverfahren entwickelt werden, damit die Echtdaten so unkritisch werden, dass sie auch in weniger geschützten Umgebungen genutzt werden können.
Wenn man es irgendwie vermeiden kann (Unittests, Generierung realistischer Testdaten) sollte man die Echtdatenübernahme in andere Stages vermeiden.
Enttäuschte Erwartungen I: Key User
Bei einer starken Aufgabenteilung zwischen IT Betrieb und Key Usern entsteht gelegentlich die Erwartung der IT, dass die Key User neue Versionen einer Software über eine für sie bereitgestellte Stage ausgiebig testen und damit in gewisser Weise die ‘Verantwortung’ übernehmen, dass die Software korrekt funktioniert. Die Frage ist allerdings inwieweit diese Erwartung realistisch sein kann? Key User, die per Definition ExpertInnen in dem fraglichen Themenfeld sein müssen, sind erfahrungsgemäß sowieso in ihren Abteilungen stark belastet und werden Besseres zu tun haben als neue Releases systematisch zu testen. Funktionieren kann so ein Konzept höchstens wenn es darum geht Weiterentwicklungen im Einzelfall abzunehmen.
Enttäuschte Erwartungen II: Lasttests
Ein weitere Enttäuschung droht im Bereich von Lasttests. Gerade bei neuen, unbekannten Systemen kann der Wunsch entstehen die notwendige Dimensionierung der Infrastruktur vorher durch synthetische Belastungstests ermitteln zu wollen. Hier gibt es zwei grundlegende Schwierigkeiten:
- Wie erzeuge ich realistische Lasten? Bei einem schon laufenden System kann ich versuchen in den vorhandenen Protokollierungen Nutzungsmuster zu finden, die mir ein Testdesign ermöglichen. Bei Systemen mit vielen Nutzern kann es trotzdem schwierig sein die gefundenen Nutzungsmuster in realistischer Weise in einem Test auszuführen (wie simuliere ich Zugriffe von tausenden von Clients aus unterschiedlichen Netzen?).
- Wie erzeuge ich eine realistische Staging Umgebung? Bei einem System, welches sich im Aufbau befindet, kann ich vor der Inbetriebnahme die produktive Stage für entsprechende Tests verwenden. Nach der Inbetriebnahme ist das natürlich kaum noch möglich. Eine Stage für realistische Lasttests aufzubauen kann eine Duplizierung weiter Teile der unterstützenden IT Infrastruktur erfordern und lässt einen schnell bei der Forderung nach Echtdaten landen.
Im Endeffekt hat man ein hohes Risiko kein angemessenes Ergebnis für den erbrachten, erheblichen Aufwand zu erhalten. In vielen Fällen wird man vermutlich besser fahren, wenn man seine Systemarchitektur so aufstellt, dass auf unerwartete Lasten rasch reagiert werden kann. Dies ist mit heutigen Virtualisierungskonzepten auch normalerweise problemlos möglich.
Warum wir vermutlich doch (irgendwann) ein Staging haben werden
Aber auch für uns wird sich das Thema ‘Staging’ in Zukunft neu stellen. Ein wichtiger Treiber ist dabei die Idee Deployments unseres Produktes in Zukunft automatisieren zu können (CI/CD).
Ein erster Schritt in diese Richtung wäre daher eine ‘Demo- oder Reviewstage’, die automatisiert die jeweils aktuell in der Versionskontrolle befindlichen Versionen unserer Anwendungsmodule verwendet, so dass sie sich schnell vorführen und prüfen lassen. Ggf. könnte man hier auch gleich weiter denken und diese Stage für verschiedene Branches verfügbar machen.
Ein anderer Treiber ist die durch Organisationsveränderungen fortschreitende funktionale Differenzierung im IT Betrieb, die die Serveradministration in andere Hände legen wird. Auch hier ist möglicherweise ein Staging ein Mittel um sowohl die Produktqualität, die Handlungsfähigkeit und die Releasegeschwindigkeit hoch halten zu können.