Entwerfen eines vollständigen Datenbankmigrationsstapels

Question

Während der Entwicklung gefällt mir die Idee, dass Frameworks wie Entity Framework 4.3 Migrations (obwohl ich es brauche, um mit SQL-Skripten anstelle von Migrationsklassen zu arbeiten) alle Entwicklerdatenbanken auf dem neuesten Stand halten.Jemand führt ein Update durch, um die neueste Quelle zu erhalten. Er versucht, die Anwendung auszuführen und erhält die Fehlermeldung, dass er seine Datenbank auf die neueste Migration aktualisieren muss (oder die Migration automatisch durchführen lassen muss).Migrationsdateien sind mit einem Zeitstempel versehen, sodass sich Entwickler keine Gedanken darüber machen müssen, ob zwei Dateien den gleichen Namen haben oder in welcher Reihenfolge die Dateien ausgeführt werden müssen.

Wenn ich bereit bin, ein WebDeploy-Bereitstellungspaket zu erstellen, möchte ich, dass das Paket die Skripts enthält, die zum Verschieben der Produktionsdatenbank auf die neueste Datenbankversion erforderlich sind.Daher müssen MSBuild oder WebDeploy irgendwie eine Entscheidung darüber treffen, welche Skripte gepackt werden müssen.Für die Bereitstellung möchte ich nicht, dass die Anwendung versucht, sich selbst zu aktualisieren, wie es EF bietet.Ich möchte das Paket entweder der IT-Abteilung übergeben oder eine automatische Bereitstellung über einen Bereitstellungsserver durchführen.

Einige meiner Fragen sind:

1. Kann EF 4.3 für meine Entwicklungsanforderungen mit SQL-Skripten anstelle von DBMigration-Klassen arbeiten (ich verwende es bereits für mein ORM, daher wäre es schön, wenn es könnte)?

2. Versteht MSBuild oder WebDeploy das Konzept der Datenbankmigrationen (z. B.Erkennt es die EF?4.3 migrationHistory-Tabelle) oder muss ich sicherstellen, dass ich ihm nur die Skripts gebe, die er ausführen muss, um meine Produktdatenbank auf die neueste Migration zu bringen?Ich möchte nicht manuell entscheiden, welche Skripte gepackt werden sollen. Gibt es eine MS WebDeploy-Erweiterung, die Migrationen versteht?

3. Sind meine Bedenken und Ideen berechtigt?Ich recherchiere nur zu diesem Thema, also weiß ich es nicht wirklich.

Answer 1

Ich denke, dass Ihre Bedenken berechtigt sind.Während der Entwicklung genügt alles, was die Entwicklermaschinen synchron hält.Bei der Bereitstellung ist mehr Kontrolle erforderlich.

In meinem Projekt haben wir uns entschieden, nur codebasierte Migrationen zu verwenden, um sicherzustellen, dass alle Datenbanken in derselben Reihenfolge und mit denselben Schritten migriert werden.Die automatische Migration und Datenbankerstellung wird durch eine benutzerdefinierte Initialisierungsstrategie deaktiviert, die nur prüft, ob die Datenbank vorhanden und gültig ist.

Mehr zu den Details habe ich in geschrieben Verhindern Sie, dass EF-Migrationen die Datenbank erstellen oder ändern.Ich habe auch ein bisschen nachgeschaut Konflikte zusammenführen was irgendwann bei mehreren Entwicklern passieren wird.

Answer 2

1. Sie können SQL in den Klassen ausführen, indem Sie die Sql-Methode aufrufen, oder SQL aus einer Migration generieren, indem Sie den Parameter -script mit dem Befehl update-database verwenden.

2. NEIN.Sie wollten Unterstützung für WebDeploy hinzufügen, haben sich aber offenbar vor RTM dagegen entschieden.Sie haben jedoch eine Befehlszeilen-App (und natürlich ein Powershell-Skript) veröffentlicht, die Sie von beiden aus aufrufen können.

In meinen Projekten erstelle ich ein Startmodul in meinen Anwendungen und führe alle Migrationen aus, die nicht automatisch bereitgestellt wurden. Auslösen der EF-Migration beim Anwendungsstart durch Code.Es ist nicht perfekt, Entwickler müssen die App ausführen, nachdem sie die neueste Version erhalten haben, bevor sie die Datenbank ändern können, aber es funktioniert sowohl für die neueste Version als auch für die Bereitstellung.