Os arquivos de banco de dados (scripts etc.) devem estar no controle de origem? Em caso afirmativo, qual é o melhor método para mantê-lo e atualizá-lo lá?

Existe até a necessidade de arquivos de banco de dados estarem no controle de origem, pois podemos colocá-lo em um servidor de desenvolvimento em que todos possam usá-lo e fazer alterações, se necessário. Mas não podemos recuperá-lo se alguém estragar tudo.

Qual abordagem é melhor usada para bancos de dados no controle de origem?

Sim. Você poderá reconstruir qualquer parte do seu sistema do controle de origem, incluindo o banco de dados (e eu também argumentaria que certos dados estáticos).

Supondo que você não queira ter uma ferramenta, sugiro que você inclua o seguinte:

• Scripts de criação para as estruturas básicas da tabela, incluindo esquemas, usuários, tabelas, chaves, padrões e assim por diante.
• Scripts de atualização (alterando a estrutura da tabela ou migrando dados de um esquema anterior para o novo esquema)
• Scripts de criação para procedimentos armazenados, índices, visualizações, gatilhos (você não precisa se preocupar com a atualização desses, pois apenas sobrescreve o que estava lá com o script de criação correto)
• Scripts de criação de dados para colocar o sistema em funcionamento (um único usuário, qualquer dado estático da lista de opções, esse tipo de coisa)

Todos os scripts devem incluir as instruções drop apropriadas e ser gravados para que possam ser executados como qualquer usuário (incluindo os prefixos de esquema / proprietário associados, se relevante).

O processo de atualização / marcação / ramificação deve ser exatamente como o restante do código-fonte - há pouco sentido em fazê-lo se você não puder associar uma versão do banco de dados a uma versão do aplicativo.

Aliás, quando você diz que as pessoas podem simplesmente atualizar o servidor de teste, espero que você se refira ao servidor de desenvolvimento. Se os desenvolvedores estão atualizando o servidor de teste rapidamente, você está olhando para um mundo de dor quando se trata de descobrir o que você precisa liberar.

Sim.

qual é o melhor método para mantê-lo e atualizá-lo lá?

Hum. Escreva um script do construtor de esquema. Faça o check-in depois de fazer alterações. Confira antes de executá-lo.

É difícil determinar o que você está pedindo.

Escreva scripts formais de migração de esquema. Faça o check-in após o teste. Verifique-os antes de executá-los.

O que mais há?

O que acontece é que as mudanças no esquema se transformam em problemas genéricos, porque o esquema evolui organicamente através de uma série de mudanças não documentadas.

Essa evolução orgânica torna a migração do esquema mais difícil, porque não existe uma fonte "autorizada" para o que deveria estar lá. Existem duas versões de produção ligeiramente diferentes, uma versão intermediária, uma versão de controle de qualidade e oito versões de desenvolvimento. Tudo um pouco diferente.

Se houver uma fonte autorizada única, a migração do esquema será apenas o delta entre a última versão e esta versão.

sim

Scripts de banco de dados (ddl, dml) são código. Todo o código deve estar em um sistema de controle de versão.

Migrações

• Usar migrações de banco de dados

Permite usar os mesmos arquivos db em desenvolvimento, qa e versões.

• Liberar no banco de dados com um número de release

Armazene o número do release em algum lugar para auditoria, muitos o armazenam no próprio banco de dados. Cada versão será composta de migrações que levarão o banco de dados à versão correta.

Existem ferramentas como o liquibase que visam fornecer controle de origem para bancos de dados. É complicado manter scripts de alteração / atualização em sua ferramenta de controle de origem regular, como muitas empresas fazem e você nem sempre pode reimplementar o banco de dados do zero.

Também tentamos automatizar isso com ferramentas de comparação de banco de dados (comparar mestre x banco de dados do cliente) e isso ajudou, mas você não pode confiar 100% nessas ferramentas, também definitivamente precisa de um processo de revisão.

sim

E além disso, você vai querer galhos .

Eu uso o Git para ramos:

• para desenvolvimento por recurso (como fazemos para o desenvolvimento regular do restante do aplicativo)

• e uma também para o servidor de produção , porque os clientes que usam o aplicativo também criam conteúdo.

Dessa forma, você obtém os benefícios do controle de origem e ramificação dos códigos-fonte e do banco de dados (e quaisquer outros arquivos que você possui).

Ainda não encontrei um sistema multifuncional [para o PostgreSQL], então tive que escrever funções / scripts para reindexar adequadamente ao mesclar ramificações (por exemplo, qualquer índice da ramificação de produção não deve ser modificado porque os clientes confiam neles. índices + chaves estrangeiras do ramo de desenvolvimento que se cruzam com o conteúdo da produção devem ser reindexados: não funcionaria para todos os aplicativos, mas abrange todos os casos de nosso aplicativo, por isso é bom o suficiente).

Mas a ideia geral é que o conteúdo do banco de dados seja uma parte essencial do aplicativo e todos os recursos devem estar no controle de origem ; portanto, você também deve usar o controle de fonte no banco de dados.

Para Java, nossa equipe usa o Flyway , que achamos realmente fácil de usar e poderoso.

Se você estiver trabalhando em Ruby, o Rails possui Migrações, que também são uma maneira poderosa de lidar com esse problema.

O Liquibase já foi mencionado - é uma boa solução, mas achei mais complicado do que alternativas como o Flyway.

Além disso, o software RedGate oferece um produto chamado SQL Source Control, projetado para o SQL Server. Eu não o usei, mas um dos meus colegas de trabalho diz que é ótimo.

Aqui está o problema que eu já vi muitas vezes quando não há controle de versão ou gerenciamento de alterações nos bancos de dados de desenvolvimento. O programador A faz uma alteração em uma tabela, exibição ou proc. O programador B faz uma alteração na mesma coisa e substitui o que o programador A fez. Ou, o DBA restaura um banco de dados de produção para desenvolver e substituir alterações. Eu já vi esse tipo de coisa causar dor considerável tantas vezes que não é engraçado. E isso é apenas em sistemas de desenvolvimento. As coisas podem ficar muito complicadas quando o teste / teste e até os servidores de produção são apanhados nisso.

O controle de versão do banco de dados não precisa ser o mesmo que o controle de versão de código regular para ser eficaz. No entanto, algum tipo de controle de alterações e backups do histórico evitarão muitos problemas.

Pense nisso como "Controle de Versão" em vez de "Controle de Origem". Isso implica que você pode ver toda a história desse script em particular. Se você pode ou não reconstruir o banco de dados para o formato atual, será mais uma questão de suas práticas em relação a esses scripts e quaisquer estruturas usadas para criá-los.

Para nossos projetos PHP / MySQL, usamos uma (uma vez) pequena ferramenta chamada Ladder . Ele foi projetado para facilitar o crescimento orgânico de um banco de dados ao longo do tempo. Todas as migrações para um projeto são armazenadas no controle de revisão / fonte / versão e são rastreadas junto com o código.

Ele suporta a adição / alteração / remoção de colunas, execução de consultas, adição / remoção de índices, restrições, etc., etc. Ele acompanhará o estado em que o banco de dados está e aplicará as migrações ausentes. Ele também permite que você "volte no tempo" especificando uma migração em que você precisa estar. ( php ladder.php migrate 15)

Ah, e a mais recente adição é diferente do banco de dados. Execute o diff-savecomando, adicione e remova algumas colunas do banco de dados e execute seu diffcomando. Você verá o código de migração gerado automaticamente com base no estado do banco de dados.

O DataGrove resolve alguns dos problemas mencionados aqui (por jfrankcarr , por exemplo).

Ele rastreia todas as alterações em um banco de dados e permite salvar uma versão do estado inteiro do banco de dados em um repositório. Em seguida, ele permite gerar várias cópias virtuais do mesmo banco de dados, para que cada desenvolvedor ou DBA possa ter sua própria cópia separada (cada cópia virtual pode ser gerada a partir de uma versão diferente). Isso garantirá que ninguém substitua o código / alterações de outra pessoa. Cada uma das cópias virtuais também é rastreada nos mesmos repositórios, para que todos os estados do banco de dados possam ser facilmente compartilhados e recriados.

Também gostaria de trazer uma ferramenta de monitoramento que também pode ser usada como ferramenta de versão de dados. A ferramenta da qual estou falando é o MONyog, na verdade é uma ferramenta de monitoramento do MySQL, mas com um pouco de truque, podemos usá-la facilmente como versão de dados.

Mas antes de prosseguir, citarei que não será aconselhável colocar todo o banco de dados para controle de versão. É realmente real rastrear as alterações de um conjunto de dados específico.

O MONyog possui um recurso chamado CSO (Custom SQL Objects), que pode monitorar a alteração em um conjunto específico de dados. A adição de um CSO é descrita aqui . Agora, na seção de histórico de monitores do MONyog, você pode obter as alterações ao longo de um período de tempo. Melhor, fornece um relatório visual na página html. O relatório será mais ou menos assim