En god måde at holde styr på skemaændringer på tværs af flere grene af et udviklingsprojekt ville være at følge en databaserefaktorering behandle. Blandt andre fordele inkorporerer denne form for proces brugen af delta- og migreringsscripts til at anvende skemaændringer til hvert miljø (eller gren i dit tilfælde). Opsætningen kunne se sådan ud:
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
Hver gang du skal ændre databaseskemaet for en bestemt gren, opretter du et SQL delta-script, der bruges til at anvende ændringen. For at gøre det nemmere vil jeg foreslå at navngive hver scriptfil for at inkludere oprettelsesdato og -klokkeslæt for at holde dem i rækkefølge. Eksempel ville være:
201102231435_addcolumn.sql
201102231447_addconstraint.sql
201103010845_anotherchange.sql
Tilføj deltafilerne til kildekontrol i den gren, hvor skemaændringen skal foretages. Du bør ende med at hver gren indeholder præcis det, der er nødvendigt for at ændre den tilsvarende database. Nogle detaljer skal muligvis justeres til din situation afhængigt af ting som din forgreningsordning, og hvorvidt din database bevares under din udgivelsesproces (i modsætning til genskabt).
Til sidst, for at prøve at gøre disse koncepter enkle, vil jeg anbefale et værktøj til at hjælpe med at styre processen. Mit forslag er at tage et kig på DBDeploy / DBDeploy.NET . Jeg har med glæde brugt det i årevis på alle mine projekter.