am 16. Juli 2010
Wir alle kennen das Spielchen: jeder Entwickler hat seinen eigenen VHost oder ähnliches, in dem munter vor sich her entwickelt wird. Irgendwann wird alles integriert, schnell die Unit-Tests angeschmissen, alles läuft, wunderbar, dann können wir ja auf das Produktivsystem kopieren. Die neuenSources sind keine 5 Minuten auf dem Produktivsystem und schon kracht es. Aber was ging schief?
Für solche Probleme gibt es oft verschiedene Ursachen. Um solche Probleme zu vermeiden, sollte man sich natürlich Gedanken um einen ordentlichen Deployment-Prozess machen, mit dem man schnell wieder auf einen funktionierenden Stand zurückspringen kann. Viele solcher Probleme rühren aber oft daher, dass eine Integration nicht ordentlich getestet werden konnte oder manche Probleme auch einfach erst mit einer Datenbasis auftreten, wie sie höchstens das Produktivsystem, nicht aber das Entwicklungssystem hat.
Zur Vermeidung solcher Probleme empfehlen sich Staging Systeme. Ein Staging System beschreibt eine Serverinstanz, welche mit der Umgebung des Produktivsystems möglichst identisch sein sollte, im Optimalfall also auch die gleiche Hardware. Das ist natürlich in den meisten Teams oder Projekten eine recht utopische Vorstellung, daher muss es nicht zwingend eine eigene Hardwarelösung sein. Ein virtueller Server macht hier ebenfalls einen ausreichenden Job.
Aber fangen wir von vorne an. Welche Aspekte sind denn für ein sinnvolles Staging System wichtig? Auf jeden Fall sollten Staging-und Produktivsystem die gleiche Softwareplatform haben. Das bedeutet es sollte in jedem Fall das gleiche Betriebssystem in der gleichen Version laufen, alle verwendeten Softwarepakete (PHP, Datenbankserver usw) sollten zwingend in der gleichen Version installiert sein und es sollte auch der gleiche Umfang an Software installiert sein, in einer möglichst identischen Konfiguration. Natürlich lassen sich gewisse Abweichungen in der Konfiguration nicht vermeiden. Wenn wir etwa auf unserem Produktivsystem auf Grund des verfügbaren RAM höhere Speicherlimits haben, als auf dem Staging System, dann ist das eben nicht zu vermeiden, stellt insofern kein aber Problem dar, weil weniger Speicher für den Testfall ja durchaus von Vorteil sein kann, um früher Probleme beim Speicherverbrauch aufzudecken. In jedem Fall sollte man allerdings davon absehen, das Staging System als VHost auf dem Produktivserver laufen zu lassen. Zum Beispiel würden somit jegliche Tests an der Konfiguration des VHosts des Staging Systems, die einen Neustart der Serverdienste benötigen, auch das Produktivsystem beeinflussen.
Die Applikation, die wir deployen, sollte ferner natürlich ebenfalls möglichst identisch konfiguriert sein. Die Quelldateien sollten beide auf dem gleichen Stand und aus dem gleichen Branch stammen. Auf dem Staging System dürfen sich ausschließlich nur die Änderungen befinden, die auch tatsächlich integriert wurden und live gehen sollen.
Ein spannender Punkt ist letztlich dann noch die Datenbank und die damit verbundene Datenbasis. Das Ziel eines Staging Systems ist es natürlich immer möglichst identisch an das Produktivsystem heranzukommen, das gilt also auch für die Datenbasis. Auf Grund der eingeschränkten Platzverhältnisse auf einem Staging System ist das aber oft nicht realistisch machbar. Selbst wenn wir die gesamte Datenbank spiegeln können, haben wir damit ja immer noch nicht zwingend auch alle restlichen Daten auf dem Staging System verfügbar, wie etwa Useruploads etc.
Hier muss man genauer prüfen und von Projekt zu Projekt entscheiden. Je nach System empfiehlt es sich die gesamten Datenstämme gewisser Nutzergruppen zu kopieren, mit denen man etwa arbeiten möchte. Es müssen also nicht zwingend alle Daten für alle Nutzer sein, aber man sollte sicherstellen, dass man zumindest aus gewissen Nutzergruppen verschiedene Testfälle abdecken kann.
Für das “Überschreiben” der Daten auf dem Staging Server durch aktuelle Daten vom Produktivsystem ist es ratsam, ein Script zu schreiben. Das hat den einfachen Hintergrund, dass man so auch “auf Knopfdruck” schnell und einfach auf dem Staging System eine aktuelle Datenbasis erhält, mit der man etwa auch Probleme reproduzieren kann, die vielleicht erst auf dem Produktivsystem aufgetreten sind. Dieses Script ist im Optimalfall parametrisiert, sodass man bequem wählen kann, in welchem Umfang und aus welchem Bereich Daten kopiert werden sollen. Das ist natürlich ebenfalls stark Projektabhängig und man muss dafür das System und seine Abhängikeiten gut kennen.
Zuletzt sollte das Staging System natürlich in den Deploymentprozess eingebunden sein. Es dürfen etwa keine Änderungen auf das Produktivsystem gehen, ohne vorher im vollen Umfang der Integration auf dem Staging System getestet worden zu sein. Ferner sollte man etwa eine Abnahme durch den Product Owner in einem SCRUM Team ausschließlich auf dem Staging System machen und nicht an irgendwelchen Entwicklerbuilds, die nicht vollständig integriert sind etc.
Das war mal soweit ein kleiner Überblick darüber, was Staging System so mit sich bringen sollte und worauf geachtet werden sollte. Das alles sind mehr ein paar allgemein gehaltene Ratschläge, denn wie so vieles in der Softwareentwicklung, ist der Einsatz verschiedener Mittel nie “einfach so” möglich, sondern stark abhängig von der Umgebung. Generell bieten Staging Systeme aber einige Vorteile. Ganz davon abgesehen, dass sie helfen eine fehlerhafte Integration zu vermeiden und Probleme vor dem Aufschlagen auf dem Produktivsystem aufzudecken. Sie sind noch dazu eine große Hilfe, wenn auf dem Produktivsystem Probleme auftreten, die sich auf dem Entwicklersystem nicht reproduzieren lassen. Wenn man die Möglichkeit hat, sich ohne weiteres seine Datenbasis auf das Staging System zu spiegel, um dort zu testen, spart das oft viel Zeit und damit auch Geld.
