Martin Fowler ha scritto il mio articolo preferito sull'argomento, http://martinfowler.com/articles/evodb.html. Scelgo di non mettere i dump dello schema sotto il controllo della versione come alumb e altri suggeriscono perché desidero un modo semplice per aggiornare il mio database di produzione.
Per un'applicazione Web in cui avrò una singola istanza di database di produzione, utilizzo due tecniche:
Script di aggiornamento del database
Una sequenza di script di aggiornamento del database che contiene il DDL necessario per spostare lo schema dalla versione N a N+1. (Questi vanno nel tuo sistema di controllo della versione.) Una tabella _version_history_, qualcosa come
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
ottiene una nuova voce ogni volta che viene eseguito uno script di aggiornamento che corrisponde alla nuova versione.
Ciò garantisce che sia facile vedere quale versione dello schema del database esiste e che gli script di aggiornamento del database vengano eseguiti solo una volta. Ancora una volta, questi non dump di database. Piuttosto, ogni script rappresenta le modifiche necessario per passare da una versione all'altra. Sono lo script che applichi al tuo database di produzione per "aggiornarlo".
Sincronizzazione sandbox per sviluppatori
- Uno script per eseguire il backup, disinfettare e ridurre un database di produzione. Eseguilo dopo ogni aggiornamento al DB di produzione.
- Uno script per ripristinare (e modificare, se necessario) il backup sulla workstation di uno sviluppatore. Ogni sviluppatore esegue questo script dopo ogni aggiornamento al DB di produzione.
Un avvertimento:i miei test automatici vengono eseguiti su un database corretto per lo schema ma vuoto, quindi questo consiglio non si adatta perfettamente alle tue esigenze.
