5. Updates¶
Pfarrplaner kann sich in einem Release an mehreren Stellen ändern: PHP-Abhängigkeiten, npm-Abhängigkeiten, Assets, Migrationen, Views, Queue-Verhalten oder Laufzeitprozesse. Ein gutes Update besteht deshalb nie nur aus einem git pull.
5.1. Grundregel¶
Vor jedem Update brauchen Sie:
- aktuelles Backup der Datenbank
- Sicherung wichtiger Anwendungsdaten aus
storage/ - kurze Prüfung offener lokaler Änderungen
- Klarheit, auf welchem Branch die produktive Instanz läuft
5.2. Updatepfad 1: klassische Installation¶
Für klassische Installationen ist der vorgesehene Weg der Update-Befehl:
php artisan install:updates
Im Hintergrund wird das npm-Skript install:updates ausgeführt. Dieses Skript prüft unter anderem:
- ob ein Upstream-Branch vorhanden ist
- ob lokale Änderungen existieren
- ob
composer installnötig ist - ob
npm installnötig ist - ob Assets neu gebaut werden müssen
- ob Migrationen auszuführen sind
- ob Caches, Queue und Octane neu gestartet werden müssen
5.2.1. Trockentest¶
Vor produktiven Updates ist diese Prüfung sehr sinnvoll:
php artisan install:updates --dry-run
Damit sehen Sie, welche Schritte ein Update auslösen würde, ohne sie schon auszuführen.
5.2.2. Typischer produktiver Ablauf¶
- Backup erstellen.
php artisan install:updates --dry-run- Wartungsfenster oder kurzen Hinweis vorbereiten.
php artisan install:updates- Login, zentrale Ansichten, Mail und wichtige Berichte prüfen.
5.3. Updatepfad 2: Docker Compose¶
Im Containerbetrieb hängt das genaue Update von Ihrer Build-Strategie ab. Der sichere Grundablauf bleibt aber gleich:
- Backup von Datenbank und persistenten Volumes erstellen.
- Neues Image bauen oder ziehen.
- Container mit der neuen Version bereitstellen.
- Migrationen im App-Container ausführen.
- Queue-Worker und Scheduler auf die neue Version umstellen.
- Funktionstest durchführen.
Typische Befehle sehen zum Beispiel so aus:
docker compose pull
docker compose up -d
docker compose exec app php artisan migrate --force
docker compose exec app php artisan optimize
Wenn Sie Assets bereits im Image bauen, entfällt der Asset-Build auf dem Zielsystem. Wenn nicht, muss auch im Containerkontext ein neuer Frontend-Build Teil des Updates sein.
5.4. Rollback-Denken¶
Ein gutes Update ist erst dann sauber geplant, wenn Sie auch den Rückweg kennen.
Für klassische Installationen bedeutet das meist:
- vorherigen Git-Stand kennen
- Datenbank-Backup haben
- wissen, ob Migrationen rückwärts überhaupt sicher sind
Für Docker bedeutet das meist:
- vorheriges Image-Tag behalten
- alte Compose-Version oder Image-Referenz dokumentieren
- Datenbank-Backup vorhalten
5.5. Nach jedem Update prüfen¶
- Anmeldung
- Startseite
- Kalender
- Öffnen und Speichern eines Gottesdiensts
- ein Bericht oder Export
- Passwort-Reset oder Testmail
- Queue, Scheduler und Logs
- Chromium-basierte Ausgaben