Estrategicamente de filiais.

Código-fonte é um ativo importante em seu esforço de desenvolvimento. Mas ele pode ser um desafio de gerenciar com eficiência e a evolução de 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 o código-fonte em repositórios compartilhados, para isolar os esforços de desenvolvimento paralelo, para integrar as alterações de código e para recuperar versões anteriores do arquivo. Um elemento-chave no controle de versão é a ramificação que permite o desenvolvimento simultâneo. Se você ramificar 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, trabalharam por sua equipe. Para obter mais informações sobre o 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 por meio 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. 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 principal contém a funcionalidade completa que passou os 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 a partir da ramificação de desenvolvimento para a ramificação principal. Esse processo é conhecido como 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 do código, consulte a seguinte página no site da CodePlex: Team Foundation Server de ramificação guia 2.0.

Ramificação e mesclagem de envolvem os 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, inverter integrando as 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 se integra a alterações de outras ramificações.

2. A ramificação principal deve conter código que passou por testes de integração para que ele esteja sempre pronto para uma versão.

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

4. 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 dos 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 você pode confirmar 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 a ramificação de desenvolvimento.

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

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

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

É importante que resolver todos os conflitos assim que possível. Usando-se um gated check-in para a ramificação principal, você ajuda a facilitar a integração inversa porque gates de qualidade ajudam a evitar conflitos ou erros na ramificação principal. Para obter mais informações, consulte Check-In alterações pendentes que são controlados por um Check-in Gated construir.

Como o sua equipe gerenciar fontes que implementam as histórias de usuários diferentes?

Como mostra a ilustração a seguir, você pode verificar as alterações para uma ramificação de trabalho periodicamente para concluir uma história de usuário. Você pode implementar várias histórias de usuários da mesma ramificação ao mesmo tempo. No entanto, você pode reverter integrar-se à ramificação principal somente quando você concluir todo o trabalho em andamento. Recomenda-se o grupo de histórias de usuários 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 de usuários 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 em um agendamento/ciclo diferente que as ramificações existentes.

• Quando seu código requer uma diretiva de ramificação diferente. Se você criar uma nova ramificação com a nova diretiva, você pode adicionar o valor estratégico para 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 pois ele cria um custo alto de integração. Embora Team Foundation Server 2010 ramificação de torna fácil, a sobrecarga de gerenciamento de ramificações pode se tornar significativa se você tiver várias ramificações.

Como a equipe gerencia o versões a partir da perspectiva de 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 o ramo principal para uma versão. Isso permite que você retornar a ramificação para seu estado nesse ponto.

Porque você deve implementar atualizações nas versões, criar uma ramificação para uma versão ajuda sua equipe a continuar a trabalhar de forma independente no próximo sprint, sem criar conflitos com futuras versões. A ilustração a seguir mostra uma ramificação que contém o código para uma atualização e reversa que é integrado a ramificação principal após um lançamento no final do segundo sprint.

Quando você cria uma ramificação para uma versão, você deve criar a ramificação a partir da ramificação principal, que é mais estável. Se você ramificar para lançamento de uma ramificação de trabalho, ela pode causar os desafios de integração porque a estabilidade das ramificações de trabalho não é garantida.