Selecione uma estratégia de ramificação eficaz
Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019
Criar ramificações para seus repositórios de controle de versão do Team Foundation (TFVC) são úteis para isolar o risco. Considere alguns desafios que os membros da equipe normalmente enfrentam quando trabalham em um projeto de software que conta com mais de cinco ou dez pessoas:
O grupo tem algumas (ou talvez várias) equipes de recursos diferentes, cada uma trabalhando em um conjunto de funcionalidades que é razoavelmente discreto. Mas cada equipe também depende da funcionalidade construída por outras equipes. Você precisa isolar o risco das mudanças introduzidas pelo trabalho feito em cada uma dessas equipes e, no entanto, eventualmente, você precisa unir todos os seus esforços em um único produto.
A equipe de teste precisa de uma versão estável do código para testar e, no entanto, simultaneamente, os desenvolvedores precisam continuar avançando com novos recursos que ocasionalmente desestabilizarão o produto.
O software tem duas versões anteriores e uma versão atual em andamento. Embora a maior parte do esforço de desenvolvimento seja investido na versão atual, as versões anteriores ainda devem ser suportadas com versões ocasionais de service packs, correções críticas e patches de segurança e outras alterações.
Este artigo explora algumas estratégias de ramificação comuns para ajudá-lo a tomar a decisão certa.
Ao contrário das ramificações Git, que têm escopo de repositório, as ramificações TFVC têm escopo de caminho e não são tão leves. Defina sua barra para criar ramificações altas e somente ramificações quando você tiver uma necessidade de código ou isolamento de liberação.
Apenas principal
A estratégia Somente principal pode ser baseada em pasta ou com a pasta principal convertida em uma ramificação, para habilitar recursos adicionais de visibilidade. Você confirma suas alterações na ramificação principal e, opcionalmente, indica marcos de desenvolvimento e lançamento com rótulos.
RISCO: A mutabilidade e a falta de histórico com rótulos TFVC podem adicionar risco de controle de mudança.
Comece com a principal estratégia de ramificação, ramificar estrategicamente e adotar outras estratégias para evoluir para estratégias mais complexas, conforme necessário.
Isolamento do desenvolvimento
Quando você precisa manter e proteger uma ramificação principal estável, você pode ramificar uma ou mais ramificações de desenvolvimento da principal. Permite o isolamento e o desenvolvimento simultâneo. O trabalho pode ser isolado em ramificações de desenvolvimento por recurso, organização ou colaboração temporária.
É possível que haja mudanças no ramo principal . Sempre encaminhe a integração (FI) principal para a ramificação de desenvolvimento e resolva conflitos de mesclagem. Em seguida, as alterações de integração reversa (RI) voltam para a principal. Mantenha a mesma barra de qualidade em todas as filiais. Crie e execute testes de verificação de compilação (BVTs) no dev da mesma forma que você está fazendo no main.
NOTA: Com essa estratégia, é provável que as equipes mantenham a ramificação de desenvolvimento para sempre, potencialmente construindo um grande histórico de tíquetes de mesclagem.
Isolamento de recursos
O isolamento de recursos é uma derivação especial do isolamento de desenvolvimento, permitindo que você ramificar uma ou mais ramificações de recursos da principal, conforme mostrado, ou de suas ramificações de desenvolvimento .
Quando você precisa trabalhar em um recurso específico, pode ser uma boa ideia criar uma ramificação de recurso.
Mantenha o tempo de vida do trabalho de recursos e a ramificação de recursos associada de curta duração. Integração direta (FI) alterações da ramificação pai com freqüência. Integração reversa (RI) de volta ao pai somente quando alguns critérios de equipe acordados, por exemplo, a definição de concluído, forem atendidos. A reversão de recursos no principal pode ser cara e pode redefinir os testes.
Isolamento de liberação
O isolamento de liberação introduz uma ou mais ramificações de liberação do principal. A estratégia permite gerenciamento de versões simultâneas, versões múltiplas e paralelas e instantâneos da base de código no momento da versão.
Quando a versão estiver pronta para ser bloqueada, é hora de criar uma nova ramificação para a versão.
Nunca forward integrate (FI) a partir do principal. Bloqueie ramificações de liberação usando permissões de acesso, para evitar modificações não intencionais em uma versão. Patches e hot fixes feitos na ramificação de lançamento podem ser integrados inversamente (RI) de volta para a ramificação principal.
Observação : nenhum dos cenários de ramificação são imutáveis, e é por isso que você observa hotfixes de emergência executados em ramificações de versão. Evolua cada estratégia para atender às suas necessidades, sem perder de vista a complexidade e o custo associado.
Manutenção e isolamento de liberação
A estratégia de Manutenção e Isolamento de Liberação introduz ramificações de manutenção . Essa estratégia permite o gerenciamento simultâneo de service packs e snapshots da base de código no momento do lançamento.
Use essa estratégia se precisar de um modelo de manutenção para que os clientes atualizem para a próxima versão principal e service packs adicionais por versão.
Como o isolamento de versão, o isolamento de manutenção e as ramificações de liberação são criados quando a liberação está pronta para ser bloqueada. Nunca encaminhe a integração do principal para a manutenção, ou da manutenção para a liberação. Bloqueie a ramificação de liberação para evitar modificações. Alterações futuras de manutenção podem ser feitas no ramo de manutenção.
Crie novas ramificações de manutenção e liberação para versões subsequentes se precisar desse nível de isolamento.
Manutenção, hotfix, isolamento de versão
Embora não seja recomendado, você pode continuar a evoluir as estratégias, introduzindo ramificações de hotfix adicionais e cenários de lançamento associados.
Neste ponto, você explorou com sucesso alguns dos cenários comuns de ramificação da TFVC. Você pode evolui-los ou investigar outras estratégias, como alternar recursos, ativar e desativar recursos para determinar se um recurso está disponível em tempo de execução.
Q&A
Por que as filiais devem ser de curta duração?
Ao manter as ramificações de curta duração, os conflitos de fusão são mantidos no mínimo possível.
Porquê apenas ramificar se necessário?
Para adotar o DevOps, você precisa confiar na automação de compilação, teste e implantação. A mudança é contínua, frequente e as operações de mesclagem são mais desafiadoras, pois os conflitos de mesclagem geralmente exigem intervenção manual. Recomenda-se, portanto, evitar ramificações e confiar em outras estratégias, como a alternância de recursos.
Porquê remover ramos?
Seu objetivo deve ser fazer com que as mudanças voltem ao principal o mais rápido possível, para mitigar as consequências da fusão a longo prazo. Ramos temporários, não utilizados e abundantes causam confusão e sobrecarga para a equipe.
Uma base de código pode ser ramificada entre projetos?
Sim. Não é recomendado, a menos que as equipes devam compartilhar a fonte e não possam compartilhar um processo comum.
E quanto à estratégia de promoção de código?
A estratégia de promoção de código parece uma relíquia da era do desenvolvimento em cascata. Normalmente, é com ciclos de teste longos e equipes de desenvolvimento e teste separadas. A estratégia já não é recomendada. Para obter mais informações sobre essa estratégia, consulte as diretrizes de ramificação.
Ao mesclar o desenvolvimento com a ramificação principal , por que nenhuma alteração é detetada?
Você provavelmente ignorou alterações em mesclagens anteriores, por exemplo, usando a opção de resolução de keep source conflitos. Consulte mesclando ramificação de desenvolvimento para principal: não houve alterações para mesclar para obter detalhes.
Existem semelhanças entre as estratégias de TFVC e Git?
A estratégia de ramificação do TFVC Feature Isolation é semelhante às ramificações do tópico Git.
Autores: Jesse Houwing, Marcus Fernandez, Mike Fourie e Willy Schaub da ALM | DevOps Rangers. Pode contactá-los aqui.
(c) 2015 Microsoft Corporation. Todos os direitos reservados. Este documento é fornecido "no estado em que se encontra". As informações e opiniões expressas neste documento, incluindo URL e outras referências a sites da Internet, podem ser alteradas sem aviso prévio. O Adquirente é responsável pela utilização do mesmo.
Este documento não lhe fornece direitos legais sobre nenhuma propriedade intelectual em qualquer produto Microsoft. Poderá copiar e utilizar o presente documento para efeitos de referência pessoal a título interno.