Das flexible Workspace-Setup von Codesphere macht die Aktualisierung Ihrer Services kinderleicht und reduziert das Risiko von Produktionsausfällen erheblich, wenn es richtig eingerichtet ist. In diesem Dokument wird erläutert, wie Sie mit Codesphere eine Staging-Umgebung einrichten und Updates über Preview Deployments testen können.
Über Staging Environments
Eine Staging-Umgebung ist im Grunde eine Kopie Ihrer Produktionsumgebung. Diese Umgebung verfügt über einen eigenen Server mit Speicherplatz, Rechenleistung und einer speziellen Zugriffsmöglichkeit, normalerweise über eine interne Test-URL.
Der Hauptvorteil einer dedizierten Staging-Umgebung besteht darin, dass alle Aktualisierungen Ihrer Anwendung (gründlich) getestet werden können, ohne Ihr Live-System zu beeinträchtigen. Dies allein macht Ausfälle und Fehlfunktionen nach Updates weniger wahrscheinlich. Mit Codesphere ist das Einrichten einer Staging-Umgebung wirklich einfach.
Mit unseren Staging Environments können Sie sogar mehr als nur Updates testen, bevor Sie sie in der Production deployen. Der gesamte Prozess des Deployments wird zu einer Angelegenheit von nur einem einzigen Klick und Sie können genauso einfach hin und her wechseln. Dies nennt man Preview Deployments.
Workspaces einrichten
Navigieren Sie zu Ihrem Codesphere Team und klicken Sie auf New Workspace. Wenn Ihr Production Workspace bereits eingerichtet ist, müssen Sie nur noch das Github-Repository und die Verzweigung mit Ihrem Code auswählen, einen Namen angeben (z. B. Staging), einen Plan mit entsprechender Rechen- und Festplattenkapazität auswählen und auf "Start Coding" klicken.
Alternativ können Sie auch Kopien von Workspaces erstellen, ohne Git zu verwenden. Klicken Sie in Ihrer Workspace-Tabelle auf die drei Punkte rechts neben dem Workspace, den Sie kopieren möchten, wählen Sie Workspace kopieren, geben Sie einen Namen ein und klicken Sie auf Workspace kopieren. Je nach Größe der Dateien kann dieser Vorgang einige Minuten in Anspruch nehmen.
Bei beiden Optionen wird ein weiterer Workspace mit Ihrer Anwendung erstellt. Wiederholen Sie nun alle Schritte, die Sie in der Production durchführen würden, um Ihre Anwendung zu deployen, wie z.B. die Installation von Paketen und Abhängigkeiten, das Erstellen und Ausführen der Anwendung. Wenn Sie eine externe Datenbank einbinden müssen, empfehlen wir, eine separate Kopie davon zu erstellen und einzubinden; in einigen Fällen funktioniert auch eine separate Partition einer bestehenden DB. Für WordPress gibt es einige spezifische Schritte, die im letzten Kapitel beschrieben werden.
Sobald dies abgeschlossen ist, sollten Sie eine laufende Kopie Ihrer Anwendung haben, auf die Sie über die interne Codesphere-URL oder das Symbol "Open Deployment" zugreifen können.
Aktualisierungsprozess
Nachdem wir nun die Workspaces eingerichtet haben, gehen wir den Aktualisierungsprozess durch. Nehmen Sie zunächst wie gewohnt Aktualisierungen an Ihrem Code oder Ihren Daten vor, entweder direkt in Codesphere (im Staging Workspace!) oder nehmen Sie die Änderungen lokal vor und übertragen Sie sie in Ihren GitHub-Zweig.
Sobald die Änderungen in Ihr Repository übertragen wurden, öffnen Sie den zuvor angelegten Workspace, klicken Sie auf das +-Symbol, um ein Terminal zu öffnen, und geben Sie git pull ein. Sie können hier auch die üblichen Git-Befehle ausführen (z. B. Umschalten zwischen entfernten Zweigen, Rollback usw.). Wenn Ihr Repository privat ist, müssen Sie sich mit einem persönlichen Zugangstoken authentifizieren (siehe GitHub-Dokumentation, wenn Sie zuerst einen einrichten müssen).
Überprüfung der Änderungen
Stellen Sie sicher, dass Ihre Anwendung mit der neuesten Version des Codes läuft (d.h. führen Sie den Build-Befehl oder die CI-Stufe erneut aus) und öffnen Sie die Codesphere-URL dieses Workspace. Testen Sie Ihre Änderungen so gründlich wie nötig. Sobald Sie sicher sind, dass alles wie erwartet funktioniert, können Sie die Änderungen in die Production deployen.
Preview Deployments
Die Aktualisierung Ihrer Produktions-URL zur Verwendung der neuesten Version des Codes, den Sie gerade in der Staging-Umgebung getestet haben, ist mit wenigen Klicks erledigt.
- Navigieren Sie zur Registerkarte Domains
- Klicken Sie auf "Bearbeiten".
- Wechseln Sie den Workspace, in dem Ihre Produktionsumgebung läuft, mit dem Staging-Workspace
- Klicken Sie auf "Aktualisieren".
Jetzt werden Ihre User sofort auf die neue Version der Anwendung weitergeleitet.
Das Besondere an dieser Einrichtung ist, dass Sie, wenn Sie feststellen, dass etwas schief läuft, genauso einfach zur alten Version zurückkehren können, indem Sie den anderen Workspace erneut verbinden. Dadurch wird das Risiko eines Produktionsausfalls erheblich minimiert.
WordPress-Besonderheiten
Bei WordPress erfordert der Wechsel zwischen Prod und Staging aufgrund der Interaktion mit der Datenbank einige zusätzliche Handgriffe. Sie benötigen eine separate Datenbank (eine Kopie der Production), bevor Sie Änderungen im Staging Workspace vornehmen.
Nachdem Ihre Aktualisierungen fertiggestellt und getestet sind und in die Produktion überführt werden können, müssen Sie zunächst die letzten vom User generierten Änderungen in die Staging-Datenbank übertragen. Es gibt ein kleines Zeitfenster (zwischen dem Kopieren der Tabellen), in dem die Änderungen für die Produktion (z. B. die Anmeldungen) verloren gehen. Normalerweise dauert das Kopieren und Anwenden des Dumps etwa 30 Minuten. Wenn dies ein Problem darstellt, empfehlen wir, Ihre Website in den Wartungsmodus zu versetzen, bevor Sie fortfahren.
Wählen Sie in der Production die Tabellen aus, die übernommen werden sollen (d.h. User, Kommentare, Passwortänderungen, Plugin-Tabellen, alles, was sich aufgrund von Benutzereingaben ändert) und erstellen Sie einen Datenbank-Dump. Die Tabellennamen werden je nach Ihrer Installation leicht variieren, haben aber ein ähnliches Format wie das folgende: wp_xxxxxx_comments
mysqldump -yourdbhost -udoadmin -P25060 defaultdb table1 table2 > mytabledump.sql
Vergewissern Sie sich, dass Sie db host, user, port, dbname und tables an Ihre spezifischen Werte anpassen. Entfernen Sie Anweisungen, die Superuser-Rechte erfordern, da sie fehlschlagen könnten.
Als Nächstes müssen Sie diesen Datenbank-Dump auf Ihre Staging-Datenbank anwenden. Der Befehl wird ähnlich aussehen wie der vorherige.
Sobald dies abgeschlossen ist, können Sie den mit Ihrer Domäne verbundenen Workspace wie zuvor beschrieben austauschen. Wir empfehlen, die alte Einrichtung für etwa eine Woche aufzubewahren, falls Probleme auftreten, danach kann sie gelöscht werden.