Selecionar uma estratégia de branches eficaz

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

A criação de branches para seus repositórios do Controle de Versão do Team Foundation (TFVC) auxilia no isolamento dos riscos. Considere alguns desafios que os membros da equipe normalmente enfrentam ao trabalhar em um projeto de software composto por 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 funcionalidade razoavelmente discreto. Mas cada equipe também depende da funcionalidade compilada por outras equipes. É necessário isolar o risco das alterações introduzidas pelo trabalho realizado em cada uma dessas equipes e ainda, eventualmente, é necessário mesclar todos os seus esforços em um produto.

• A equipe de teste precisa de uma versão estável do código a ser testado e, ao mesmo tempo, os desenvolvedores precisam continuar em frente com os novos recursos que ocasionalmente desestabilizarão o produto.

• O software tem duas versões anteriores e uma versão atual em andamento. Mesmo que a maioria do esforço de desenvolvimento seja investida na versão atual, as versões anteriores ainda devem ter suporte com versões ocasionais de service packs, correções críticas e atualizações de segurança, e outras alterações.

Este artigo explora algumas estratégias comuns de ramificação para ajudá-lo a tomar a decisão certa.

Ao contrário dos branches do Git, que usam o repositório como escopo, os branches do TFVC usam como escopo o caminho e não são tão leves. Seja exigente na criação de ramificações e somente crie uma ramificação quando você tiver a necessidade de isolamento de código ou versão.

Somente Principal

A estratégia Somente principal pode ser baseada em pastas ou com a pasta principalconvertida em um Branch, para habilitar recursos de visibilidade adicionais. Você confirma suas alterações no branch principal e, opcionalmente, indica marcos de desenvolvimento e lançamento com rótulos.

RISCO: a mutabilidade e a falta de histórico dos rótulos do TFVC podem gerar riscos no controle das alterações.

Comece com a estratégia de ramificação Somente principal, crie branches de forma estratégica e adote outras estratégias para desenvolver estratégias mais complexas conforme necessário.

Isolamento de desenvolvimento

Quando precisar proteger e manter um branch principal estável, você poderá ramificar um ou mais branches de desenvolvimento a partir do principal. Isso proporciona isolamento e desenvolvimento simultâneo. O trabalho pode ser isolado em branches de desenvolvimento por recurso, organização ou colaboração temporária.

É possível que haja alterações no branch principal. Sempre faça a integração avançada (FI) do branch principal para o branch dev e resolva os conflitos de mesclagem. Em seguida, faça a RI (integração reversa) das mudanças de volta para principal. Mantenha o mesmo padrão de qualidade entre os diferentes branches. Crie e execute BVTs (testes de verificação de build) no desenvolvimento da mesma maneira que você está fazendo no principal.

OBSERVAÇÃO: com essa estratégia, é provável que as equipes mantenham o branch de desenvolvimento para sempre, potencialmente criando 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 ramificar um ou mais branches de recursos do principal, conforme mostrado, ou a partir de seus branches de desenvolvimento.

Quando você precisa trabalhar em um recurso específico, pode ser uma boa ideia criar um branch de recurso.

Encurte o tempo de trabalho nos recursos e em seu branch de recursos associado. Faça a FI (integração avançada) do branch pai com frequência. Faça a RI (integração reversa) de volta ao pai somente quando alguns critérios de equipe acordados, por exemplo, definição de concluído, são atendidos. A reversão de recursos em principal pode ser cara e pode redefinir o teste.

Isolamento de versão

O isolamento de versão apresenta um ou mais branches de lançamento do principal. A estratégia permite o gerenciamento simultâneo de versão, várias versões paralelas e instantâneos de base de código no momento da versão.

Quando a versão estiver pronta para ser bloqueada, é hora de criar um novo branch para a versão.

Nunca faça a integração avançada (FI) a partir do principal. Bloqueie os branches de versão usando permissões de acesso, para evitar modificações não intencionais em uma versão. Patches e correções frequentes feitas no branch de versão podem ser objeto de integração reversa (RI) de volta ao branch principal.

OBSERVAÇÃO: nenhum dos cenários de ramificação é imutável, razão pela qual você percebe hotfixes de emergência executados nos branches de versão. Aprimore cada estratégia para corresponder aos seus requisitos, sem perder de vista a complexidade e o custo associados.

Isolamento de manutenção e versão

A estratégia de manutenção e isolamento de versão introduz branches de manutenção . Essa estratégia permite o gerenciamento simultâneo de service packs e instantâneos de 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.

Assim como o isolamento de versão, os branches de isolamento e versão de manutenção são criados quando a versão está pronta para ser bloqueada. Nunca encaminhe a integração de principal à manutenção ou da manutenção à versão. Bloqueie o branch de lançamento para evitar modificações. Futuras alterações de manutenção podem ser feitas no branch de manutenção .

Crie novos branches de manutenção e versão para as versões subsequentes se você precisar desse nível de isolamento.

Manutenção, hotfix, isolamento de versão

Embora não seja recomendado, você pode continuar a desenvolver as estratégias, introduzindo branches de hotfix adicionais e os cenários de lançamento associados.

Neste ponto, você explorou com êxito alguns dos cenários comuns de ramificação do TFVC. Você pode aprimorá-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.

Perguntas e respostas

Por que os branches devem ter curta duração?

Mantendo a curta duração dos branches, os conflitos de mesclagem são mantidos no menor número possível.

Por que só ramificar se necessário?

Para adotar o DevOps, você precisa contar com a automação de build, teste e implantação. A alteração é contínua, frequente e as operações de mesclagem mais desafiadoras, pois os conflitos de mesclagem geralmente exigem intervenção manual. Portanto, é recomendável evitar ramificação e contar com outras estratégias, como a ativação e desativação de recursos.

Por que remover branches?

Sua meta deve ser fazer com que as alterações retornem ao principal o mais rápido possível, para atenuar as consequências de mesclagem a longo prazo. Ramificações temporárias, não usadas e abundantes causam confusão e sobrecarga para a equipe.

Uma base de código pode ser ramificada entre projetos?

Sim. Isso não é recomendado, a menos que as equipes precisem compartilhar a origem e não possam compartilhar um processo comum.

E a 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, ela funciona com ciclos de teste longos e equipes separadas de desenvolvimento e teste. A estratégia não é mais recomendada. Para obter mais informações sobre essa estratégia, consulte as diretrizes de ramificação.

Ao mesclar o desenvolvimento com o branch principal, por que nenhuma alteração é detectada?

Você provavelmente ignorou as alterações das mesclagens anteriores, por exemplo, usando a opção de resolução de conflitos keep source. Para obter mais detalhes, consulte mesclar o branch de desenvolvimento com o principal: não houve alterações à mesclagem.

Há semelhanças entre as estratégias de branch do TFVC e do Git?

A estratégia de ramificação isolamento de recursos do TFVC é semelhante aos branches de tópico do Git.

Autores: Jesse Houwing, Marcus Fernandez, Mike Fourie e Willy Schaub da ALM | DevOps Rangers. Você pode contatá-los aqui.

© 2015 Microsoft Corporation. Todos os direitos reservados. Este documento é fornecido como foi escrito. As informações e opiniões apresentadas neste documento, incluindo URLs e outras referências a sites da Web, podem ser alteradas sem aviso prévio. Você assume o risco de usá-las.

Este documento não fornece direitos legais e nenhuma propriedade intelectual sobre qualquer produto da Microsoft. Você pode copiar e usar este documento para fins de referência interna.