Sim. Você deve ser capaz de reconstruir qualquer parte do seu sistema a partir do controle de origem, incluindo o banco de dados (e eu também diria certos dados estáticos).

Supondo que você não quer ter uma ferramenta para fazer isso, sugiro que você queira incluir o seguinte:

• Scripts de criação para estruturas de tabelas básicas, incluindo esquemas, usuários, tabelas, chaves, padrões e assim por diante.
• Atualizar scripts (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 para estes, já que sobrescreveu o que estava lá com o script de criação correto)
• Scripts de criação de dados para obter o sistema em execução (um único usuário, qualquer dado da lista de opções estática, esse tipo de coisa)

Todos os scripts devem incluir as instruções de descarte 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 igual ao restante do código-fonte - não há 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 apenas atualizar o servidor de teste, espero que você queira dizer o servidor de desenvolvimento. Se os desenvolvedores estão atualizando o servidor de teste em tempo real, você está olhando para um mundo de dor quando se trata de descobrir o que você precisa liberar.

Sim.

what is the best method to keep it and update it there?

Escreva um script do construtor de esquemas. Verifique depois de fazer alterações. Confira antes de executá-lo.

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

Grave scripts de migração de esquema formal. Verifique-os após o teste. Confira-os antes de executá-los.

O que mais há?

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

Esta evolução orgânica dificulta a migração de esquemas 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 de teste, uma versão de controle de qualidade e oito versões de desenvolvimento. Tudo ligeiramente diferente.

Se houver uma única origem autoritativa, 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ódigos. O código All deve estar em um sistema de controle de versão.

Migrações

• Use migrações de banco de dados

Permite que você use os mesmos arquivos db em desenvolvimento, qa e releases.

• Liberar para o banco de dados com um número de release

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

Existem ferramentas como liquibase destinadas a fornecer controle de origem para bancos de dados. É complicado manter scripts de alteração / atualização em sua ferramenta de controle de código-fonte regular, como muitas empresas fazem e você nem sempre pode reimplantar o banco de dados do zero.

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

Sim

E furthemore, você vai querer ramos .

Eu uso o Git para filiais:

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

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

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

Eu ainda não encontrei um sistema all-in-one [para PostgreSQL], então eu tive que escrever funções / scripts para reindexar corretamente ao mesclar as ramificações (por exemplo, qualquer índice da ramificação de produção não deve ser modificado porque os clientes confiam neles, enquanto que os índices + chaves estrangeiras do ramo de desenvolvimento que se cruzam com os conteúdos de produção devem ser reindexados: não funcionará para todas as aplicações, mas cobre todos os casos de nossa aplicação, então é bom o suficiente).

Mas a idéia geral é que conteúdo do banco de dados é uma parte essencial do aplicativo, e todos os recursos devem estar no controle de origem , ergo yes, você deve usar o controle de origem também.

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

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

Aqui está o problema que eu tenho visto muitas vezes quando não há controle de versão ou gerenciamento de mudanças nos bancos de dados de desenvolvimento. O programador A faz uma alteração em uma tabela, visão ou proc. O programador B faz uma mudança na mesma coisa e sobrescreve o que o programador A fez. Ou o DBA restaura um banco de dados de produção para o desenvolvimento e sobregrava as alterações. Eu vi esse tipo de coisa causar sofrimento considerável, muitas vezes não é engraçado. E isso é apenas em sistemas de desenvolvimento. As coisas podem ficar muito confusas quando o teste / teste e até mesmo os servidores de produção são capturados.

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 efetivo. No entanto, alguns tipos de backups de histórico e controle de alterações evitam muitos problemas.

Pense nisso como "Controle de versão" em vez de "Controle de origem". Isso significa que você pode ver todo o histórico desse script em particular. Se você pode ou não reconstruir o banco de dados para sua forma atual, será mais uma questão de suas práticas em relação a esses scripts e a qualquer estrutura usada para criá-los.

Para nossos projetos PHP / MySQL, estamos usando 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 de um projeto são armazenadas no controle de revisão / fonte / versão e são rastreadas junto com o código.

Suporta adicionar / alterar / eliminar colunas, executar consultas, adicionar / eliminar índices, restrições, etc, etc. Ele acompanhará o estado do banco de dados e aplicará as migrações ausentes. Ele também permite que você "volte no tempo" especificando uma migração na qual você precisa estar. ( php ladder.php migrate 15 )

Ah, e a última adição é o banco de dados. Execute o comando diff-save , inclua e remova algumas colunas do banco de dados e execute seu comando diff . Você verá o código de migração gerado automaticamente com base no estado do banco de dados.

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

Ele rastreia todas as alterações em um banco de dados e permite que você salve uma versão de todo o estado do banco de dados em um repositório. Em seguida, ele permite que você crie 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 fará com 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.

Eu também gostaria de trazer uma ferramenta de monitoramento que pode ser usada também como ferramenta de versionamento de dados. A ferramenta sobre a qual estou falando é o MONyog, na verdade é uma ferramenta de monitoramento do MySQL, mas com um pequeno hack podemos facilmente usá-lo como controle de versão de dados.

Mas antes de ir adiante, cito que não será aconselhável colocar todo o banco de dados para controle de versão. É ser um assassino real para rastrear a mudança de um determinado conjunto de dados.

O MONyog tem um recurso chamado CSO (Objetos SQL personalizados), que pode monitorar a alteração em um conjunto particular de dados. Adicionar um CSO é descrito 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, dá um relatório visual na página html. O relatório será algo parecido com isto