Para a versão baseada em branch, precisamos falar sobre o diagrama a seguir, que ilustra perfeitamente o panorama do processo de gerenciamento de configuração. Primeiramente, este diagrama foi escrito com base no modelo Git, mas na verdade, Git e Subversion já entenderam o conceito de gerenciamento de controle de versões, embora o Git faça um salto qualitativo em relação ao Subversion no gerenciamento de branch e desempenho distribuído (mas esse não é o foco deste artigo).
Antes de introduzir o princípio deste grafo, vamos falar sobre duas estratégias diferentes para controle geral de versões: uma é "backbone pioneer, branch estável" e a outra é "backbone estável, branch pioneer". Como o nome sugere, é a versão estável (versão de produção), no tronco ou no ramo. No caso das equipes de projeto tradicionais que usam VSS, é difícil dizer a qual modo ele pertence, principalmente porque o próprio VSS não possui uma estratégia de gestão de agência, então muitas equipes de projeto estabelecem duas bibliotecas de versões (ou três), respectivamente, correspondentes ao ambiente de produção e ao ambiente de desenvolvimento, claro, isso também é uma espécie de gestão de filial disfarçada. No entanto, se você mudar para Subversion ou Git como ferramenta de controle de versão, a maioria das equipes usa o modo trunk estável, ou seja, o trunk (truck ou master) corresponde a um ambiente de produção estável e marca diferentes versões para indicar a versão de produção. Pessoalmente, acho que o padrão de código backbone estável deveria ser a solução de gerenciamento de versões de código mais comum atualmente. A imagem acima é o modelo padrão de gerenciamento de "backbone estável".
mestre: A subversão correspondente é o caminhão。 Correspondente à versão de produção, ela é marcada uma vez a cada lançamento.
Branch de Release (também conhecido como branch de integração): Desde que a produção seja atualizada, ela precisa ser integrada primeiro ao ramo de lançamento (branch de integração). É um pouco semelhante ao que a equipe do projeto atualmente chama de conceito de "pré-produção" e "ambiente simulado".
Branch de desenvolvimento (branch de desenvolvimento ou branch de desenvolvimento): O ambiente enfrentado pelo ambiente de desenvolvimento.
Ramo de características (ramo de características): Algumas funções independentes podem ser separadas de um ramo de desenvolvimento separado. Isso serve principalmente para lidar com o fato de que alguns recursos podem demorar relativamente para serem atualizados, para não arrastar o lançamento e os ramos separados.
Desvio de correções rápidas (ramo de correção de bugs): O bug aqui é principalmente um bug de produção.
Depois de introduzir o tronco e os galhos, preciso indicar a direção da geração e fusão desses ramos.
Master é a versão de produção, e o tronco aceita apenas dois ramos para fusão, um é o ramo de liberação (ramo de integração) e o outro é o ramo de hotfixes. Nenhum outro ramo pode ser fundido em um ramo de produção.
O ramo de lançamento é criado inicialmente ao mesmo tempo da produção, que é exatamente igual à produção. Ele só aceita a ramificação de desenvolvimento para se fundir com ela. Em outras palavras, ele não aceita mesclar diretamente do branch de feature ou do branch de correções de bugs.
O ramo de desenvolvimento, o ramo de desenvolvimento, assim como o ramo de integração, é o mesmo que o ambiente de produção em determinado momento. No entanto, à medida que o desenvolvimento avança, novos recursos continuarão sendo criados no ramo de desenvolvimento. A teoria de desenvolvimento só aceita a fusão de dois ramos, um é para hotfixes e o outro é o branch de características.
Branch de características, começando em um certo ponto (versão) com o branch de desenvolvimento, o branch de características eventualmente se fundirá com o branch de desenvolvimento.
Vamos apresentar brevemente o método de controle de versão na forma de um cenário
Suponha que uma versão de produção seja dividida em ramos (dev, hotfixes, release), e nesse momento, o dev comece a desenvolver um total de dez funções. Quando 8 dos 10 recursos foram desenvolvidos, a equipe de testes começou a intervir para testes internos, e o administrador de configuração implantou o ramo de desenvolvimento no ambiente de desenvolvimento para testes por meio de ferramentas de integração contínua (um tema separado aqui). Quando a verificação de teste constatou que duas das funções eram completamente inaceitáveis e precisavam ser refeitas, como seguro simples e devolução de sinistros, dois ramos de recursos foram separados do dev, correspondentes a seguro simples e reembolso de sinistros, e no branch dev, o código correspondente também precisou ser revertido (operação manual aqui). Quando a equipe de teste descobre que não há problema com o teste do dev branch, ele atende às condições do UAT, então o administrador de configuração funde o dev branch no release branch e então usa ferramentas de integração contínua para publicar esse branch no ambiente de pré-produção e entregá-lo ao usuário para teste. Quando a verificação do usuário encontra um problema, o desenvolvedor modifica o dev branch e depois o funde no branch de release (aqui, na imagem original, ele é modificado diretamente no release branch, acho que isso não é bom, recomendo que o desenvolvedor apenas encare o dev branch), quando o processo de verificação de release e verificação descobre de repente que há um bug sério no entorno de build que precisa ser corrigido imediatamente, então ele é modificado urgentemente no hotfixes branch, e é lançado com urgência após verificar que está correto. Ao mesmo tempo, o ramo de hotfixes é fundido com dev (aqui é principalmente manual, porque nesse momento a versão de produção já é muito diferente da versão dev, e muitas vezes é impossível completar a fusão automática), e então dev é incorporado à versão. Após um período de tempo, a função de devolução de reivindicação pode não ser mais necessária e precisa ser cancelada, então o ramo de retorno de reivindicação será excluído. Outro recurso é fácil de garantir e foi desenvolvido e incorporado novamente ao ramo de desenvolvimento para lançar a próxima versão online.
O cenário acima basicamente inclui desenvolvimento rotineiro, desempacotamento, atualizações emergenciais e outros cenários no processo diário de desenvolvimento.
|
Publicado em 08/04/2018 10:25:39
|
|
|
|
