TFS modelo de ramificação para apoiar longa QA (teste do sistema) ciclo

Question

Digamos que você tenha um aplicativo. Esta aplicação é para ser testado e QA implantado para produção. Há algumas restrições sobre o ciclo de vida da aplicação.

1. Somente uma versão do aplicativo irá sempre existir em produção.
2. Uma vez implantado para produção, se necessário hot-fixes pode ter que ser desenvolvido. Hot-fix são mais bem orientadas para correção específica defeito alta gravidade e não introduzir novas funcionalidades. A alteração de código-fix quente deve ser inversa integrado a outros ramos.
3. Antes relessing à produção de nova versão característica que deve passar por ciclo de QA.
4. Depois de lançar a QA leva tempo significativo para testar o aplicativo. No primeiro ciclo QA se QA abre 20 defeitos que precisam ser corrigidos na próxima versão para QA sem mais recursos para teste. Se a equipe de controle de qualidade, em seguida, reabre dizer 10 defeitos, em seguida, na próxima versão para QA eles só querem os 10 defeitos a serem corrigidos. Há outros defeitos ou quaisquer novos recursos. O próximo recurso só pode acontecer após a contagem de defeito é 0 (ou alguns defeitos são decidiu não ser fixa ou aprimoramento etc.).
5. Uma vez que o ciclo de QA leva tempo, durante esse tempo de desenvolvimento não pode parar. Novos recursos deve continuar a ser desenvolvido para a próxima versão do recurso.

Como você configurar suas TFS de ramificação modelo.

Answer 1

Parece que você é um candidato perfeito para a estratégia "Standard" da orientação TFS ramo / merge: http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785

Em essência, isto leva a sua Dev básica <-> Main <-> modelo Release, em seguida, adiciona mais uma camada de engano. hot fixes obter a sua própria filial no lado lançamento da hierarquia, de modo que o seu desenvolvimento + teste não interromper o ciclo de QA ordinária acontecendo na principal nem poluem a santidade do lançamento. Você pode ver uma ilustração visual na página 7 do PDF.

Você tem uma exigência férrea de que ramo de lançamento (es) representam um instantâneo exato da produção (ou seja, há uma relação 1: 1 entre checkins para liberar e implementações, e / ou um ramo comunicado separado criado por implantação)? Se não, então você não pode sequer precisa do ramo hotfix - fazer correcções diretamente no lançamento. Isso é abordado na estratégia de "Basic" no início do documento.

Em qualquer caso, certifique-se de ler todo o conjunto de documentos. Não é muito, mas destila um monte de resultados de implementações do mundo real. (Os "VSTS Rangers" são essencialmente constituída por MVPs e outros consultores on-site)

Para um olhar mais longo, mais teórica em estratégias de desenvolvimento da equipe e sua implementação no TFS, confira os papéis dos padrões & grupo Práticas: http://msdn.microsoft.com/en-us/library/bb668991. aspx http://branchingguidance.codeplex.com/Wiki/View.aspx?title= html