Launch: Go-Live und Wartung
Teil 5 unserer Serie zum Projekt-Workflow — vorher: Teamarbeit: Datenbank-Änderungen nur in eine Richtung synchronisieren.
Um den letzten Stand der Entwicklung auf dem Live-Server zu veröffentlichen, nutzen wir ebenfalls Deployer: Wir richten einen weiteren Host ein und veröffentlichen die Entwicklung mit dep deploy. Damit liegen bereits alle für Contao notwendigen Dateien auf dem Live-Server.
Anschließend hinterlegen wir die Datenbank-Zugangsdaten in der .env.local (siehe Umgebungsvariablen in Contao: die Dotenv) und synchronisieren mit dep database:release die Datenbank auf den Live-Server.
Jetzt fehlen lediglich die Inhaltsdateien. Wir haben uns bewusst gegen ein Deployer-Recipe entschieden, das die Dateien in files auf einem Server veröffentlicht — die Sorge war zu groß, dass der Befehl versehentlich verwendet wird und Dateien ohne Backup überschrieben werden. Stattdessen nutzen wir für diesen einmaligen Vorgang SFTP oder SSH.
Launch-Vorbereitung
Sobald die Installation vollständig und lauffähig ist und die abschließenden Tests problemlos verliefen (z. B. der Formularversand), bereiten wir die Website für den Launch vor. Dazu gehören die Aktivierung von Skripten für Besucherstatistiken, die Einrichtung der Google Search Console — und eine optimierte .htaccess.
Eine Vorlage, wie diese .htaccess aussehen kann, findest du im Nutshell Starterkit. Dort wird zum Beispiel das Caching für bestimmte Dateitypen festgelegt, aber auch Weiterleitungen von http auf https und von ohne www auf mit www.
Da ein paar dieser Anweisungen für die Entwicklung von Nachteil sind, nutzen wir diese .htaccess nur auf dem Live-Server. In den Nutshell-Recipes für Deployer gibt es dafür eine eigene Option: Custom .htaccess file per host.
Damit kann die Website offiziell online gehen.
Nach dem Launch: Wartung
Für alle Projekte, die wir entwickelt haben, bieten wir Wartungsverträge an. Diese beinhalten zum Beispiel wöchentliche Backups von Dateien und Datenbank. Das ist sogar dann sinnvoll, wenn der Hoster eigentlich selbst Backups erstellt (Beispiel).
Diese Backups erstellen wir nicht händisch: Nach einmaliger Einrichtung kümmert sich GitLab um die automatisierten Backups. Kann ein Backup nicht erfolgreich durchgeführt werden, bekommen wir eine Nachricht und können uns das Problem genauer ansehen.
Außerdem führen wir im Rahmen des Wartungsvertrags monatliche Updates durch. Diese laufen größtenteils halbautomatisch über Trakked, da wir danach noch die wichtigsten Funktionen (z. B. den Formularversand) testen.
Bei unseren eigenen Websites gehen wir noch einen Schritt weiter und lassen GitLab die Updates automatisiert durchführen. Perspektivisch sollen auch die Funktionstests mithilfe von Cypress automatisiert werden, sodass wir nur noch eingreifen müssen, wenn ein Update zu neuen Problemen führt.