Skip to main content

​
Update vorbereiten

  1. Zielbranch, Commit beziehungsweise Image-Version ausdrücklich festlegen.
  2. Änderungen und Freigaben prüfen.
  3. Sicherung und Wiederherstellung vorbereiten.
  4. Offene Verarbeitung nach dem Wartungsleitfaden ausschließen.
  5. Migrationen vorab als konkretes SQL prüfen und freigeben.
  6. Schemaänderungen vor API-/Frontend-Code ausführen lassen, der sie benötigt.
  7. Start und fachliche Lesekontrollen nachweisen.
Das Repository enthält nummerierte SQL-Migrationen sowie Deployment- und Schema-Prüfskripte. Prüfe diese für die tatsächlich verwendete Image-Version. Ein erfolgreich gemeldeter Build beweist nicht, dass eine Migration in der Zielumgebung ausgeführt wurde.
Historische Deployment-Stände verwendeten drizzle-kit push --force. Das kann destruktive Schemaänderungen ohne Rückfrage ausführen und ersetzt keinen geprüften Migrationsplan. Verwende eine solche Schemaangleichung nicht als spontane Fehlerbehebung.

​
Bestehende Belege schützen

Neue nullable Schnappschuss-Spalten sind additiv. Alte Zeilen ohne Schnappschuss müssen weiter lesbar bleiben. Bereits gebuchte Archive, Exporte und Belegschnappschüsse werden nicht rückwirkend aus aktuellen Positionen neu berechnet.

​
Versionen abgleichen

Unterscheide: Diese Stände können auseinanderliegen. Ein Branchwechsel kann ältere Frontend-Dateien ausliefern, während ein bereits gestarteter API-Prozess noch den vorherigen Code verwendet. Dokumentationsänderungen allein verändern nicht die Anwendungsversion. Ein neuer Eintrag in der Datenbank-Versionshistorie benötigt die gesonderte Schreibfreigabe.

​
Rückfall

Plane vorab, welcher Code mit welchem Schema kompatibel ist. Setze nach einer fehlgeschlagenen Buchung oder einem unklaren Export nicht einfach alte Daten zurück. Prüfe zuerst die bereits ausgeführten Schritte und entfernten Auswirkungen.