Melhores práticas para a gestão de migrações que atualizar vários bancos de dados?

Question

A minha equipa está avaliando ferramentas e processos para a gestão de migrações de banco de dados / refatoração de banco de dados, como descrito por Martin Fowler, Pramod Sadalage, et. al. Nós estamos interessados ??em, processos repetitivos, testáveis ??automatizados, por isso não estamos interessados ??em técnicas como correr manualmente SQL Compare cada vez que implantar. Nós estamos usando atualmente CruiseControl.NET para integração contínua.

O nosso ambiente de produção tem vários servidores de banco de dados SQL Server 2000 com a replicação entre eles. Nossos migrações vai tornando alterações ao esquema no servidor de banco de dados de origem e de destino.

Para executar essa migração com uma ferramenta como o dbdeploy, parece que seria necessário para executar a migração contra um dos servidores, e nós teríamos que adicionar os outros servidores como servidores vinculados. Um único script em execução contra o servidor principal poderia, assim, executar DDL contra qualquer um dos servidores vinculados.

A minha pergunta é esta: será que esta abordagem ser considerada uma prática recomendada, ou há uma melhor técnica para a aplicação de migrações que tocam vários servidores de banco de dados

?

Answer 1

Eu não vejo nada de intrinsecamente errado com esta abordagem, no entanto, quando configurá-lo certifique-se de testar o que acontece quando um dos servidores ligados é baixo. Você não quer estar rolando para trás todos os outros servidores se passa a ser para baixo e você quer saber as alterações não foram aplicados a esse servidor.

Claro que a primeira melhor prática, mais importante para qualquer migração é ter certeza que você tem um processo de backup sólido no lugar antes de iniciar a migração de alterações.

Answer 2

Visual Studio 2008 (Team Edition, especificamente GDR) pode lidar com a implantação automatizada de esquema contra o arquivo de esquema definido / metadados que você pode implantar para os servidores. Esta poderia ser incluído no seu processo de criação / implantação. No entanto, eu acho que ainda há uma questão sobre alterações de replicação e de esquema - não há nenhum pacote que compreende / é ciente de sua configuração de replicação.

Por exemplo, usamos procedimentos de replicação personalizados no assinante e embora as alterações do esquema propagar do editor às vezes temos de script manualmente muda dependendo qualquer replicação personalizado que temos no lugar. Se você não usar procs replicação costume, eu diria que este era o caminho a percorrer.

Answer 3

Você pode experimentar uma combinação de Chinchillin e Wizardby :. instalar agentes chinchillin em servidores de banco de dados e tê-lo executar scripts de migração Wizardby durante o seu processo de implantação

Esta integração está em obras, embora:)

Answer 4

Aqui na Red Gate agora temos uma solução migrações repetíveis que usa o SQL Compare e Controle de origem SQL. A linha de comando SQL Compare, portanto, pode ser usado para apoiar um processo de integração contínua.

http://www.red-gate.com/MessageBoard /viewtopic.php?t=14107

É atualmente uma compilação acesso antecipado, por isso estamos interessados ??em obter feedback tanto quanto possível.