Filiais estrategicamente

Código-fonte é um ativo importante em seu esforço de desenvolvimento.Mas pode ser um desafio para gerenciar com eficiência e evoluir arquivos de origem quando vários desenvolvedores trabalham simultaneamente em atualizações de arquivo.Você pode usar um sistema de controle de versão para armazenar código-fonte em repositórios compartilhados para isolar os esforços de desenvolvimento paralelo, para integrar as alterações de código e recuperar versões anteriores do arquivo.Um elemento-chave no controle de versão é a ramificação que permite o desenvolvimento simultâneo.Se ramifica estrategicamente, você pode manter a ordem e consistência de várias versões do software.

Team FoundationFornece um sistema de controle de versão flexível e confiável.Você pode usar Controle de versão do Team Foundation para gerenciar várias revisões durante o desenvolvimento de código-fonte, documentos, itens de trabalho e outras informações essenciais que trabalharam pela sua equipe. Para obter mais informações sobre controle de versão do Visual Studio Team Foundation Server, consulte Usando o Controle de Versão.

Como sua equipe gerencia código enquanto ele apresenta várias alterações simultaneamente através de várias versões do projeto?

Quando você trabalha 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.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 principal contém funcionalidade completa que passou por testes de integração e o ramo de desenvolvimento contém o código que está em construção.Quando uma nova funcionalidade na ramificação de desenvolvimento é concluída e pode passar os testes de integração, você pode promover o código da filial de desenvolvimento para a ramificação principal.Esse processo é chamado de integração inversa.Por outro lado, se você mesclar o código a partir da ramificação principal para a ramificação de desenvolvimento, o processo é conhecido como integração direta.

Para obter mais informações sobre como criar e mesclar as ramificações de código, consulte a seguinte página no site da CodePlex: Team Foundation Server Branching guia 2.0.

Ramificação e mesclagem envolvem princípios a seguir:

1. Cada ramificação deve ter uma diretiva definida sobre como integrar o código nessa ramificação.Por exemplo, na estrutura de ramificação da ilustração anterior, você pode atribuir um membro da equipe possuem e gerenciam a ramificação principal.Esse membro é responsável por executar a operação de ramificação inicial, inversa integrando alterações a partir da ramificação de desenvolvimento para a ramificação principal e encaminhar integrando as alterações a partir da ramificação principal para a ramificação de desenvolvimento.Integração direta é importante quando a ramificação principal também integra as alterações de outras ramificações.

2. A ramificação principal deve conter código que passou por testes de integração para que esteja sempre pronto para um lançamento.

3. DESENVOLVIMENTO (ou trabalho) ramificação evolui constantemente porque os membros da equipe verificar periodicamente as alterações.

4. Os rótulos são instantâneos de arquivos em uma ramificação em um momento específico.

   Para mais informações, consulte Use Rótulos para Obter um Instantâneo de Seus Arquivos.

Team Foundation Buildpermite escolher entre vários tipos de compilações para suas ramificações: manual, contínua, gated, sem interrupção e agendada. Recomendamos que a ramificação principal tem um tipo de compilação gated check-in. Isso significa que o ramo de desenvolvimento deve passar todos os requisitos para a ramificação principal antes de comprometer uma integração inversa.A ramificação de desenvolvimento deve executar um tipo de compilação contínua porque sua equipe deve saber assim que possível, quando um novo check-in afeta o ramo de desenvolvimento.

Freqüência deve sua equipe inversa integrar e encaminhar integrar?

Como mostrado na ilustração a seguir, a integração direta e inversa de integração devem ocorrer pelo menos ao concluir uma história de usuário.Embora cada equipe pode definir integridade diferente, conclusão de uma história de usuário geralmente significa que você conclua a funcionalidade e os testes de unidade correspondente.Você pode inverter integrar a ramificação principal somente após testes de unidade tem verificado a estabilidade da ramificação do desenvolvimento.

Se você tiver mais de uma filial do trabalho (desenvolvimento), integração direta com todas as filiais do trabalho deve ocorrer assim que qualquer ramificação integra a ramificação principal.Como a ramificação principal é mantida estável, integração direta é segura.Conflitos ou falhas nas filiais da trabalho podem ocorrer porque você não pode garantir as filiais do trabalho estão estáveis.

É importante resolver todos os conflitos assim que possível.Usando-se um check-in gated para a ramificação principal, você ajudar a facilitar a integração inversa porque gates de qualidade ajudam a evitar conflitos ou erros na ramificação principal.Para mais informações, consulte Check-in para uma pasta controlada por um Gated seleção no processo de criação.

Como sua equipe gerencia fontes implementam histórias diferentes?

Como mostra a ilustração a seguir, você pode verificar as alterações em uma ramificação de trabalho periodicamente para concluir uma história de usuário.Você pode implementar várias histórias da mesma ramificação ao mesmo tempo.No entanto, você pode inverter integrar a ramificação principal somente quando você concluir todo o trabalho em andamento.É recomendável agrupar histórias por tamanho semelhante, porque você não deseja uma história de usuário grande para bloquear a integração de muitas pequenas.Você pode dividir os dois conjuntos de histórias em duas ramificações.

Quando a equipe deve adicionar uma ramificação?

Você deve criar ramificações nas seguintes situações:

• Quando você deve liberar o código de programação/ciclo diferente de ramificações existentes.

• Quando seu código requer uma política diferente de ramificação.Se você criar uma nova ramificação tem a nova diretiva, você pode adicionar o valor estratégico para o seu projeto.

• Quando a funcionalidade é liberada para um cliente e seus planos de equipe para 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 ele cria um custo alto de integração.Embora torna fácil a ramificação, a sobrecarga de gerenciamento de filiais pode se tornar significativa se você tiver várias ramificações.

Como a equipe gerenciar os lançamentos da perspectiva 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 de um instantâneo do código em um ponto específico no tempo. Como mostra a ilustração a seguir, você pode rotular ramificação para uma versão principal. Isso permite que você retornar a ramificação para o estado nesse momento.

Porque você deve implementar atualizações em versões, criar 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 futuras versões.A ilustração a seguir mostra uma ramificação que contém código para uma atualização e reversa que é integrado a ramificação principal após um lançamento no final da segunda sprint.

Quando você cria uma ramificação de um lançamento, você deve criar ramificação a partir da ramificação principal, que é mais estável.Se ramifica para lançamento de uma ramificação de trabalho, ele pode causar desafios de integração porque não há garantia de estabilidade de filiais do trabalho.