Martin Fowler schreef mijn favoriete artikel over dit onderwerp, http://martinfowler.com/articles/evodb.html. Ik kies ervoor om schemadumps niet onder versiebeheer te plaatsen als alumb en anderen suggereren omdat ik een gemakkelijke manier wil om mijn productiedatabase te upgraden.
Voor een webtoepassing waar ik een enkele productiedatabase-instantie heb, gebruik ik twee technieken:
Scripts voor database-upgrade
Een reeks database-upgradescripts die de DDL bevatten die nodig is om het schema van versie N naar N+1 te verplaatsen. (Deze gaan in uw versiebeheersysteem.) Een _version_history_-tabel, zoiets als
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
krijgt elke keer dat een upgradescript wordt uitgevoerd een nieuw item dat overeenkomt met de nieuwe versie.
Dit zorgt ervoor dat het gemakkelijk is om te zien welke versie van het databaseschema bestaat en dat database-upgradescripts slechts één keer worden uitgevoerd. Nogmaals, dit zijn niet database-dumps. In plaats daarvan vertegenwoordigt elk script de veranderingen nodig om van de ene versie naar de volgende te gaan. Ze zijn het script dat u toepast op uw productiedatabase om deze te "upgraden".
Sandbox-synchronisatie voor ontwikkelaars
- Een script om een productiedatabase te back-uppen, op te schonen en te verkleinen. Voer dit uit na elke upgrade naar de productie-DB.
- Een script om de back-up te herstellen (en indien nodig aan te passen) op het werkstation van een ontwikkelaar. Elke ontwikkelaar voert dit script uit na elke upgrade naar de productie-DB.
Een waarschuwing:mijn geautomatiseerde tests worden uitgevoerd tegen een schema-correcte maar lege database, dus dit advies zal niet perfect aansluiten bij uw behoeften.