Die Qualität von LydiaCMS sichern statische Analyse, Tests und eine Release-Pipeline. Was sich automatisieren lässt, automatisiere ich: von der Codeprüfung bis zum Deployment.
Statische Analyse von PHP: PHPStan und Rector
PHPStan läuft auf der höchsten Stufe (max) mit 8 eigenen Regeln, die die Konventionen des Projekts überwachen, und 14 eigene Rector-Regeln können Abweichungen in allen Paketen gesammelt korrigieren. Das Ergebnis ist eine höhere Codequalität: Fehler in der Architektur werden bei der Analyse gefunden und nicht erst zur Laufzeit. Code: PHPStan, Rector.
Tests: Nette Tester und E2E in Playwright
- Der Kern hat über 600 Unit- und Integrationstests in Nette Tester. Sie laufen parallel, und jeder Thread arbeitet mit einem eigenen Präfix der Datenbanktabellen.
- Die Beispielanwendung hat eine Suite von E2E-Tests in Playwright (über 30 Dateien), die den öffentlichen Teil der Website und die Administration durchläuft.
- Die Tests der Pakete PHPStan und Rector laufen in der CI-Pipeline, die Tests des Kerns führe ich lokal in Docker aus.
CI/CD-Pipeline in GitLab: automatische Versionen und Veröffentlichung von Paketen
Pakete werden aus einer privaten Composer-Registry installiert, deshalb muss jede Veröffentlichung einheitlich und ohne manuellen Schritt ablaufen. Alle Pakete nutzen daher eine gemeinsame Pipeline in GitLab, und Änderungen am Prozess werden an einer einzigen Stelle vorgenommen. Sie hat drei Phasen:
- Check.
composer validate --strictund eine Syntaxprüfung von PHP in allen Quellen. Schlägt sie fehl, wird das Paket nicht veröffentlicht. - Tag. Auf dem Hauptzweig wird die nächste Version berechnet und gesendet.
- Build. Der gesendete Tag veröffentlicht das Paket in der Composer-Registry, und die Anwendung holt sich die neue Version mit
composer update.
Deployment ohne Ausfallzeit (Zero-Downtime-Deployment)
Eine neue Version der Website wird nicht direkt in die laufende Anwendung eingespielt. Ein Skript bereitet neben ihr ein vollständiges neues Release vor und schaltet erst um, wenn es geprüft ist:
- baut das Release aus dem Zweig und installiert die Abhängigkeiten ohne Entwicklerpakete,
- bindet die gemeinsamen Daten ein (
.env, Logs, hochgeladene Dateien), - startet die Anwendung probeweise, sodass ein fehlerhafter Build nie bis zum Umschalten kommt,
- sichert die Datenbank und führt die Migrationen aus (
lydiacms:upgrade), - prüft die Website mit einem Health-Check und kehrt bei einem Fehler selbstständig zum vorherigen Release zurück.
Backup und Rollback
Vor den Migrationen wird die Datenbank gesichert. Bei einem Problem lassen sich sowohl das vorherige Release (Dateien) als auch die Datenbank aus dem Backup wiederherstellen.