Sucursal estrategicamente
Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019
O código-fonte é um ativo importante no seu esforço de desenvolvimento. Mas pode ser um desafio gerenciar e evoluir arquivos de origem de forma eficaz quando vários desenvolvedores trabalham simultaneamente em atualizações de arquivos. Você pode usar um sistema de controle de versão para armazenar o código-fonte em repositórios compartilhados, isolar esforços de desenvolvimento paralelos, integrar alterações de código e recuperar versões anteriores de arquivos. Um elemento-chave no controle de versão é a ramificação que permite o desenvolvimento simultâneo. Se você ramificar estrategicamente, poderá manter a ordem e a consistência de várias versões do seu software.
Team Foundation fornece um sistema de controle de versão flexível e confiável. Você pode usar o controle de versão do Team Foundation para gerenciar várias revisões durante o desenvolvimento do código-fonte, documentos, itens de trabalho e outras informações críticas que são trabalhadas pela sua equipe.
Como sua equipe gerencia o código enquanto ele introduz várias alterações simultaneamente por meio de várias versões do projeto?
Ao trabalhar com um sistema de controle de versão, você deve considerar como configurar uma estrutura de ramificação. Você pode criar uma ramificação espelhando o arquivo de código-fonte. Em seguida, você pode alterar a ramificação sem afetar a fonte. Por exemplo, como mostra a estrutura de ramificação na ilustração a seguir, a ramificação MAIN contém a funcionalidade concluída que passou nos testes de integração e a ramificação DEVELOPMENT contém o código que está em construção. Quando uma nova funcionalidade na ramificação DESENVOLVIMENTO é concluída e pode passar nos testes de integração, você pode promover o código da ramificação DESENVOLVIMENTO para a ramificação MAIN. Este processo é designado por integração inversa. Por outro lado, se você mesclar o código da ramificação MAIN para a ramificação DEVELOPMENT, o processo será chamado de integração direta.
Para obter mais informações sobre como criar e mesclar ramificações de código, consulte a seguinte página no site do CodePlex: Team Foundation Server Branching Guide 2.0.
A ramificação e a fusão obedecem aos seguintes princípios:
Cada ramificação deve ter uma política definida sobre como integrar o código a essa ramificação. Por exemplo, na estrutura de ramificação da ilustração anterior, você pode atribuir um membro da equipe para possuir e gerenciar a ramificação MAIN. Este membro é responsável por realizar a operação inicial do ramo, inverter as mudanças de integração do ramo DESENVOLVIMENTO para o ramo PRINCIPAL, e avançar integrando as mudanças do ramo PRINCIPAL para o ramo DESENVOLVIMENTO. A integração direta é importante quando a filial MAIN também integra mudanças de outras filiais.
A ramificação MAIN deve conter código que passou nos testes de integração para que esteja sempre pronto para uma versão.
O ramo de DESENVOLVIMENTO (ou trabalho) evolui constantemente porque os membros da equipe verificam as mudanças periodicamente.
Os rótulos são instantâneos dos arquivos em uma ramificação em um momento específico.
Para obter mais informações, consulte Usar rótulos para tirar um instantâneo de seus arquivos.
Team Foundation Build permite que você escolha entre vários tipos de compilações para suas ramificações: manual, contínua, gated, rolling e scheduled. Recomendamos que a ramificação MAIN tenha um tipo de compilação de check-in fechado. Isso significa que a ramificação DESENVOLVIMENTO deve passar todos os requisitos para a ramificação MAIN antes que você possa confirmar uma integração reversa. A ramificação DESENVOLVIMENTO deve executar um tipo de compilação contínua porque sua equipe deve saber o mais rápido possível quando um novo check-in afeta a ramificação DESENVOLVIMENTO.
Com que frequência sua equipe deve reverter, integrar e encaminhar a integração?
Como mostrado na ilustração a seguir, a integração reversa e a integração direta devem ocorrer pelo menos quando você concluir uma história de usuário. Embora cada equipe possa definir a completude de forma diferente, a conclusão de uma história de usuário geralmente significa que você conclui a funcionalidade e os testes de unidade correspondentes. Você pode reverter a integração com a ramificação MAIN somente depois que os testes de unidade tiverem verificado a estabilidade da ramificação DEVELOPMENT.
Se você tiver mais de uma ramificação de trabalho (DESENVOLVIMENTO), a integração direta para todas as ramificações de trabalho deve ocorrer assim que qualquer ramificação se integrar à ramificação PRINCIPAL. Como a ramificação MAIN é mantida estável, a integração avançada é segura. Conflitos ou falhas nas ramificações de trabalho podem ocorrer porque você não pode garantir que as ramificações de trabalho sejam estáveis.
É importante que resolva todos os conflitos o mais rapidamente possível. Ao usar um check-in fechado para a filial MAIN, você ajuda a tornar a integração inversa muito mais fácil, porque portões de qualidade ajudam a evitar conflitos ou erros na filial MAIN. Para obter mais informações, consulte Check-in em uma pasta controlada por um processo de compilação de check-in fechado.
Como sua equipe gerencia fontes que implementam diferentes histórias de usuários?
Como mostra a ilustração a seguir, você pode fazer check-in de alterações em uma ramificação de trabalho periodicamente para concluir uma história de usuário. Você pode implementar várias histórias de usuário na mesma ramificação ao mesmo tempo. No entanto, você pode reverter a integração para a ramificação MAIN somente quando concluir todo o trabalho em andamento. É recomendável que você agrupe histórias de usuário por tamanho semelhante, porque você não quer que uma história de usuário grande bloqueie a integração de muitas histórias pequenas. Você pode dividir os dois conjuntos de histórias de usuários em duas ramificações.
Quando a equipe deve adicionar uma filial?
Você deve criar ramificações nas seguintes situações:
Quando você deve liberar o código em um cronograma/ciclo diferente das ramificações existentes.
Quando seu código requer uma política de ramificação diferente. Se você criar uma nova filial que tenha a nova política, poderá agregar valor estratégico ao seu projeto.
Quando a funcionalidade é liberada para um cliente e sua equipe planeja fazer alterações que não afetam o ciclo de lançamento planejado.
Você não deve criar uma ramificação para cada história de usuário porque isso cria um alto custo de integração. Embora o TFVC facilite a ramificação, a sobrecarga de gerenciamento de filiais pode se tornar significativa se você tiver muitas filiais.
Como a equipe gerencia as versões do ponto de vista do controle de versão?
Sua equipe deve ser capaz de liberar o código no final de qualquer sprint. Usando Team Foundation Server, você pode rotular uma ramificação para tirar um instantâneo do código em um ponto específico no tempo. Como mostra a ilustração a seguir, você pode rotular a ramificação MAIN para uma versão. Isso permite que você retorne a ramificação ao seu estado neste momento.
Como você deve implementar atualizações em versões, a criação de uma ramificação para uma versão ajuda sua equipe a continuar a trabalhar de forma independente na próxima sprint sem criar conflitos com versões futuras. A ilustração a seguir mostra uma ramificação que contém código para uma atualização e que é integrada inversa na ramificação MAIN após uma liberação no final do segundo sprint.
Ao criar uma ramificação para uma versão, você deve criar essa ramificação a partir da ramificação MAIN, que é a mais estável. Se você ramificar para liberação de uma ramificação de trabalho, isso pode causar desafios de integração porque a estabilidade das ramificações de trabalho não é garantida.