Tatsächlich habe ich ein paar Jahre gebraucht um doch mal damit aufzuhören am “offenen Herzen” zu operieren und mich für die Einrichtung eines Staging-Systems zu entscheiden. Auslöser war tatsächlich ein nicht funktionierendes Upgrade von Shopware. Hier hatte ich das Update auf 5.6.2 durchgeführt ohne vorher die entsprechende Upgrade-Doku gelesen zu haben.
Im Beitrag zum Update auf 5.6.0 steht im zweiten Hinweis:
verwaiste Einträge in s_order_details
Vor dem Update müssen ggf. verwaiste Einträge in s_order_details entfernt werden.
DELETE from s_order_details WHERE orderID Not IN (Select id from s_order)
Dadurch, dass ich danach zwar wieder das Backup wiederherstellte, jedoch die DB nicht mit wiederhergestellt habe konnte ich ohne manuelles nachjustieren das Upgrade nicht durchführen. Daher mein Kommentar im Shopware-Forum.
Jetzt auch noch ein wichtiger Hinweis: Die folgende Anleitung wurde von mir nach bestem Wissen und Gewissen erstellt, ich übernehme jedoch natürlich keine Haftung für jegliches Fehlverhalten. Die Umsetzung der u.a. Punkte geschieht natürlich auf euer eigenes Risiko.
Um solche Geschichten zukünftig zu vermeiden habe ich mich nun (endlich!) für die Einrichtung eines Staging-Systems entschieden um nicht immer das Risiko des Zeitaufwandes für die Wiederherstellung eingehen zu müssen. Ok, jetzt endlich zur Einrichtung:
Voraussetzungen:
- Ich nutze die Plesk Version Onyx 17.8.11
- ausreichend Speicher für das Staging System (es sollte max 1/3 belegt sein)
- Sinnvoll ist es die max_execution_time in den PHP Einstellungen (geht ja im Plesk über die Oberfläche) hochzusetzen. Ich habe hier den Wert 600 stehen
- Möglichkeit eine zweite Datenbank einzurichten
Anlegen der Subdomain
Auch wenn es vielleicht anders geht, ich persönlich finde es absolut sinnvoll das Staging System auf einer Subdomain laufen zu lassen. Sollte man das nicht wollen, so kann man auch einen eigenen Webspace dafür einrichten. Jedoch sollte es zwingend auf dem gleichen Server laufen, da es von Hoster zu Hoster immer wieder unterschiedliche Konfigurationen geben kann und die Testinstanz ja möglichst unter gleichen Bedingungen laufen sollte.
Ich denke die Bilder sind selbsterklärend 🙂
Ein weiterer Vorteil der Subdomain ist, dass ich auf diesen Ordner über die bisherigen FTP Zugangsdaten zugreifen kann. Meine Empfehlung ist es jedoch einen neuen FTP Nutzer anzulegen und diesen auf den Pfad /staging.domain.de zu begrenzen. Nicht, dass man aus versehen im falschen Ordner etwas verändert.
Kopieren des Webspace
Nun kopieren wir den Webspace des Produktiv-Systems in den Webspace der frisch angelegten Subdomain.
Hier wählen wir dann die Subdomain aus und können ruhig vorhandene Daten löschen.
Datenbank kopieren
Natürlich ist es auch nötig die Datenbank zu kopieren. Den Datenbanknutzer als solchen habe ich nicht geändert. Die Datenbank in Plesk zu kopieren ist wirklich komfortabel:
Beim Kopieren auch hier darauf achten, dass eine neue Datenbank und eine vollständige Kopie erstellt wird.
Datenbank anpassen
Jetzt müssen wir die Datenbank mit dem neuen Staging System verknüpfen und die Shop-URL in der neuen Datenbank anpassen. Als erstes ändern wir über dem FTP Server die config.php Datei (ACHTUNG! Nicht die config Datei des Produktiv-Shops ändern!) Auf jeden Fall sicherstellen, dass man sich im Verzeichnis des Staging-Systems befindet.
Hier dann die config.php auf den neuen Datenbanknamen anpassen. Als FTP -Software nutze ich im Übrigen bereits seit Jahren den FileZilla und bin wirklich sehr zufrieden damit.
In einem zweiten Schritt ändern wir nun den Host in der Datenbank des Staging-Systems. Ich habe auch über Plesk dann die Datenbank dem Webserver hinzugefügt:
Über den phpMyAdmin Button gelangen wir direkt in die Datenbankverwaltung. Hier nun nach der Tabelle s_core_shops suchen und öffnen.
In der Spalte “host” dann entsprechend den Namen auf die Subdomain anpassen.
Fast fertig…
Jetzt ist das Staging-System bereit. Damit das System nicht für alle abrufbar ist, habe ich noch den Wartungsmodus eingeschalten und meine IP als Ausnahme hinterlegt.
Zusätzlich die Datei robots.txt im root mit dem Code
User-agent: * Disallow: /
anzulegen, kann nicht schaden.
Ich persönlich nutze das Staging System um Änderungen vorab durchzuspielen und dann – wenn es alles geprüft ist – auch auf dem Live-System umzusehen. Ein “One-Click-Deployment” ist das also nicht.
Jedoch kann man natürlich jederzeit das Staging-System mit ein paar Klicks aktualisieren in dem man einfach den Webspace wieder neu kopiert, die DB neu kopiert und dann die Anpassungen schnell nochmals durchführt.
Wie immer: Sollte ich irgendetwas vergessen haben oder irgendetwas nicht passen, dann einfach über die Kommentare melden.