Como você gerenciar revisões de banco de dados em um tamanho médio de projeto com ramos?

Question

No trabalho temos 4 pessoas trabalhando juntas em alguns projetos diferentes. Para cada projeto cada um de nós tem um trabalho exemplar que local no e, em seguida, há um desenvolvimento, teste e implantação ao vivo, juntamente com quaisquer ramos que temos (usamos subversão). Nosso banco de dados é MySQL.

Então, minha pergunta é, o que é uma boa maneira de gerenciar quais revisões do banco de dados foram feitas para cada implantação (e para os desenvolvedores suas cópias locais). Agora cada mudança entra em um arquivo de texto que é timestamped em nome e colocar em uma pasta no âmbito do projecto. Isto não está funcionando muito bem para ser honesto .. Eu preciso de uma solução que irá ajudar a manter o controle do que foi aplicado onde.

Answer 1

Se o seu banco de dados mapeia muito bem para um conjunto de objetos de acesso a dados, considere usar 'migrações'. A idéia é armazenar seu modelo de dados como código do aplicativo com as etapas para mover para frente e para trás através de cada versão do banco de dados.

Eu acredito Rails fez isso primeiro .

Java tem pelo menos um projeto .

E aqui está um .NET migração biblioteca .

Para versões de mudança, você executar um script simples que percorre toda a cima ou para baixo versões para levá-lo para a versão que você deseja. A beleza da coisa é que você verifique suas migrações para o mesmo repositório de origem como o seu Código app -. É tudo em um só lugar

Talvez outros podem sugerir outras bibliotecas de migração.

Felicidades.

Edit: Veja também https://stackoverflow.com/questions/313/net-migrations-engine e .NET banco de dados ferramenta de migração roundup (de post acima).

Answer 2

http://odetocode.com/Blogs/scott /archive/2008/01/30/11702.aspx

O blog acima de nós trouxe ao nosso sistema de banco de dados de controle de versão atual. Simplificando, há mudanças DB são feitas sem um script de atualização e todos os scripts de atualização estão no nosso repositório de controle de origem.

Nós só gerir as alterações de esquema, mas você também pode ser capaz / dispostos a considerar manter lixeiras de seus dados disponíveis no controle de versão bem; criar tais arquivos é um exercício bastante trivial usando mysqldump.

Nossos difere da solução da solução apresentada no blog de uma maneira importante: não é automatizado. Temos de mão aplicar atualizações de banco de dados, etc. Embora este pode ser um pouco demorado, adiou alguns do esforço de um sistema totalmente automatizado teria exigido. Uma coisa que fizemos automatizar entanto, foi o acompanhamento de versões db no software:. Esta era bastante simples e garante que nosso software está ciente do banco de dados que está sendo executado contra e irá executar somente se ele conhece o esquema que está trabalhando com

A parte mais difícil da nossa solução foi como mesclar atualização de nossas filiais em nosso tronco. Passamos algum tempo para desenvolver um fluxo de trabalho para lidar com a possibilidade de dois desenvolvedores tentando mesclar ramos com atualizações DB ao mesmo tempo e como lidar com isso. Nós finalmente a acordo sobre o bloqueio de um arquivo no controle de versão (o arquivo em questão para nós é na verdade uma versão do software de mapeamento de tabela para db versão que auxilia na nossa estratégia de gestão manual), muito como se fosse seção crítica de um segmento, e o desenvolvedor que recebe o bloqueio vai sobre sua atualização do tronco. Quando concluído, o outro desenvolvedor seria capaz de bloquear e é sua responsabilidade para fazer as alterações necessárias para seus scripts para garantir que as colisões versão esperada e outros juju ruim são evitadas.

Answer 3

Nós manter todos os nossos scripts de banco de dados (dados e esquema / DDL) no controle de versão. Nós também manter um catálogo central das mudanças. Quando um desenvolvedor faz uma alteração em um arquivo schema / DDL ou adiciona um script que altera os dados de alguma forma, esses arquivos são adicionados ao catálogo, juntamente com o SVN cometer número.

Reunimos um pequeno utilitário em casa que lê o catálogo alterações e constrói um script de atualização grande com base no conteúdo do catálogo, agarrando o conteúdo de cada revisão no catálogo e aplicá-las. O conceito é bastante semelhante à ferramenta DBDeploy , que eu acredito veio originalmente de Thoughtworks , assim você pode ser capaz de utilizá-lo. Ele vai, pelo menos, dar-lhe um bom lugar para começar, a partir de que ponto você pode personalizar uma solução mais diretamente adequado às suas necessidades.

Boa sorte!