A implantação de bancos de dados SQL Server a partir de Teste para viver

votos
24

Pergunto-me como vocês gerenciar a implantação de um banco de dados entre 2 servidores SQL, especificamente SQL Server 2005. Agora, há um desenvolvimento e um vivo. Como isso deve ser parte de um buildscript (lote padrão do Windows, até mesmo fazer com a complexidade atual desses roteiros, eu poderia mudar para o PowerShell ou mais tarde), Enterprise Manager / Management Studio Express não contam.

Será que você acabou de copiar o arquivo .mdf e anexá-lo? Estou sempre um pouco cuidadoso quando se trabalha com dados binários, como este parece ser um problema de compatibilidade (embora o desenvolvimento e viver deve executar a mesma versão do servidor em todos os tempos).

Ou - dada a falta de EXPLICAR CREATE TABLE em T-SQL - você fazer algo que exporta um banco de dados em SQL-scripts que podem ser executados no servidor de destino? Se sim, existe uma ferramenta que pode despejar automaticamente um banco de dados para consultas SQL e que sai da linha de comando? (Novamente, Enterprise Manager / Gestão Studio Express não contam).

E, por último - dado o fato de que o banco de dados ao vivo já contém dados, a implantação não pode envolver a criação de todas as tabelas, mas sim verificar a diferença de estrutura e ALTER TABLE os vivos ao invés, que também podem precisar de dados de verificação / conversão quando os campos existentes mudar.

Agora, eu ouvi um monte de coisas grandes sobre os Red Gate produtos, mas para projetos de hobby, o preço é um pouco íngreme.

Então, o que você está usando para implantar automaticamente bancos de dados SQL Server a partir de Teste para se viver?

Publicado 03/08/2008 em 00:30
fonte usuário
Em outras línguas...                            


14 respostas

votos
19

Eu tomei a mão-de codificação toda a minha DDL (cria / alterar / excluir) declarações, adicionando-os à minha .sln como arquivos de texto, e usando o controle de versão normal (usando a subversão, mas qualquer controle de revisão deve funcionar). Desta forma, eu não só obter o benefício de controle de versão, mas a atualização ao vivo de dev / palco é o mesmo processo para o código e banco de dados - tags, ramos e assim por diante o trabalho do mesmo jeito.

Caso contrário, eu concordo redgate é caro se você não tem uma empresa de comprá-lo para você. Se você pode obter uma empresa para comprá-lo para você, porém, é realmente vale a pena!

Respondeu 03/08/2008 em 00:51
fonte usuário

votos
14

Para os meus projetos que eu alternar entre SQL Compare de Red Gate eo Assistente de publicação da Microsoft banco de dados que você pode baixar gratuitamente aqui .

O assistente não é tão liso como SQL Compare ou de dados SQL Compare, mas ele faz o truque. Um problema é que os scripts que ele gera pode precisar de alguma reorganização e / ou edição a fluir em um tiro.

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

Respondeu 03/08/2008 em 00:40
fonte usuário

votos
7

Não se esqueça a solução da Microsoft para o problema: Visual Studio 2008 Database Edition . Inclui ferramentas para a implantação de alterações das bases de dados, produzindo uma comparação entre os bancos de dados de esquema e / ou alterações de dados, testes de unidade, geração de dados de teste.

É muito caro, mas eu usei a edição de avaliação por um tempo e pensei que era brilhante. Isso torna o banco de dados tão fácil de trabalhar como qualquer outro pedaço de código.

Respondeu 18/08/2008 em 11:47
fonte usuário

votos
6

Como Rob Allen, eu uso SQL Compare / Dados Comparar por Redgate. Eu também uso o assistente de publicação de banco de dados pela Microsoft. Eu também tenho um aplicativo de console que eu escrevi em C # que leva um script sql e executa-lo em um servidor. Desta forma, você pode executar grandes scripts com comandos 'go' em que de uma linha de comando ou em um script em lotes.

Eu uso bibliotecas Microsoft.SqlServer.BatchParser.dll e Microsoft.SqlServer.ConnectionInfo.dll na aplicação de consola.

Respondeu 04/08/2008 em 19:00
fonte usuário

votos
4

Eu trabalho da mesma forma Karl faz, mantendo todos os meus scripts SQL para criação e alteração de tabelas em um arquivo de texto que guardo no controle de origem. Na verdade, para evitar o problema de ter que ter um script examinar o banco de dados ao vivo para determinar o que altera a correr, eu costumo trabalhar assim:

  • Na primeira versão, eu coloco tudo durante os testes em um script SQL, e tratar todas as tabelas como CRIAR. Isso significa que eu acabar caindo e readding mesas muito durante os testes, mas isso não é um grande negócio cedo para o projeto (já que estou sempre cortando os dados que eu estou usando nesse ponto de qualquer maneira).
  • Em todas as versões subseqüentes, eu faço duas coisas: eu fazer um novo arquivo de texto para manter os scripts SQL de atualização, que contêm apenas os altera para essa versão. E eu fazer as mudanças ao original, criar um script de banco de dados frescos, bem. Desta forma, um upgrade apenas executa o script de atualização, mas se temos que recriar a DB não precisamos para executar 100 scripts para chegar lá.
  • Dependendo de como eu estou implantando as mudanças DB, eu também costumo colocar uma tabela de versão no banco de dados que contém a versão do DB. Então, ao invés de fazer quaisquer decisões humanas sobre as quais a execução de scripts, qualquer código que eu tenho que executam as criam / upgrade de scripts usa a versão para determinar o que executar.

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

Respondeu 03/08/2008 em 01:37
fonte usuário

votos
3

Usando SMO / DMO, não é muito difícil de gerar um script de seu esquema. Dados é um pouco mais divertido, mas ainda factível.

Em geral, eu tomo abordagem "Script It", mas você pode querer considerar algo ao longo destas linhas:

  • Distinguir entre Desenvolvimento e Staging, de modo que você pode desenvolver com um subconjunto de dados ... isso eu iria criar uma ferramenta para puxar simplesmente para baixo de alguns dados de produção, ou gerar dados falsos onde a segurança está em causa.
  • Para o desenvolvimento da equipe, cada alteração para o banco de dados terá de ser coordenada entre os membros de sua equipe. Esquema e dados mudanças podem ser misturados, mas um único script deve permitir que um determinado recurso. Uma vez que todos os seus recursos estão prontos, você unir estes acima em um único arquivo SQL e executar isso contra uma restauração da produção.
  • Uma vez que seu preparo cancelou aceitação, você executar o arquivo SQL solteira novamente na máquina de produção.

Eu tenho usado as ferramentas Red Gate e eles são grandes ferramentas, mas se você não puder pagar, construir as ferramentas e trabalhando desta forma não é muito longe do ideal.

Respondeu 04/08/2008 em 18:38
fonte usuário

votos
3

Se você tem uma empresa de comprá-lo, Sapo da Quest Software tem esse tipo de funcionalidade de gerenciamento integrado. É basicamente uma operação de dois clique para comparar dois esquemas e gerar um script de sincronização de um para o outro.

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

Respondeu 03/08/2008 em 01:22
fonte usuário

votos
2

Eu também manter scripts para todos os meus objetos e dados. Para a implantação de eu escrevi este utilitário gratuito - http://www.sqldart.com . Ele vai deixar você reorganizar seus arquivos de script e será executado todo o lote dentro de uma transação.

Respondeu 08/06/2010 em 22:33
fonte usuário

votos
2

RedGate SqlCompare é um caminho a percorrer na minha opinião. Fazemos implantação DB em uma base regular e desde que eu comecei a usar essa ferramenta eu nunca olhei para trás. Interface muito intuitiva e economiza muito tempo no final.

A versão Pro vai cuidar de scripting para a integração de controle de origem também.

Respondeu 28/08/2008 em 01:22
fonte usuário

votos
2

Eu estou usando o mecanismo de migrações de Subsonic então eu só tenho uma dll com aulas de fim squential que têm 2 métodos, para cima e para baixo. Há uma integração / build gancho roteiro contínua em nant, para que eu possa automatizar a atualização do meu banco de dados.

Não é o melhor thign no mundo, mas ele bate escrever DDL.

Respondeu 26/08/2008 em 18:39
fonte usuário

votos
2

Concordo com manter tudo no controle de origem e script manualmente todas as alterações. Alterações no esquema para uma única liberação entrar em um arquivo de script criado especificamente para esse lançamento. Todos os procedimentos armazenados, vistas, etc devem entrar em arquivos individuais e tratados como cs ou .aspx, tanto quanto o controle de origem vai. Eu uso um script PowerShell para gerar um arquivo .sql grande para atualizar o material de programação.

Eu não gosto de automatizar a aplicação de alterações de esquema, como novas tabelas, novas colunas, etc Ao fazer uma versão de produção, gosto de passar o comando script de alteração de comando para certificar-se de cada um funciona como esperado. Não há nada pior do que correr um script grande mudança na produção e recebendo erros porque você se esqueceu algum pequeno detalhe que não se apresentar no desenvolvimento.

Eu também aprendi que os índices precisam ser tratados como arquivos de código e colocar em controle de origem.

E você definitivamente deve ter mais de 2 bases de dados - dev e viver. Você deve ter um banco de dados dev que todo mundo usa para tarefas diárias dev. Em seguida, um banco de dados de teste que imita produção e é usado para fazer o seu teste de integração. Então, talvez, uma cópia recente completo de produção (restaurado a partir de um backup completo), se isso for possível, para que a sua última rodada de testes de instalação vai contra algo que é tão perto da coisa real quanto possível.

Respondeu 13/08/2008 em 16:41
fonte usuário

votos
2

Concordo que scripting tudo é o melhor caminho a percorrer e é o que eu defendo no trabalho. Você deve roteiro tudo, desde DB e criação do objeto para preencher suas tabelas de pesquisa.

Qualquer coisa que você faz na interface do usuário somente não irá traduzir (especialmente para mudanças ... não tanto para as primeiras implementações) e vai acabar exigindo uma ferramenta como o que Redgate oferece.

Respondeu 03/08/2008 em 02:38
fonte usuário

votos
1

Atualmente estou trabalhando a mesma coisa para você. Não só a implantação de bancos de dados SQL Server a partir de teste para viver, mas também incluem todo o processo a partir de local -> Integração -> Test -> Produção. Então, o que pode me fazer facilmente todos os dias é que eu faço tarefa NAnt com Red-Gate SQL Compare . Eu não estou trabalhando para RedGate mas eu tenho que dizer que é uma boa escolha.

Respondeu 27/11/2008 em 04:15
fonte usuário

votos
1

Eu faço toda a minha criação de banco de dados como DDL e em seguida, enrole que DDL em uma classe de esquema maintainence. I podem fazer várias coisas para criar o DDL em primeiro lugar, mas, fundamentalmente, eu faço todo o maint esquema no código. Isto também significa que, se um precisa de fazer as coisas não DDL que não mapeiam bem para SQL você pode escrever a lógica processual e executá-lo entre pedaços de DDL / DML.

Meus dbs, em seguida, ter uma tabela que define a versão atual para que se possa codificar um conjunto relativamente simples de testes:

  1. O DB existe? Se não criá-lo.
  2. o DB é a versão atual? Se não, então executar os métodos, em sequência, que trazem o esquema atualizado (você pode querer para solicitar ao usuário para confirmar e - de preferência - fazer backups neste momento).

Para um único aplicativo de usuário Eu só executar este no lugar, para uma aplicação web que atualmente para bloquear o usuário se as versões não coincidirem e ter um stand alone app esquema maint corremos. Para multi-usuário, ele vai depender do ambiente particular.

A vantagem? Bem, eu tenho um nível muito alto de confiança de que o esquema para as aplicações que utilizam essa metodologia é consistente em todas as instâncias desses aplicativos. A sua não é perfeito, existem problemas, mas funciona ...

Há algumas questões ao desenvolver em um ambiente de equipe, mas isso é mais ou menos um dado de qualquer maneira!

Murph

Respondeu 26/08/2008 em 16:38
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more