Das „Content Backup“ Script läuft automatisch per Cronjob und spielt alle am Content vorgenommenen Änderungen in unser Content-Repo. Damit sind wir jederzeit in der Lage, einen älteren Stand zurückzuspielen, wenn nötig und haben ein automatisiertes Backup auf Github liegen. Besonderheit: Sofern es eine unbearbeitete Seite gibt (erkennbar an .lock-Dateien) wird das Backup ausgesetzt und wir werden per Slack im passenden Channel darüber informiert, dass Änderungen gespeichert werden müssen, bevor das Backup erneut läuft.
Das „System Deployment“ Script erlaubt es uns, den aktuellen Entwicklungsstand vom Quality Assurance Environment produktiv zu bringen. Diese Entscheidung löst folgende automatische Pipeline aus:
- Hole neueste Docker-Version
- Baue Container mit neuester PHP-Version, CMS-Version und neuestem Ubuntu
- Nehme main-Branch des System-Repositorys und finalisiere Container
- Ersetze Container auf Production
- Done und Live!
Die Separation von Content und System ist dabei ein starker Mehrwert: So können wir Systemfunktionalität und Content autark voneinander weiterentwickeln, ohne dass nennenswerte Abhängigkeiten bestehen. Natürlich müssen wir gerade bei der Entwicklung / Änderung von Datenstrukturen auf die Kompatibilität zwischen Funktion und Daten achten, aber genau dafür haben wir ja unsere Dev- und Quality Assurance Umgebungen.
