Martin Fowler escreveu meu artigo favorito sobre o assunto, http://martinfowler.com/articles/evodb.html. Eu escolho não colocar despejos de esquema sob controle de versão como alumb e outros sugerem porque quero uma maneira fácil de atualizar meu banco de dados de produção.
Para um aplicativo da Web em que terei uma única instância de banco de dados de produção, uso duas técnicas:
Scripts de atualização do banco de dados
Uma sequência de scripts de atualização de banco de dados que contém o DDL necessário para mover o esquema da versão N para N+1. (Estes vão em seu sistema de controle de versão.) Uma tabela _version_history_, algo como
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
obtém uma nova entrada toda vez que um script de atualização é executado, o que corresponde à nova versão.
Isso garante que seja fácil ver qual versão do esquema de banco de dados existe e que os scripts de atualização de banco de dados sejam executados apenas uma vez. Novamente, estes não despejos de banco de dados. Em vez disso, cada script representa as alterações necessário passar de uma versão para outra. Eles são o script que você aplica ao seu banco de dados de produção para "atualizá-lo".
Sincronização de sandbox do desenvolvedor
- Um script para fazer backup, limpar e reduzir um banco de dados de produção. Execute isso após cada atualização para o banco de dados de produção.
- Um script para restaurar (e ajustar, se necessário) o backup na estação de trabalho de um desenvolvedor. Cada desenvolvedor executa esse script após cada atualização para o banco de dados de produção.
Uma ressalva:meus testes automatizados são executados em um banco de dados com esquema correto, mas vazio, portanto, este conselho não atenderá perfeitamente às suas necessidades.
