Eine gute Möglichkeit, Schemaänderungen über mehrere Zweige eines Entwicklungsprojekts hinweg zu verfolgen, wäre, einem zu folgen Datenbank-Refaktorisierung Prozess. Neben anderen Vorteilen umfasst diese Art von Prozess die Verwendung von Delta- und Migrationsskripten, um Schemaänderungen auf jede Umgebung (oder in Ihrem Fall auf Zweige) anzuwenden. Das Setup könnte etwa so aussehen:
main
src <-- ASP.NET project source
db <-- Database create scripts
delta <-- Database change scripts (SQL delta files)
branch
src
db <-- usually has the same contents as the copy in main branch
delta <-- only the changes necessary for this branch
Jedes Mal, wenn Sie das Datenbankschema für einen bestimmten Zweig ändern müssen, erstellen Sie ein SQL-Delta-Skript, das verwendet wird, um die Änderung anzuwenden. Um es einfacher zu machen, würde ich vorschlagen, jede Skriptdatei so zu benennen, dass Datum und Uhrzeit der Erstellung enthalten sind, um sie in der Reihenfolge zu halten. Beispiel wäre:
201102231435_addcolumn.sql
201102231447_addconstraint.sql
201103010845_anotherchange.sql
Fügen Sie die Deltadateien zur Quellcodeverwaltung in dem Zweig hinzu, in dem die Schemaänderung vorgenommen werden muss. Am Ende sollte jeder Zweig genau das enthalten, was zum Ändern der entsprechenden Datenbank erforderlich ist. Einige Details müssen möglicherweise an Ihre Situation angepasst werden, abhängig von Dingen wie Ihrem Verzweigungsschema und davon, ob Ihre Datenbank während Ihres Veröffentlichungsprozesses beibehalten (im Gegensatz zu neu erstellt) wird oder nicht.
Um diese Konzepte zu vereinfachen, würde ich schließlich ein Tool empfehlen, das bei der Verwaltung des Prozesses hilft. Mein Vorschlag ist, einen Blick auf DBDeploy zu werfen / DBDeploy.NET . Ich verwende es seit Jahren gerne bei all meinen Projekten.
