Een goede manier om schemawijzigingen in meerdere takken van een ontwikkelingsproject bij te houden, is het volgen van een database refactoring werkwijze. Dit soort processen omvat naast andere voordelen het gebruik van delta- en migratiescripts om schemawijzigingen toe te passen op elke omgeving (of vertakking in uw geval). De opstelling zou er ongeveer zo uit kunnen zien:
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
Elke keer dat u het databaseschema voor een bepaalde branch moet wijzigen, maakt u een SQL-deltascript dat wordt gebruikt om de wijziging toe te passen. Om het gemakkelijker te maken, raad ik aan om elk scriptbestand een naam te geven met de aanmaakdatum en -tijd om ze op volgorde te houden. Voorbeeld zou zijn:
201102231435_addcolumn.sql
201102231447_addconstraint.sql
201103010845_anotherchange.sql
Voeg de delta-bestanden toe aan het bronbeheer in de vertakking waar de schemawijziging moet worden aangebracht. Je zou moeten eindigen met elke tak die precies bevat wat nodig is om de bijbehorende database te wijzigen. Sommige details moeten mogelijk worden aangepast aan uw situatie, afhankelijk van zaken als uw vertakkingsschema en of uw database behouden blijft tijdens uw releaseproces (in plaats van opnieuw gemaakt).
Ten slotte, om te proberen deze concepten eenvoudig te maken, zou ik een hulpmiddel aanbevelen om het proces te helpen beheren. Mijn suggestie is om een kijkje te nemen op DBDeploy / DBDeploy.NET . Ik gebruik het al jaren met veel plezier voor al mijn projecten.