Implantando bancos de dados SQL Server do teste ao ativo

Question

Gostaria de saber como vocês gerenciam a implantação de um banco de dados entre 2 SQL Servers, especificamente o SQL Server 2005.Agora, há um desenvolvimento e um desenvolvimento vivo.Como isso deve fazer parte de um buildscript (lote padrão do Windows, mesmo com a complexidade atual desses scripts, posso mudar para o PowerShell ou mais tarde), o Enterprise Manager/Management Studio Express não conta.

Você poderia simplesmente copiar o arquivo .mdf e anexá-lo?Sempre tomo um pouco de cuidado ao trabalhar com dados binários, pois isso parece ser um problema de compatibilidade (mesmo que o desenvolvimento e o live devam executar a mesma versão do servidor o tempo todo).

Ou - dada a falta de "EXPLAIN CREATE TABLE" no T-SQL - você faz algo que exporta um banco de dados existente para scripts SQL que podem ser executados no servidor de destino?Se sim, existe uma ferramenta que pode despejar automaticamente um determinado banco de dados em consultas SQL e que é executada na linha de comando?(Novamente, Enterprise Manager/Management Studio Express não contam).

E por último - dado o fato de que o banco de dados ativo já contém dados, a implantação pode não envolver a criação de todas as tabelas, mas sim a verificação da diferença na estrutura e ALTER TABLE das tabelas ativas, o que também pode precisar de verificação/conversão de dados quando os campos existentes mudam.

Agora, ouço muitas coisas boas sobre o Portão Vermelho produtos, mas para projetos de hobby, o preço é um pouco alto.

Então, o que você está usando para implantar automaticamente bancos de dados SQL Server do teste ao ativo?

Answer 1

Comecei a codificar manualmente todas as minhas instruções DDL (criar/alterar/excluir), adicionando-as ao meu .sln como arquivos de texto e usando controle de versão normal (usando subversão, mas qualquer controle de revisão deve funcionar).Dessa forma, não apenas obtenho o benefício do controle de versão, mas a atualização ao vivo do dev/stage é o mesmo processo para código e banco de dados - tags, ramificações e assim por diante funcionam da mesma forma.

Caso contrário, concordo que o redgate é caro se você não tiver uma empresa que o compre para você.Se você conseguir que uma empresa compre para você, realmente vale a pena!

Answer 2

Para meus projetos eu alterno entre SQL Compare do REd Gate e o Database Publishing Wizard da Microsoft que você pode baixar gratuitamenteaqui.

O Assistente não é tão inteligente quanto o SQL Compare ou o SQL Data Compare, mas funciona.Um problema é que os scripts que ele gera podem precisar de alguma reorganização e/ou edição para fluir de uma só vez.

Por outro lado, ele pode mover seu esquema e dados, o que não é ruim para uma ferramenta gratuita.

Answer 3

Não se esqueça da solução da Microsoft para o problema: Edição de banco de dados do Visual Studio 2008.Inclui ferramentas para implantar alterações em bancos de dados, produzindo uma comparação entre bancos de dados para alterações de esquema e/ou dados, testes de unidade, geração de dados de teste.

É muito caro, mas usei a edição de teste por um tempo e achei brilhante.Isso torna o banco de dados tão fácil de trabalhar quanto qualquer outro trecho de código.

Answer 4

Como Rob Allen, eu uso SQL Compare/Data Compare da Redgate.Também uso o assistente de publicação de banco de dados da Microsoft.Também tenho um aplicativo de console que escrevi em C# que pega um script SQL e o executa em um servidor.Dessa forma, você pode executar scripts grandes com comandos 'GO' a partir de uma linha de comando ou em um script em lote.

Eu uso as bibliotecas Microsoft.SqlServer.BatchParser.dll e Microsoft.SqlServer.ConnectionInfo.dll no aplicativo de console.

Answer 5

Eu trabalho da mesma maneira que Karl, mantendo todos os meus scripts SQL para criar e alterar tabelas em um arquivo de texto que mantenho sob controle de origem.Na verdade, para evitar o problema de ter que um script examinar o banco de dados ativo para determinar quais ALTERs executar, geralmente trabalho assim:

• Na primeira versão, coloco tudo durante o teste em um script SQL e trato todas as tabelas como CREATE.Isso significa que acabo descartando e lendo muitas tabelas durante os testes, mas isso não é grande coisa no início do projeto (já que geralmente estou hackeando os dados que estou usando nesse ponto).
• Em todas as versões subsequentes, faço duas coisas:Eu crio um novo arquivo de texto para armazenar os scripts SQL de atualização, que contém apenas os ALTERs para essa versão.E eu faço as alterações no original, crio um novo script de banco de dados também.Dessa forma, uma atualização apenas executa o script de atualização, mas se precisarmos recriar o banco de dados, não precisaremos executar 100 scripts para chegar lá.
• Dependendo de como estou implantando as alterações do banco de dados, normalmente também colocarei uma tabela de versão no banco de dados que contém a versão do banco de dados.Então, em vez de tomar qualquer decisão humana sobre quais scripts executar, qualquer código que eu esteja executando os scripts de criação/atualização usa a versão para determinar o que executar.

A única coisa que isso não ajudará é se parte do que você está movendo do teste para a produção forem dados, mas se você quiser gerenciar a estrutura e não pagar por um pacote de gerenciamento de banco de dados bom, mas caro, não é realmente muito difícil.Também descobri que é uma boa maneira de manter o controle mental do seu banco de dados.

Answer 6

Se você tem uma empresa que está comprando, o Toad da Quest Software possui esse tipo de funcionalidade de gerenciamento integrada.É basicamente uma operação de dois cliques para comparar dois esquemas e gerar um script de sincronização de um para o outro.

Eles têm edições para a maioria dos bancos de dados populares, incluindo, é claro, o Sql Server.

Answer 7

Concordo que criar um script de tudo é a melhor maneira de fazer e é o que defendo no trabalho.Você deve criar scripts de tudo, desde a criação de banco de dados e objetos até o preenchimento de suas tabelas de pesquisa.

Qualquer coisa que você fizer apenas na interface do usuário não será traduzida (especialmente para alterações ...nem tanto para primeiras implantações) e acabará exigindo ferramentas como as que o Redgate oferece.

Answer 8

Usando SMO/DMO, não é muito difícil gerar um script do seu esquema.Os dados são um pouco mais divertidos, mas ainda assim factíveis.

Em geral, eu adoto a abordagem "Script It", mas você pode querer considerar algo nesse sentido:

• Distinguir entre Desenvolvimento e Preparação, de modo que você possa desenvolver com um subconjunto de dados...isso eu criaria uma ferramenta para simplesmente extrair alguns dados de produção ou gerar dados falsos no que diz respeito à segurança.
• Para o desenvolvimento da equipe, cada alteração no banco de dados deverá ser coordenada entre os membros da equipe.As alterações de esquema e de dados podem ser misturadas, mas um único script deve ativar um determinado recurso.Quando todos os seus recursos estiverem prontos, você os agrupa em um único arquivo SQL e executa-o em uma restauração da produção.
• Depois que sua preparação tiver sido aprovada, você executará o arquivo SQL único novamente na máquina de produção.

Eu usei as ferramentas Red Gate e elas são ótimo ferramentas, mas se você não puder pagar, construir as ferramentas e trabalhar dessa maneira não está muito longe do ideal.

Answer 9

Estou usando o mecanismo de migração do Subsonic, então só tenho uma dll com classes em ordem sequencial que possuem 2 métodos, para cima e para baixo.Há um gancho de script de integração/construção contínua no nant, para que eu possa automatizar a atualização do meu banco de dados.

Não é a melhor coisa do mundo, mas é melhor do que escrever DDL.

Answer 10

RedGate SqlCompare é um caminho a percorrer na minha opinião.Fazemos implantação de banco de dados regularmente e desde que comecei a usar essa ferramenta nunca olhei para trás.Interface muito intuitiva e economiza muito tempo no final.

A versão Pro também cuidará dos scripts para integração do controle de origem.

Answer 11

Também mantenho scripts para todos os meus objetos e dados.Para implantação, escrevi este utilitário gratuito - http://www.sqldart.com.Ele permitirá que você reordene seus arquivos de script e execute tudo em uma transação.

Answer 12

Concordo em manter tudo sob controle de origem e criar scripts manuais de todas as alterações.As alterações no esquema de uma única versão vão para um arquivo de script criado especificamente para essa versão.Todos os procs, visualizações, etc. armazenados devem ir para arquivos individuais e tratados como .cs ou .aspx no que diz respeito ao controle de origem.Eu uso um script PowerShell para gerar um grande arquivo .sql para atualizar o material de programabilidade.

Não gosto de automatizar a aplicação de alterações de esquema, como novas tabelas, novas colunas, etc.Ao fazer um lançamento de produção, gosto de executar o script de alteração comando por comando para garantir que cada um funcione conforme o esperado.Não há nada pior do que executar um script de grande mudança na produção e receber erros porque você esqueceu algum pequeno detalhe que não apareceu no desenvolvimento.

Também aprendi que os índices precisam ser tratados como arquivos de código e colocados no controle de origem.

E você definitivamente deve ter mais de 2 bancos de dados - dev e live.Você deve ter um banco de dados de desenvolvimento que todos usem para tarefas diárias de desenvolvimento.Em seguida, um banco de dados temporário que imita a produção e é usado para fazer seus testes de integração.Então, talvez uma cópia recente completa da produção (restaurada a partir de um backup completo), se isso for viável, para que sua última rodada de testes de instalação vá contra algo que seja o mais próximo possível da realidade.

Answer 13

Eu faço toda a criação do meu banco de dados como DDL e, em seguida, envolvo esse DDL em uma classe de manutenção de esquema.Posso fazer várias coisas para criar o DDL em primeiro lugar, mas fundamentalmente faço toda a manutenção do esquema no código.Isso também significa que, se for necessário fazer coisas não DDL que não mapeiam bem para SQL, você poderá escrever lógica processual e executá-la entre pedaços de DDL/DML.

Meu banco de dados tem uma tabela que define a versão atual para que seja possível codificar um conjunto de testes relativamente simples:

1. O banco de dados existe?Se não, crie-o.
2. O banco de dados é a versão atual?Caso contrário, execute os métodos, em sequência, que atualizam o esquema (você pode solicitar ao usuário que confirme e - idealmente - faça backups neste momento).

Para um aplicativo de usuário único, apenas executo isso, para um aplicativo da web, atualmente bloqueamos o usuário se as versões não corresponderem e tivermos um aplicativo de manutenção de esquema independente que executamos.Para multiusuário, dependerá do ambiente específico.

A vantagem?Bem, tenho um alto nível de confiança de que o esquema dos aplicativos que usam essa metodologia é consistente em todas as instâncias desses aplicativos.Não é perfeito, há problemas, mas funciona...

Existem alguns problemas ao desenvolver em um ambiente de equipe, mas isso é mais ou menos um dado adquirido de qualquer maneira!

Murph

Answer 14

Atualmente estou trabalhando a mesma coisa para você.Não apenas implantando bancos de dados SQL Server do teste ao ativo, mas também inclui todo o processo de Local -> Integração -> Teste -> Produção.Então, o que pode me tornar fácil todos os dias é que eu faço Tarefa NAnt com Red-Gate SQL Compare.Não trabalho para RedGate, mas devo dizer que é uma boa escolha.