Teil 5/5: Umzug, Launch und weitere Schritte
Moin!
Im heutigen, letzten Teil möchte ich dir erzählen, wie wir Projekte veröffentlichen und wie es danach weitergeht.
Im 3. Teil habe ich dir ja bereits erzählt, wie wir Deployer nutzen, um einen lokalen Entwicklungsstand auf einer STAGE zu veröffentlichen.
Und im 4. Teil (letzte Woche) habe dir davon erzählt, wie wir die STAGE als Zentrale nutzen, um datenbankbasierte Änderungen zu machen und wie wir Deployer nutzen, um sowohl Datenbank-Änderungen als auch Inhaltsdateien (in files) zu synchronisieren.
Um nun den letzten Stand der Entwicklung auf dem LIVE-Server zu veröffentlichen, nutzen wir ebenfalls Deployer. Dafür richten wir einen weiteren Host ein und veröffentlichen unsere Entwicklung mit dep deploy. Dadurch haben wir bereits alle für Contao notwendigen Dateien auf dem LIVE-Server.
Nun hinterlege ich noch die Datenbank-Zugangsdaten in der .env.local und synchronisiere dann mit dep database:release die Datenbank auf dem LIVE-Server.
Jetzt fehlen lediglich die Inhaltsdateien. Wir haben uns damals bewusst gegen ein Deployer Recipe entschieden, das die Dateien in files auf einem Server veröffentlicht. Die Sorge, dass der Befehl versehentlich verwendet wird und Dateien ohne Backup dann überschrieben werden, war einfach zu groß. Stattdessen nutzen wir für diesen (einmaligen) Vorgang SFTP oder SSH.
Nachdem 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ört neben der Aktivierung von z.B. Skripten für Besucherstatistiken oder der Einrichtung der Google Search Console auch die Einrichtung einer optimierten .htaccess.
Eine Vorlage, wie diese .htaccess aussehen kann, findest du in unserem Nutshell Starterkit.
Hier wird zum Beispiel das Caching für bestimmte Dateitypen festgelegt, aber auch Weiterleitungen z.B. 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.
Nun kann die Website unsererseits offiziell online gehen.
Nach dem Launch bieten wir für alle Projekte, die wir entwickelt haben, auch 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 werden von uns aber nicht händisch erstellt. Stattdessen kümmert sich Gitlab (nach einmaliger Einrichtung) um unsere automatisierten Backups. Kann ein Backup nicht erfolgreich durchgeführt werden, bekommen wir eine Nachricht, sodass wir uns das Problem genauer ansehen können.
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 sogar noch einen Schritt weiter und lassen Gitlab die Updates automatisiert durchführen. Für die Zukunft ist angedacht, auch die Funktionstests mithilfe von Cypress zu automatisieren, sodass wir nur noch eingreifen müssen, wenn ein Update zu neuen Problemen führt. Aber bis dahin führen wir die Tests selbst durch oder bekommen dank unserer Kunden und Seitenbesucher auch relativ schnell Feedback, wenn eine Funktion unserer Website fehlerhaft ist.
***
Damit sind wir am Ende dieser kleinen 5-teiligen E-Mail-Serie angekommen. Ab nächste Woche geht es wieder mit unserer Flaschenpost weiter (noch nicht abonniert?).
Möchtest du noch mehr darüber erfahren, wie wir Contao Projekte entwickeln? Dann lass uns doch einfach gemeinsam an deinen Projekten arbeiten. Oder ich zeige dir im Rahmen einer Schulung, wie du noch bessere Projekte mit Contao umsetzt. Antworte dafür einfach auf diese Mail!
Viele Grüße,
Dennis