TFS 2010 modelo ramificação para uma aplicação in-house

Question

Esta não é uma questão em que eu não tenho quaisquer idéias, mas em vez disso eu gostaria de apresentar um modelo e ver se ele é aprovado ou qualquer um pode ver problemas com ele ou tem melhores sugestões. Eles dizem que é melhor para o modelo de escolher cuidadosamente você ramificação a fim de evitar futuras dores de cabeça.

Portanto, temos uma aplicação in-house com apenas uma versão (o mais tardar) liberados para os clientes e, basicamente, existem 2 tipos de atividades de desenvolvimento: a actividade principal está trabalhando para o próximo lançamento e, geralmente, inclui novos recursos e correções de correcção e está previsto, ea segunda que não está prevista e é sobre a manutenção e inclui correcções da versão atual na produção.

Depois de longa pesquisa, decidimos ir com um Principal tronco do qual branch-out 2 ramos criança: Desenvolvimento & Manutenção (ou hotfix ). Como é apresentada no guia, o desenvolvimento diário que aconteceria no Desenvolvimento ramo de onde fazemos a integração reversa (RI) toda vez que temos apresenta pronto para o próximo lançamento. Direito antes do lançamento da integração inversa irá parar e o código será estabilizado no Principal ramo. Após o lançamento de Principal , haverá uma integração para a frente (FI) de Principal para Desenvolvimento e Manutenção .

Qualquer correcção irá acontecer em Manutenção somente e dependendo da correção (por exemplo, se queremos retê-lo na base de código) faremos uma RI em Principal e de lá a FI em Desenvolvimento .

Agora tudo parece bem, pelo menos no papel, então eu gostaria de ouvir a opinião dos outros sobre este modelo.

Por exemplo, nós também considerando ter um outro ramo, Release , onde a estabilização do código acontece antes de uma liberação para produção (em vez de trabalhar directamente no Principal ) e é claro que vai lançar daqui para a produção e fazer um RI em principal seguida por um FI para Desenvolvimento & Manutenção , mas não estamos certeza se isso vai trazer qualquer benefício ou só vai aumentar a complexidade?

E supondo que haverá recursos do Desenvolvimento que não vai estar pronto ou não é desejável para o próximo lançamento Isso significa que vamos ter que fazer alguma "cherry picking" dos changesets que estão relacionados às características queriam, mas que não é muito bom de acordo com os docs. Alguma sugestão?

Mais uma vez eu sei que não é um simples, pergunta simples, mas em vez disso uma aberta, ainda espero ouvir de qualquer pessoa com uma experiência semelhante. Agradecemos antecipadamente pela sua atenção.

Answer 1

Você já leu a documentação TFS ALM Rangers Ramificação de Orientação? O que você está propondo é muito parecido com o seu "Plano de Poder Standard", embora eles encorajam tendo ambos um lançamento e ramo "service pack" (bem como seus ramos de lançamento e manutenção acima).

http://vsarbranchingguide.codeplex.com/

Eu tenho implementado o plano de ramificação padrão em alguns clientes e não tive um problema com ele. Se você pretende adotar fluxos simultâneos de trabalho (equipes de recursos, etc) A ramificação de Orientação tem planos sólidos para isso também.

Outra coisa a considerar pode ser um modelo degrau onde você cria novas agências Dev em cada versão e congelar o antigo como autorização. Isso evitaria RIs pois você pode apenas Hotfix o velho e FI a correção para o novo ramo Dev se necessário. Eu trabalhei neste modelo bem e foi incrível.