Um ramo “modelo” é uma prática comum?

5

Achei que seria bom ter uma ramificação de controle de versão dedicada para todas as alterações no esquema do banco de dados e queria saber se alguém mais está fazendo o mesmo e quais foram os resultados.

Diga que você está trabalhando com:

  1. Modelo / documentação do esquema (algum arquivo em que você modela o banco de dados visualmente para gerar a origem do esquema, digamos, MySQL Workbench, com um arquivo .mwb, que é binário)
  2. Origem do esquema (um arquivo .sql)
  3. Geração de código baseada em esquema

A maneira normal em que estávamos trabalhando era com ramificações de recursos, portanto, fazíamos alterações nos arquivos de modelo (os específicos do banco de dados) e depois regenerávamos os pontos 2 e 3, lidando com possíveis conflitos (ou mesmo reescrevendo o código ).

Agora, diga que seu fluxo de trabalho segue o mesmo caminho da numeração do item anterior. Com uma ramificação de modelo, você não teria que reconciliar o modelo de esquema com binários em outras ramificações de recursos, ou ter que gerar novamente a origem do esquema e gerar novamente o código (que pode ter código humano sobre ele).

Faz muito sentido para mim parecer estranho não ter visto isso antes como uma prática comum.

Editar : estou contando com fusões de ramificação para serem as asserções para o modelo que corresponde ao código. Eu uso um DVCS, então não tenho medo de ramos de vida longa ou de fusões assustadoras. Eu também estou fazendo ramificação de recursos.

    
por dukeofgaming 10.10.2012 / 07:28
fonte

3 respostas

6

Eu aconselharia contra isso. Os esquemas do banco de dados são alterados juntamente com outros códigos ou recursos relacionados. Para poder acompanhar as alterações corretamente, você precisa fazer alterações coesas entre si, e um commit compartilhado é a melhor maneira de fazer isso.

Considere sua sugestão de manter o esquema em um ramo separado. Primeiramente, você mantém as ramificações para que você possa enviar alterações independentemente de outras alterações não relacionadas. O que acontece se você enviar confirmações de esquema sem o código correspondente?

  1. Você cria um histórico de confirmações que aparece "fora do azul". É difícil seguir de onde veio ou por que, depois de um tempo.
  2. Se você confirmar apenas um esquema, lembre-se de que outras pessoas também podem fazê-lo. Isso significa que outras pessoas podem puxar e reescrever / alterar as alterações do esquema e ainda passar em todos os testes (porque não estão testando o seu código). Então, quando você quiser comprometer seu código, você terá conflitos, que poderiam ter sido evitados.

Pode haver outras desvantagens ou mesmo benefícios. Mas esses 2 aqui são motivo suficiente para eu não usar essa abordagem.

Espero que ajude.

    
por 10.10.2012 / 07:50
fonte
1

Eu recomendaria colocar todos os tipos de código fonte juntos que construam um sistema em execução (incluindo consultas de banco de dados e -schemas)

Por quê? Porque, então você sempre tem uma relação entre seu código e o resto das coisas que constroem seu sistema (configuração, SQL, Readmes, Tests, ...). Se você fizer uma alteração, certamente será lembrado de alterar esses outros artefatos também. Se você tem filiais diferentes, ou até mesmo repositórios diferentes, é muito mais difícil lembrar qual revisão da ramificação A pertence à revisão da ramificação B, embora levando a erros.

Nós costumávamos trabalhar com release-branches, uma vez. Para o efeito, todos os desenvolvedores concordaram com um procedimento comum:

  1. consertar um bug no ramo de lançamento
  2. crie um patch / diff
  3. aplica o diff ao ramo principal

Isso não é muito bom, porque você duplicou as alterações que poderiam ter sido mescladas. Mas é uma abordagem fácil, cada desenvolvedor pode manipular, e o SVN / CVS-merge, às vezes, é problemático na a.

    
por 10.10.2012 / 10:42
fonte
0

É uma má ideia em termos de "filosofia de desenvolvimento" e usabilidade

  • você quebrou a regra "filial por tarefa / recurso" - a ramificação do modelo não tem tarefas relacionadas (ou mais de uma tarefa no período de tempo)
  • Este ramo será ramo "para sempre"
  • permanente adicional mescla-se com ramificações de recursos e construções interrompidas se a mesclagem for perdida após alterações de esquema
por 10.10.2012 / 17:02
fonte

Tags