feat: complete notdienst planning, quick wins and notifications
This commit is contained in:
@@ -60,12 +60,9 @@ Parallele Änderungen laufen in serialisierbaren Datenbanktransaktionen mit Wied
|
||||
|
||||
## Einführung und Schema
|
||||
|
||||
Das Projekt verwendet weiterhin seinen vorhandenen Ablauf mit `prisma db push`. Es gibt keine vollständige versionierte Prisma-Migrationshistorie. Die neuen Tabellen sind additiv; vorhandene Personen erhalten noch kein automatisch befülltes Beschäftigungsprofil.
|
||||
Aktuelle Releases verwenden die versionierten Migrationen in `prisma/migrations` und einen separaten Initialisierungsdienst vor dem App-Start. Die [zentrale Betriebsanleitung](../deploy/README.md) beschreibt Installation, Updates, Baseline für bestehende Datenbanken und Runtime-Grants. `scripts/start-production.sh` startet die Anwendung; es verändert das Schema nicht. Kein `prisma db push` auf verwalteten Datenbanken verwenden.
|
||||
|
||||
- Lokal: Abhängigkeiten installieren, Prisma-Client generieren, Schema gegen eine dafür vorgesehene Datenbank anwenden, App starten und Profile einrichten.
|
||||
- Im vorhandenen Docker-Ablauf erzeugt `npm run build:prod` den Client; `scripts/start-production.sh` wendet das Schema vor App-Start an.
|
||||
- [Prüfbares SQL](../deploy/sql/personalbereich.sql) beschreibt dieselbe additive Änderung gegen den dokumentierten Ausgangsstand. Es ist einmalig und nicht idempotent. Entweder den vorhandenen Schemaabgleich **oder** dieses SQL verwenden; das SQL nicht nach bereits erfolgtem Schemaabgleich erneut ausführen.
|
||||
- Ist der Personalbereich bereits auf Stand `043fed2` eingeführt, beschreibt [Personalbereich-E-Mail-SQL](../deploy/sql/personalbereich-email.sql) ausschließlich die zusätzlichen Mail-Tabellen und die Profileinstellung. Auch dieses Skript ist eine einmalige Alternative zum Schemaabgleich.
|
||||
Die historischen SQL-Dateien [Personalbereich](../deploy/sql/personalbereich.sql) und [Personalbereich-E-Mails](../deploy/sql/personalbereich-email.sql) dokumentieren ihre damaligen Ausgangsstände. Sie sind kein aktueller Deployment-Schritt und dürfen nicht zusätzlich zu den versionierten Migrationen ausgeführt werden. Vorhandene Personen erhalten weiterhin erst durch Einrichtung ein Beschäftigungsprofil.
|
||||
|
||||
Die reale Projekt- und Produktionsdatenbank wurde bei dieser Umsetzung nicht verändert. Alle DB- und Browserprüfungen liefen mit synthetischen Daten in einer separaten lokalen PostgreSQL-Datenbank.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user