Martin Fowler skrev min yndlingsartikel om emnet, http://martinfowler.com/articles/evodb.html. Jeg vælger ikke at lægge skemadumps ind under versionskontrol som alumb og andre foreslår, fordi jeg vil have en nem måde at opgradere min produktionsdatabase på.
Til en webapplikation, hvor jeg har en enkelt produktionsdatabaseinstans, bruger jeg to teknikker:
Databaseopgraderingsscripts
En sekvensdatabaseopgraderingsscripts, der indeholder den nødvendige DDL for at flytte skemaet fra version N til N+1. (Disse går i dit versionskontrolsystem.) En _version_history_ tabel, noget i stil med
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
får en ny post hver gang et opgraderingsscript kører, som svarer til den nye version.
Dette sikrer, at det er nemt at se, hvilken version af databaseskemaet der findes, og at databaseopgraderingsscripts kun køres én gang. Igen, disse er ikke database dumps. Hvert script repræsenterer snarere ændringerne nødvendigt at flytte fra en version til den næste. De er det script, du anvender på din produktionsdatabase for at "opgradere" den.
Udviklersandkassesynkronisering
- Et script til at sikkerhedskopiere, rense og formindske en produktionsdatabase. Kør dette efter hver opgradering til produktions-DB.
- Et script til at gendanne (og justere, om nødvendigt) sikkerhedskopien på en udviklers arbejdsstation. Hver udvikler kører dette script efter hver opgradering til produktions-DB.
En advarsel:Mine automatiserede test kører mod en skemakorrekt, men tom database, så dette råd vil ikke passe perfekt til dine behov.