Ein Update eines Auktion Produktivsystems ist in der Regel kein Hexenwerk, wenn einige wichtige Überlegungen im Vorfeld - die Hausaufgaben - gemacht wurden.
Warum der Einsatz so genannter Staging-Server sinnvoll ist
Wer "neu" beginnt, wird vielleicht noch auf seinem Live-Server Änderungen direkt einspielen und testen.
Aber das ist schon in der Anfangsphase riskant, denn mögliche, unkalkulierbare Fehlfunktionen "vergraulen" möglicherweise die einigen wenigen wichtigen Kunden der Plattform schon vom Start an.
Manchmal ist es aber auch so, dass die Fachabteilung oder bei kleinen Projekten der Betreiber selbst kein Geld für Produkttests ausgeben will, oder kann, und sich im gleichen Atemzug aber auch ganz schnell darüber beschwert, dass da ein Fehler auf "der Website" ist.
Ein Dilemma für den Entwickler oder den Projektmanager. Denn wie erklärt man seinem Geldgeber, dass es fast zur Pflicht gehört, so etwas wie ein Staging System zu haben? Wohl nur demjenigen, der ein Staging-System sein eigen nennen kann und dessen unschätzbaren Wert bereits durch umgangene Pleiten bei online Projekten kennen gelernt hat oder nach Standards wie z.B. ITIL operiert.
Ein Staging Server oder wenigstens eine weitere Staging Instanz muss auch gar nicht so teuer sein. Für Staging kann
- eine komplett andere Domain oder
- eine Subdomain des Produktivsystem
- ein Unterverzeichnis des Produktivsystems
zum Einsatz kommen, wohingegen die Staging-Instanz dringend in einem passwortgeschützten Bereich laufen sollte, um weder Goolge, noch ähnlichen Neugierigen Zugang zu gewähren.
Die Staging Instanz soll hier im Folgenden kurz vorgestellt werden
Es reicht hierzu ein eigener Serveraccount für die Arbeits-Kopie, die notfalls auch auf der Live-Maschine läuft und sich in einem Unterverzeichnis mit 2. Datenbank befindet und zum Testen heran gezogen wird.
Vorteil dieser Lösung: Staging-Dateien sind sehr schnell auf Produktiv-Dateien (vorher Backup machen) gespiegelt. Test erfolgt auf gleicher Systemkonfiguration. Keine weitere Lizenzierung erforderlich.
Nachteil: Riskanter, da mögliche Übergriffe (Datenverbindung, Hacker Angriffe, was auch immer) von Staging nach Production nicht hermetisch abgeschirmt sind. Aber eher vernachlässigbar bei unkritischen Projekten.
Hier unser Vorschlag für ein weitgehend reibungsfreies Updaterelease
- Prüfung: Wurden alle Template Änderungen im User Verzeichnis gemacht?
- Kopie des Bestands und Aufsetzen einer Parallel-Installation mit gespiegelter Datenbankinstanz
- Abschaltung des Emailversands, um Bestandkunden nicht zu irritieren
- Debug-Modus einschalten per Setting in der config.inc.php - Dieser hilft auch schon bei "Notices" zur System Prüfung.
- Alternativ oder zusätzlich: Löschen der User ausser eigenen Testusern aus der Test Instanz
- Kurztest: Läuft alles ?
- Aufstellen einer Liste aller Änderungen an Dateien, inkl. Templates, da auch diese bei einem Update ggf. geändert werden und/ oder neue Funktionen dazu kommen, die in geänderten Bestandstemplates naturgemäß noch fehlen. Backups davon erstellen und Vorbereitungen treffen, mit einem MERGE Tool, wie zb. Winmerge oder Totalcommander Dateinhalts-Vergleiche an Dateien mit eigenen Änderungen fest zu stellen.
- Datei Updates einspielen, Datenbank Updates einspielen
- Kurztest: Läuft alles ? Wenn nicht, festhalten wo bzw. welche Datei oder Funktion Probleme macht
- Dateivergleiche mit Mergetools anstellen, ggf. Änderungen in eigener Datei nachpflegen
- Kurztest: Läuft alles ? Wenn nicht Rückkehr zu vorherigem Punkt
- Intensivtest mit allen wichtigen Routinen, auch ggf. neu hinzu gekommener Funktionen oder Module und '"warm" werden mit neuen Funktionen.
Wenn alles passt:
- Produktiv System noch einmal komplett sichern inkl. Datenbank
- Produktiv System in einen Wartungsmodus versetzen ( Cron Jobs stoppen, 404 Fehlerseite mit Wartungsmodus Hinweis anlegen )
- Original Produktiv Dateien aus dem /source/ Verzeichnis zum Zweck eines Backups umbenennen (zb /souce2) und Lese/schreibe Rechte aufheben (chmod 400)
- Update Dateien nach /source/ und eigens geänderte Dateien an Ihre Zielort kopieren
- Datenbank updates über den ADMIN Bereich einspielen, ggf. auf eigene Ergänzungen hier achten
- Debug-Modus ausschalten per Setting in der config.inc.php
- Wartungsmodus aufheben und "Zunge gerade halten"
- Intensivtest mit allen wichtigen Routinen
Viel Erfolg.
Gute Planung zahlt sich also aus
Ein Update stellt immer ein Risiko für ein laufendes Produktivsystem dar.
Mögliche Planungskriterien können hier sein:
- Ist der eingesetzte Webserver vom Softwarestand kompatibel mit ggf. neueren Funktionen der Software?
- Habe ich selbst Veränderungen an der Software gemacht, die mit einem Update kollidieren könnten ?
- Habe ich die Neuheiten im Update mit meinem Geschäftsmodell abgeglichen fall Funktionen obsolet werden?
- Ist das Update selbst von mir schon getestet worden?
- Habe ich ausreichende Backups gemacht?
- Habe ich einen Notfallplan im Falle autretender Probleme?
- Und alle an die wir hier nicht gedacht haben auf zu listen
Letzteres erfordert sehr genaue Planungsarbeit - planen Sie daher Ihre Updates sorgfältig und vertrauen nicht komplett auf die Menschen hinter der Software. Jeder, der mit Software arbeitet muss wissen, dass kein Mensch auf der Welt fehlerfreie Software entwickeln kann und alle wie auch immer gearteten Konstellationen beherrschen kann. Beschwerden darüber sind daher müßig. Lediglich über der Qualität der Fehlerbeseitigung kann man sich ein Urteil erlauben. Testen und Verantwortung zeigen muss man aber selber.