2017-11-28 2 views
3

Wir möchten Flyway so verwenden, dass wir die letzte Migration wiederholen können, solange die letzte schemaVersion noch nicht freigegeben ist, also die letzte db-Änderungsdatei nicht nur würde es erneut ausgeführt werden, aber wenn möglich, nach dem Löschen der letzten Änderungen (es ist also nicht genau das wiederholbare Migrationskonzept, das ich folge).Wiederholbare Migrationen nur innerhalb eines Releases (nur letzte Update-Datei) durch Spring Boot

Gibt es eine Lösung oder eine gute Idee, um dieses Problem zu lösen? Wir verwenden Spring Boot, um den Flyway-Prozess zu konfigurieren.

EDIT: Bisher (dank Axel) Ich fand heraus, diese zwei Alternativen:

  • 0.Increment Schema für jede Änderung, auch innerhalb eines Release (Vermeidung, dass die Motivation der Frage ist)

  • 1.Verwenden Sie die Eigenschaft spring.flyway.cleanOnValidationError in jeder Pipeline auf true/deploy vor dem Release eins Dies bedeutet, wenn wir jemals ein versioniertes Skript vor dem Snapshot ändern, würden wir beim Deployment feststellen die Freisetzungs-Pipeline

  • 2.Work mit wiederholbaren Migrationen (R__) und einige Hack machen, den Namen zu einer versioniert Migration während des Lösens Pipeline Problem zu ändern: SCHAFFT und Tropfen sind in Ordnung, aber Abspaltungen erfordern PL/SQL für die IF Teil VORHANDEN

  • 3.Ändern db Migration Anbieter auf einem, die Herabstufung unterstützt (die gleiche Zugweg Dokumentation sagt dies in der Regel eine problematische Idee ist)

Wenn niemand eine bessere Lösung findet, werde ich Axel Antwort acccept

+0

Ist dies nur für Dev oder für andere Umgebungen? –

+0

nur für dev, ich denke, Integrationsstufen verwenden immer die Version – Whimusical

+0

(so dass sie nie die Notwendigkeit für die Aktualisierung einer versionierten Schemadatei konfrontiert) – Whimusical

Antwort

2

Set flyway.cleanOnValidationError zu true, um zu bekommen, was Sie wollen (oder sehr nahe sowieso): schnelle Iteration in Dev, mit automatischer Schema-Wiederherstellung, wenn eine Migration sich ändert.

+0

Interessante Funktion. Dies bereinigt das Schema und beginnt alle Migrationen von Anfang an anzuwenden, wenn ich es richtig verstehe. Aber wie können wir garantieren, dass alle Skripte abzüglich der letzten die Konsistenz behalten, bevor wir den Fehler in der Produktion finden? – Whimusical

+0

Ich meine, das ist genau das gleiche wie das Wiederherstellen der db. Was passiert, wenn jemand ein vorher veröffentlichtes Schemamigrationsskript (nicht die "Snapshot" -Version) ändert und an CI/CD sendet ... Wir würden den Fehler später in der Pipeline erkennen, wenn Sie in Nicht-Entwicklungsumgebungen – Whimusical

+1

implementieren das in dev. Diese Arten von Fehlern werden gefunden, sobald Sie Ihre CI-Umgebung treffen. –

Verwandte Themen