Job

Ein Kubernetes Job führt die Flyway-Migration kontrolliert vor dem Rollout einer neuen Backend-Version aus. Damit wird vermieden, dass mehrere Backend-Pods gleichzeitig das Schema verändern.

Flyway-Job

Der geplante Job bflies-flyway verwendet:

• ein eindeutig versioniertes Migrationsimage beziehungsweise das freigegebene Backend-Image,
• dieselben Datenbankverbindungsdaten wie das Backend,
• das Datenbank-Secret,
• den internen Datenbank-Service,
• eine zum Release passende Menge versionierter Migrationen.

Ablauf

1. GitLab deployt oder startet den Flyway-Job.
2. Der Job wartet auf die erreichbare Datenbank.
3. Flyway prüft Baseline, Checksummen und ausstehende Migrationen.
4. Die Migration wird genau einmal ausgeführt.
5. Nur bei erfolgreichem Abschluss wird das Backend ausgerollt.
6. Jobstatus und Logs bleiben für die Diagnose verfügbar.

Fehlerverhalten

Ein fehlgeschlagener Job stoppt das Release. Das Backend darf dann nicht automatisch auf eine Version aktualisiert werden, die ein neueres Schema erwartet. Datenbank-Rollback und Restore werden je Migration vor der Produktionsfreigabe bewertet.

Noch zu entscheiden

• Erzeugung des eindeutigen Jobnamens pro Release,
• Aufbewahrung erfolgreicher und fehlgeschlagener Jobs,
• Timeouts und Retry-Verhalten,
• technische Umsetzung in GitLab und Kustomize.