Projetando uma pilha de migração de banco de dados completa

Question

Durante o desenvolvimento, gosto da ideia de estruturas como a Entidade Framework 4.3 migrações (embora eu precise que ele funcione com scripts SQL em vez de classes de migração) mantendo todos os bancos de dados de desenvolvedores atualizados. Alguém faz uma atualização para obter a fonte mais recente, eles tentam executar o aplicativo e obter um erro que eles precisam atualizar seu banco de dados para a última migração (ou ter a migração acontecer automaticamente). Arquivos de migração são timestamped, então os devs não precisam se preocupar em nomear dois arquivos da mesma ou sequência que os arquivos precisam ser executados.

Quando eu preparo para construir um pacote de implantação da WebDeploy, quero que o pacote contenha os scripts necessários para mover o banco de dados de produção para a versão mais recente do DB. Então, de alguma forma, MSBuild ou WebDeploy precisa tomar uma decisão sobre quais scripts devem ser embalados. Para implantação, não quero que o aplicativo tente se atualizar como o que a EF oferece. Eu quero usar o pacote para o departamento de TI ou fazer uma implantação automática por meio de um servidor de implementação.

Algumas das minhas perguntas são:

.

1. pode ef 4.3 trabalho com scripts SQL em vez de classes de dbmigration para minhas necessidades de desenvolvimento (eu já estou usando para o meu orm, então seria bom se pudesse)?

2. faz msbuild ou webdeploy entender o conceito de migrações do banco de dados (por exemplo, ele reconhece o EF 4.3 tabela migratória) ou eu tenho que ter certeza de dar-lhe apenas os scripts que ele precisa ser executado que trará meu prop db para a última migração? Decidir manualmente quais scripts devem ser padrastos não é algo que eu quero fazer, há uma extensão do MS WebDeploy que entende migrações?

3. são minhas preocupações e ideias válidas? Eu só estou pesquisando essas coisas, então eu realmente não sei.

Answer 1

Eu acho que suas preocupações são válidas.Durante o desenvolvimento, qualquer coisa que mantenha as máquinas de desenvolvedor em sincronia.Ao implantar, mais controle é necessário.

No meu projeto, decidimos usar apenas migrações baseadas em código, para garantir que todos os bancos de dados sejam migrados na mesma ordem com as mesmas etapas.A migração automática e a criação de DB é desativada por uma estratégia de inicialização personalizada que só verifica se o dB existe e é válido.

Eu escrevi mais sobre os detalhes em impedir que as migrações da EF criem ou alterem o banco de dados .Eu também parecia um pouco em conflitos de mesclagem

Answer 2

.

1. Você pode executar o SQL nas aulas chamando o método SQL ou gerar SQL de uma migração usando o parâmetro -Script com o comando de atualização-banco de dados.

2. não.Eles estavam olhando para adicionar suporte para webdeploy, mas aparentemente decidido contra isso antes da RTM.Eles, no entanto, liberar um aplicativo de linha de comando (e o Script PowerShell, obviamente) que você poderia ligar de qualquer só.

   O que eu faço em meus projetos é criar um módulo de inicialização em meus aplicativos e executar qualquer migração que não tenha sido implantada automaticamente - acionando a migração da EF na inicialização do aplicativo por código .Não é perfeito, os desenvolvedores devem executar o aplicativo depois de obter mais recente antes de alterar o banco de dados, mas funciona para obter mais recente e implantação.