Anstatt die Datenbank automatisch zu aktualisieren, generieren Sie ein SQL-Skript mit fließendem N-Hibernate für die Produktionsumgebung

Question

Ich habe einen Blick auf die verschiedenen Dokumentationen geworfen, aber nichts gefunden, was sich mit diesem Problem befasst.Ich denke darüber nach, Fluentmigrator für zukünftige Projekte zu verwenden, obwohl für Staging-/Produktionspraktiken Schemaaktualisierungen über einen DBA durchgeführt werden müssen.Ich darf für andere Umgebungen wie Testen, Entwickeln und Lokal tun, was ich will.

Der Zweck des Tools wird völlig zunichte gemacht, wenn ich sowieso die Skripte schreiben muss, um die Änderungen vorzunehmen.Mir kam jedoch der Gedanke, was wäre, wenn ich es nicht täte?Meine Frage lautet also:Ist es möglich, dass Fluent Migrate ein SQL-Skript in eine Datei ausspuckt, anstatt die Transaktion tatsächlich auszuführen?

In meinen Experimenten habe ich eine Konsolen-App erstellt, die dieselbe DAL-Assembly wie das Hauptprojekt verwendet und die Migrationslogik nutzt, sodass sie die Datenbank bei jeder Ausführung der Konsolen-App von Grund auf oder je nach meiner Wahl vom nächstgelegenen Punkt aktualisiert .Wir verwenden TeamCity und dachten daher, es wäre cool, die App ausführen zu lassen und das Skript (als Artefakt) in einem Ordner abzulegen, da dies ein Schritt im Build-Prozess für unseren DBA wäre. In den Umgebungen würde es verpönt sein, das Schema selbst zu aktualisieren.

Answer 1

Der FluentMigrator-Befehlszeilen-Runner generiert SQL-Skripte, ohne die Änderungen auf die Datenbank anzuwenden, wenn Sie Folgendes verwenden:

• --preview=true
• --output=true
• --outputFilename=output1.sql

Und wenn Sie das installieren FluentMigrator.Tools-Paket in Ergänzung zu FluentMigrator-Paket, haben Sie über das Build-Ausgabeverzeichnis des Migrationsprojekts Zugriff auf den Command Line Runner (Migrate.exe).

Notiz:Die generierten Skripte enthalten Einfügungen in die FluentMigrator-Versionstabelle.

Answer 2

After reading Command Line Runner Options I'd use --verbose=true to output the sql script and --output to save it to a file. There seems to be no 'dry run' option however - you'll need to run the migration in some preproduction environment to obtain the script.

Give it a shot as I've admittedly never tried it.