Gestão de Banco de Dados SQL Server com Integração Contínua

Question

Digamos que temos um servidor de integração contínua. Quando eu check-in, o pós-hook puxa o código mais recente, executa os testes, pacotes de tudo. Qual é a melhor maneira de também automatizar as alterações de banco de dados?

Idealmente, eu construir um instalador que poderia quer construir um banco de dados a partir do zero ou atualizar um já existente usando algum método de sincronização automática.

Answer 1

Se você tem a oportunidade de definir e controlar a gestão de banco de dados e processo de criação db todo, ter um olhar sério em DB Santo - é mais do que apenas uma ferramenta - é um processo.

Se você gosta dele e pode implementá-lo, você vai ter grandes retornos sobre ele - mas é um pouco de um "tudo-ou-nada" tipo de abordagem. Recomendado.

Answer 2

Eu recentemente esbarrou em um artigo , que podem ser de uso.

O autor explicou algumas das melhores práticas de integração contínua, incluindo análise, processamento e automação.

Aqui estão algumas das principais lições:

• No código muitas lojas é unidade testada no ponto de cometer. Para bases de dados, prefere-se a execução de todos os testes de unidade de uma só vez e em sequcia contra uma base de dados de controle de qualidade, contra o desenvolvimento, como parte do passo de teste
• A etapa de teste é uma parte crítica de todo o processo de IC / CD. scripts de teste, incluindo-se os testes de unidade, também deve ser versionadas no controle de origem, extraído no ponto da etapa de compilação e executado
• puxando dados do produção é atraente como um expediente rápido, mas nunca é uma boa idéia
• A melhor abordagem é usar uma ferramenta ou um script para rapidamente, repetidamente e de forma confiável criar dados de teste sintéticos para suas tabelas transacionais
• A execução de testes de unidade para produzir resultados de resumo manuais para consumo humano derrota o propósito de automação. Precisamos de máquinas resultados legíveis, que pode permitir que um processo automatizado para abortar, ramo e / ou continuar.
• A execução de um processo de IC, o que exige 100% de todos os testes para passar, é semelhante a não ter CI em tudo, se o pipeline de fluxo de trabalho está configurado atomicamente para a paragem em caso de falha, o que deveria. Enfiar a agulha, os testes devem ter construído em limiares, que irá gerar um erro baseado ou no% dos testes de falha ou em alguns casos, se determinados testes de alta prioridade falhar.
• Todos os processos devem, em última análise produzir um resultado booleano de aprovação ou reprovação, mas alguns processos não automatizados pode facilmente encontrar o seu caminho em seu pipeline de fluxo de trabalho CI (por exemplo, o teste de unidade). Software deve ser plug-n-play em qualquer gasoduto fluxo de trabalho, tendo entradas conhecidas e produzindo resultados esperados -. Como passagem, falham
• processo CI / CD deve ser abortada em caso de falha e um email de notificação deve ser enviada imediatamente vs continuar a ciclo do gasoduto.
• O processo de IC não deve ciclo novamente até que quaisquer erros na última compilação são fixos. Em caso de falha, toda a equipe deve obter a notificação de falha, incluindo tantos detalhes quanto ao que falhou possível.
• Se um oleoduto leva 1 hora, do início ao fim, para completar, incluindo todos os testes, então todos os intervalos de construção deve ser definido para não menos do que uma hora e todos os novos commits devem ser colocados em fila, e aplicado para a próxima construção.
• Não há senhas de texto simples deve existir em scripts de automação

Answer 3

gostaria de alertar contra o uso de um backup db como um artefato de desenvolvimento, a maioria das melhores práticas CI sugerem que você gerenciar o esquema, procedimentos, triggers, e vistas como artefatos de desenvolvimento de primeira classe. Os efeitos colaterais é que você pode dar um passo adiante e usá-los para construir uma nova base de dados sempre que quiser, idealmente você também tem alguns dados que podem ser empurrado para o banco de dados.

Aqui está uma versão notas penhasco para obter seus pés molhados, mas há muito lá neste espaço out: http://www.infoq.com/news/2008/02/versioning_databases_series

Eu gosto de algumas das ideias que Scott Ambler tem aqui também, o local é bom, mas o livro é surpreendentemente profunda para um conjunto tão difícil de problemas. http://www.agiledata.org/ http://www.amazon.com/exec/obidos/ASIN/0321293533/ambysoftinc

Answer 4

Red Gate é uma solução bastante robusto e funciona fora da caixa. Mas a melhor coisa é que você pode integrá-lo com o seu processo de integração contínua. Eu usá-lo com MSBuild e Hudson. rapidamente explicando como funciona: http://blog.vincentbrouillet.com/post / 2011/02/10 / Banco de Dados-schema-sincronização-with-RedGate

Se você precisa saber mais sobre isso, não hesite em perguntar

Answer 5

A abordagem Red Gate usando controle de origem SQL ea linha de comando SQL Compare Pro é detalhado com exemplos de código aqui: http://downloads.red-gate.com/HelpPDF/ContinuousIntegrationForDatabasesUsingRedGateSQLTools.pdf

Troy caça escreveu um artigo na conversa simples intitulado "Integração Contínua para o SQL Server bancos de dados": http://www.simple-talk.com/content/article.aspx ? article = 1247

Answer 6

Você olhou para FluentMigrator ? O padrão de download inclui scripts Nant que seria fácil de adicionar em um CI. Livre, de código aberto e fácil de usar. Trabalha para uma grande variedade de bancos de dados.

Answer 7

A última versão (5.0) do DB Santo não sofrem com o problema "não ASCII caráter" (isso significa apenas que o arquivo é UTF8 codificado) e ele deve ser capaz de fazer exatamente o que você precisa.

Além disso, as ferramentas podem realmente ser autônomo usado para executar as várias funções (scripting, construção, comparando, modernização e embalagem), se quiser, é só que usá-los todos juntos fornece um processo completo end-to-end tornando assim o maior valor global do que a soma dela é peças.

Em essência, para fazer alterações no esquema de atualizar scripts de criação de objeto individuais e por tabela inserir scripts (para dados de referência) que são mantidos sob controle de origem como se você estivesse desenvolvendo um “dia um” banco de dados de greenfield. As ferramentas DB fantasmas são usados ??para ativar a coisa toda construindo esses scripts em um novo banco de dados (usando a integração contínua se necessário) e, em seguida, comparar e atualizar um banco de dados de destino, que pode ser uma cópia do banco de dados de produção. Este processo produz um script delta que pode ser usado no banco de dados de produção real durante go-live.

Você pode até mesmo produzir um projeto de banco de dados Visual Studio e adicioná-lo em todas as soluções que têm actualmente.

Malc

Answer 8

Eu sei que este post é antigo, mas temos uma nova solução que leva a seguinte abordagem:

1. Os desenvolvedores de script mudanças SQL individuais e os entrego a fonte ao controle.
2. O nosso programa ( OneScript ) puxa os arquivos de script mudança de controle de origem, filtros e classifica-os e gera um único liberar arquivo de script.
3. Esse arquivo script de liberação é então aplicada a uma banco de dados para fazer um lançamento.

Nossa página de casa aqui explica este processo com mais detalhes e tem um link para um exemplo que faz estes passos automaticamente a partir de um gancho Subversion. Então, logo após um commit, o desenvolvedor recebe um e-mail dizendo que se o lançamento foi bem sucedida ou teve erros. O código PowerScript está incluído.

Disclaimer -Estou trabalhando na empresa que faz OneScript.