mysql - preços - google cloud sql




Como você gerencia bancos de dados em desenvolvimento, teste e produção? (10)

Tive dificuldade em encontrar bons exemplos de como gerenciar esquemas e dados do banco de dados entre servidores de desenvolvimento, teste e produção.

Aqui está nossa configuração. Cada desenvolvedor tem uma máquina virtual executando nosso aplicativo e o banco de dados MySQL. É a sua caixa de areia pessoal para fazer o que quiserem. Atualmente, os desenvolvedores farão uma alteração no esquema SQL e farão um despejo do banco de dados em um arquivo de texto que serão enviados para o SVN.

Estamos querendo implantar um servidor de desenvolvimento de integração contínua que sempre executará o código confirmado mais recente. Se fizermos isso agora, ele recarregará o banco de dados do SVN para cada compilação.

Temos um servidor de teste (virtual) que executa "candidatos a lançamento". Implantar no servidor de teste é atualmente um processo muito manual e geralmente me envolve carregar o SQL mais recente do SVN e ajustá-lo. Além disso, os dados no servidor de teste são inconsistentes. Você acaba com os dados de teste que o último desenvolvedor a enviar no seu servidor sandbox.

Onde tudo se desmorona é a implantação para produção. Como não podemos sobrescrever os dados ao vivo com dados de teste, isso envolve a recriação manual de todas as alterações no esquema. Se houver um grande número de alterações de esquema ou scripts de conversão para manipular os dados, isso pode ficar realmente complicado.

Se o problema fosse apenas o esquema, seria um problema mais fácil, mas há dados "básicos" no banco de dados que também são atualizados durante o desenvolvimento, como metadados em tabelas de segurança e permissões.

Essa é a maior barreira que vejo ao avançar na integração contínua e na construção de uma etapa. Como você resolve isso?

Uma pergunta de acompanhamento: como você controla as versões do banco de dados para saber quais scripts devem ser executados para atualizar uma determinada instância do banco de dados? Uma tabela de versões como Lance menciona abaixo do procedimento padrão?

Obrigado pela referência a Tarantino. Eu não estou em um ambiente .NET, mas achei sua página wiki DataBaseChangeMangement muito útil. Especialmente esta apresentação em PowerPoint (.ppt)

Vou escrever um script Python que verifica os nomes dos scripts *.sql em um determinado diretório em relação a uma tabela no banco de dados e executa os que não estão lá em ordem, com base em um inteiro que forma a primeira parte do script. nome do arquivo. Se for uma solução bem simples, como eu suspeito que seja, postarei aqui.

Eu tenho um roteiro de trabalho para isso. Ele lida com a inicialização do banco de dados se ele não existir e executando os scripts de atualização conforme necessário. Há também opções para limpar um banco de dados existente e importar dados de teste de um arquivo. É cerca de 200 linhas, então eu não vou postar (embora eu possa colocá-lo no pastebin se houver interesse).


Escrevi uma ferramenta que (conectando-se ao Open DBDiff ) compara esquemas de bancos de dados e sugere scripts de migração para você. Se você fizer uma alteração que exclua ou modifique dados, isso gerará um erro, mas fornecerá uma sugestão para o script (por exemplo, quando uma coluna estiver ausente no novo esquema, ele verificará se a coluna foi renomeada e criará xx-generated script.sql.suggestion contendo uma declaração de renomeação).

http://code.google.com/p/migrationscriptgenerator/ SQL Server só tenho medo :( Também é muito alfa, mas é muito baixo atrito (especialmente se você combiná-lo com Tarantino ou http://code.google.com/p/simplescriptrunner/ )

A maneira que eu uso é ter um projeto de scripts SQL no seu .sln. Você também tem um banco de dados db_next localmente para o qual você faz as alterações (usando o Management Studio ou o NHibernate Schema Export ou o LinqToSql CreateDatabase ou algo assim). Então você executa o migrationscriptgenerator com os DBs _dev e _next, que cria. os scripts de atualização SQL para migração.


Estamos usando o mysql-diff linha de comando: ele gera uma diferença entre dois esquemas de banco de dados (do DB ou script ativo) como o script ALTER. O mysql-diff é executado no início do aplicativo e, se o esquema for alterado, ele será reportado ao desenvolvedor. Portanto, os desenvolvedores não precisam escrever ALTERs manualmente, as atualizações de esquema acontecem de forma semi-automática.


Existem algumas boas opções. Eu não usaria a estratégia "restaurar um backup".

  1. Script todas as alterações do esquema e ter seu servidor de CI executar esses scripts no banco de dados. Ter uma tabela de versões para acompanhar a versão atual do banco de dados e executar apenas os scripts se eles forem para uma versão mais recente.

  2. Use uma solução de migração. Essas soluções variam por idioma, mas para o .NET eu uso o Migrator.NET. Isso permite que você modifique seu banco de dados e suba e desça entre versões. Seu esquema é especificado no código C #.


Isso é algo que eu estou constantemente insatisfeito com a nossa solução para este problema que é. Durante vários anos mantivemos um script de alteração separado para cada lançamento. Este script conteria os deltas da última versão de produção. Com cada lançamento do aplicativo, o número da versão seria incrementado, dando algo como o seguinte:

  • dbChanges_1.sql
  • dbChanges_2.sql
  • ...
  • dbChanges_n.sql

Isso funcionou bem até que começamos a manter duas linhas de desenvolvimento: Trunk / Mainline para novos desenvolvimentos e uma ramificação de manutenção para correções de bugs, aprimoramentos de curto prazo, etc. Inevitavelmente, surgiu a necessidade de fazer alterações no esquema na ramificação. Neste ponto, nós já tínhamos dbChanges_n + 1.sql no Trunk, então acabamos indo com um esquema como o seguinte:

  • dbChanges_n.1.sql
  • dbChanges_n.2.sql
  • ...
  • dbChanges_n.3.sql

Novamente, isso funcionou bem, até que um dia nós olhamos para cima e vimos 42 scripts delta na linha principal e 10 na ramificação. ARGH!

Atualmente, simplesmente mantemos um script delta e deixamos a versão do SVN - ou seja, sobrescrevemos o script a cada lançamento. E nós evitamos fazer mudanças de esquema nos ramos.

Então, eu não estou satisfeito com isso também. Eu realmente gosto do conceito de migrações do Rails. Eu me tornei bastante fascinado com o LiquiBase . Ele suporta o conceito de refatoração de banco de dados incremental. Vale a pena dar uma olhada e eu vou estar olhando em detalhes em breve. Alguém tem experiência com isso? Eu ficaria muito curioso para ouvir sobre seus resultados.


O livro Refactoring Databases: Evolutionary Database Design pode fornecer algumas ideias sobre como gerenciar o banco de dados. Uma versão curta também pode ser lida em http://martinfowler.com/articles/evodb.html

Em um projeto PHP + MySQL, tive o número de revisão do banco de dados armazenado no banco de dados, e quando o programa se conecta ao banco de dados, ele primeiro verifica a revisão. Se o programa exigir uma revisão diferente, ele abrirá uma página para atualizar o banco de dados. Cada atualização é especificada no código PHP, que alterará o esquema do banco de dados e migrará todos os dados existentes.


Para o banco de dados oracle, usamos as ferramentas oracle-ddl2svn .

Esta ferramenta automatizou o próximo processo

  1. para cada esquema de db obtenha ddls de esquema
  2. colocá-lo sob versão contol

alterações entre instâncias resolvidas manualmente


Seus desenvolvedores precisam escrever scripts de mudança (alteração de esquema e dados) para cada bug / recurso em que trabalham, e não simplesmente despejar o banco de dados inteiro no controle de origem. Esses scripts atualizarão o banco de dados de produção atual para a nova versão em desenvolvimento.

Seu processo de compilação pode restaurar uma cópia do banco de dados de produção em um ambiente apropriado e executar todos os scripts a partir do controle de origem, o que atualizará o banco de dados para a versão atual. Fazemos isso diariamente para garantir que todos os scripts sejam executados corretamente.


Veja como o Ruby on Rails faz isso.

Primeiro, existem os chamados arquivos de migração, que basicamente transformam o esquema do banco de dados e os dados da versão N para a versão N + 1 (ou no caso de downgrade da versão N + 1 para N). Banco de dados tem tabela que informa a versão atual.

Os bancos de dados de teste são sempre limpos antes dos testes de unidade e preenchidos com dados fixos dos arquivos.


Você também pode olhar para usar uma ferramenta como o SQL Compare para fazer o script da diferença entre as várias versões de um banco de dados, permitindo que você migre rapidamente entre as versões


  • Nomeie seus bancos de dados da seguinte forma - db_dev, db_test, db_qa, db_prod (Obviamente, você nunca deve codificar nomes de db
  • Assim, você seria capaz de implantar até mesmo os diferentes tipos de banco de dados no mesmo servidor físico (eu não recomendo isso, mas você pode ter que ... se os recursos são apertados)
  • Certifique-se de que você seria capaz de mover dados entre esses automaticamente
  • Separe os scripts de criação de banco de dados da população = Deve ser sempre possível recriar o banco de dados a partir do zero e preenchê-lo (a partir da versão antiga do banco de dados ou da origem de dados externa
  • não use strings de conexão de código no código (mesmo não nos arquivos de configuração) - use nos modelos de string de conexão dos arquivos de configuração, que você preenche dinamicamente, cada reconfiguração do application_layer que precisa ser recompilada é BAD
  • use versionamento de banco de dados e controle de versões de objetos db - se você puder pagar, use produtos prontos, se não desenvolver algo por conta própria
  • acompanhar cada mudança de DDL e salvá-lo em alguma tabela de histórico ( exemplo aqui )
  • Backups diários! Teste o quão rápido você seria capaz de restaurar algo perdido de um backup (use scripts de restauração automática)
  • mesmo o seu banco de dados DEV e o PROD têm exatamente o mesmo script de criação, você terá problemas com os dados, então permita que os desenvolvedores criem a cópia exata do prod e brinquem com ele (sei que receberei minuses para este, mas mude no a mentalidade e o processo de negócios custarão muito menos quando a merda atingir o leque - então force os codificadores a subscrever legalmente o que quer que seja, mas garanta isso




svn