Kategorien
Einsatz von Staging Systemen
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.
Wir arbeiten auch mit Staging Servern und haben gute Erfahrungen damit gemacht.
Bei den Kunden, bei denen wir Staging Server einsetzen, haben wir deutlich weniger Probleme, als bei Kunden ohne Staging Server.
Jede Umgebung kann andere Probleme verursachen und daher ist es für mich sehr sinnvoll.
Ich kann dem Ralph Meier nur zustimmen. Wir arbeiten ebenfalls mit Staging Servern und haben nur gute Erfahrungen damit sammeln können, und möchten es nicht missen. Den Weg der Installation der einzelnen Komponente von der Entwicklung-Umgebung auf der Staging-Umgebung und dann auf der Live-Umgebung, haben wir uns mit einem Installer-Objekt erleichtert. Der besitzt alle notwendigen Einstellungen, Templates …etc. die eine Komponente erwartet, und installiert diese.
Vielen Dank für diesen Beitrag und die vielen Tipps. Ab und an habe ich schon solche Beiträge über Staging und Deployment Server gelesen doch für mein Verständnis waren sie schon immer einen Schritt zu weit, denn ich habe noch nie einen solchen Server aufgesetzt und auch ein solches Handling ist für mich Neuland. Mir fehlen immer die Beträge die die Lücken zwischen „Anfänger“ und „Profi“ füllen. Daher wollte ich diesen Artikel mal aufgreifen und nach Erfahrungswerte, Tutorials oder Step-by-Step Anleitungen fragen. Wie habt ihr Euch dieses Wissen angeeignet?
Würde mich freuen wenn ihr ein paar Tipps für einen Wissbegierigen habt 🙂
das grundproblem ist, dass sich dieser beitrag nur an php entwickler richtet, nicht an die it die die infrastruktur betreut 🙂
Was man noch erwähnen sollte, dass beim Kopieren von Daten aus einem Live-System ins Staging- oder Testsystem alle notwendigen Daten anonymisiert werden müssen. Sprich Kontodaten, persönliche Daten etc…, wenn man ein Nachrichtensystem hat müssen diese Daten durch Dummydaten ersetzt werden.
Es geht dabei einfach um die gesetzlichen Bestimmungen des Datenschutz. Weil auf Staging-Systeme kommen oft auch Entwickler die nicht aufs Live-System kommen und so sensible Daten lesen können die sie nix angehen.
Was auch noch wichtig ist, dass E-Mail Adresse auf eine Dummy-Adresse geändert wird. Es ist etwas blöd, wenn man im Staging-System rumspiel und ein User bekommt auf einmal eine E-Mail: „Du hast eine Nachricht von Person XYZ“ und hat aber gar keine… Wobei das noch ein harmloserer Fall ist.
Hier mal meine Ansichten/Gedanken:
Privater Entwicklungsserver: Sollte bereits möglichst alle Komponenten des späteren Produktions-System enthalten (Loadbalancer, Surrogate-Server, Scripting-hosts, CDN, Dbms, Memcache, …). Viele Fehler, Effekte entstehen ja oft auch zwischen den Komponenten. Wenn man in Produktion beispielsweise mit einem Mysql-(Replikations-)Cluster arbeitet, so will der Entwickler selber auch einen haben.
(Continues-) Integrations-Server: Hier werden regelmäßig die Erzeugnisse der verschiedenen Entwickler eines Teams „integriert“. Hauptsächlich um zu prüfen ob diese überhaupt zusammen passen. Hier können dann auch automatisierte Tests stattfinden. Hier ist der Integrations-Branch des kommenden Feature-Releases (manche benutzen auch den Trunk dafür) enthalten.
Um Hotfixes zu integrieren ist es ggf. sinnvoll einen zweiten Integrations-Server bereitszustellen, welcher einen (Bugfix-)Branch des aktuellen Releases auf Produktion beinhaltet.
Staging-Server: Hier findet die „General-Probe“ für ein (Feature- oder Bugfix-)Release statt. Es gibt hierbei zwei Aspekte. Zum einen die QA, die durch Menschen durchgeführt wird und die QA, die automatisiert stattfinden kann (Performance und Last-Tests). Und zum anderen das geplante Deploy auf Produktion zu proben (ggf. Daten-Migration, heißes/kaltes deploy). Für beides ist es zwingend notwendig, dass das Staging-System dem Produktion-System entspricht, unzwar in Struktur (Hardware, Sofware) und Dimension (vergleichbarer Nutz-Daten-Umfang). Hier sollte auch der Panik-Fall durchgespielt werden können, dass heisst, auf Knopfdruck zurück zu der vorigen Version zu springen, wie man es auch auf dem Produktions-System können sollte. Auch ernste Fehler können hier simuliert werden (Plattencrash, Abstürze, etc…). Im Zeitalter der Virtualisierung ist es glücklicherweise nicht so schwer und nicht so teuer einen Produktions-Cluster nachzubilden. Natürlich muss man, wenn Produktion 20 PHP-Hosts hat im Staging-System nicht auch 20 Knoten haben, aber die Verteilung der Anfragen sollte auf jeden Fall simuliert werden.
Problematisch ist natuerlich, wenn ein Feature-Release auf Staging (in QA) ist, aber ein Bugfix-Release (für die aktuelle Produktions-Version) zwischengeschoben werden muss – eventuell braucht man dann ein zweites Staging.
Präsentations-Server: Wenn es sinnvoll ist, kann man zB. für Kunden-Abnahmen noch einen Präsentations-Server andenken.
Spricht eigentlich etwas dagegen, wenn man das Kundensystem selbst hostet, für eine Staging-Umgebung die virtuelle Maschine des Live-Systems zu kopieren?
Man würde einfach die Updates in den Staging-Server einspielen und testen.
Bei Erfolg wird der Staging-Server einfach zum Live-System deklariert und die virtuelle Maschine des Live-Systems wird gestoppt und als Backup behalten. Da der Staging-Server eine identische Kopie ist sollte das (abgesehen von der Synchronisation der Datenbasis) kein Problem sein – oder doch?
@Tom: nicht so ganz. Prinzipiell kann man es so machen, für uns war es aber ein schöner Vorteil, wenn wir auf dem Staging System testen können bis zum Umfallen und damit auch Daten verändern können. Willst du den Stage anschließend zum Live deklarieren, schränkst du dich in den Testmöglichkeiten ein.
@Tim: was hätte dir denn noch gefehlt? Die Möglichkeiten zur Lösung sind ja vielfältig. D.h. man kann einen dedizierten zusätzlichen Server hinstellen, über virtuelle Maschinen oder gar nur per VHost arbeiten..
@sven: im Grunde schwer, das alles ausführlich durchzukauen 🙂 Evtl auch insofern schwer, da die letztliche Lösung schwer von der Umgebung abhängt. Sofern ihr schon virtuelle Server o.ä. einsetzt, setze doch einfach mal einen auf, der quasi euer Live-System spiegelt. Mache eine Kopie der Datenbank und bring das Ding ans laufen. Dann hast du schon fast den wichtigsten Job geschafft 🙂
itja hat hier einen sehr wichtigen Punkt angespochen an den leider viel zu viele vergessen!
Die Kundendaten sollten (MÜSSEN!!!!!!!) dort anonymisiert werden.
Ich hatte mal riesige Probleme wegen soetwas. Wir waren in Summe 5 „externe Entwickler“ die für eine Agentur eine Kundenseite weiterentwickelt haben.
„Leider“ hatte einer der Entwickler eine leichte „kriminelle“ Neigung zum Datendiebstahl und Weiterverkauf dieser Daten.
Früher wäre ich nie auf die Idee gekommmen, dass soetwas passieren kann, also immer schön aufpassen;)
Verbesserung:
Die Kundendaten sollten (MÜSSEN!!!!!!!) dort anonymisiert werden.
Ich meine natürlich „immer“ und nicht „dort“ 😉
Auch Steinzeitdumps von älteren Datenbanken haben hier nichts verloren.
Man sollte IMMER einen Contentgenerator erstellen.
Definitiv, den Punkt hatte ich auf meinem Block stehen, hab ihn aber tatsächlich vergessen 🙂 Datenschutz ist ein wichtiger Aspekt. Mal davon abgesehen, dass das Staging System evtl ungesichert ist, wg. noch nicht bekannter Sicherheitslücken im neuen Code.