TFS 2010 modèle de branchement pour une application en interne

Question

Ce n'est pas une question où je n'ai aucune idée, mais je voudrais présenter un modèle et voir si elle est approuvée ou tout le monde peut voir les problèmes avec elle ou a de meilleures suggestions. Ils disent qu'il est préférable de choisir avec soin vous modèle de branchement afin d'éviter des maux de tête futurs.

Nous avons donc une application avec une seule version (la dernière) en interne libérés aux clients et fondamentalement, il y a deux types d'activités de développement: l'activité principale travaille pour la prochaine version et contient habituellement des nouvelles fonctionnalités et des correctifs de correction et il est prévu, et le second qui est pas prévu et concerne la maintenance et inclut les correctifs de la version actuelle de la production.

Après de longues recherches, nous avons décidé d'aller avec un principal tronc dont nous branches enfants branche sur 2: Développement Maintenance (ou Hotfix ). Comme il est présenté dans le guide, le développement quotidien se passerait-il dans le Développement branche d'où nous faisons l'intégration inverse (RI) chaque fois que nous proposons des avantages prêts pour la prochaine version. Juste avant la sortie de l'intégration inverse arrêtera et le code sera stabilisé dans la branche principal . Après la sortie de principal il y aura une intégration vers l'avant (FI) de principal Développement et Maintenance .

Tout correctif se produira dans Maintenance uniquement et en fonction de la solution (par exemple, si nous voulons conserver dans la base de code), nous ferons un RI dans principal à partir de là une FI dans développement .

Maintenant, tout semble bien, au moins sur le papier, donc je voudrais entendre les opinions des autres sur ce modèle.

Par exemple, nous permettrait également d'envisager d'avoir une autre branche, Release , où la stabilisation du code qui se passe avant une mise en production (au lieu de travailler directement dans principal ) et Bien sûr, nous publierons d'ici à la production et faire un RI dans principal suivie d'une FI à développement Maintenance , mais nous ne sommes pas sûr que cela apportera un avantage ou va simplement augmenter la complexité?

Et en supposant qu'il y aura des fonctionnalités Développement qui ne sera pas prêt ou non désiré pour la prochaine version cela signifie que nous devrons faire quelques « picorage » des changesets qui sont liés aux caractéristiques recherchées, mais ce n'est pas trop bon selon les docs. Toutes les suggestions?

Encore une fois, je sais que ce n'est pas une simple question simple mais à la place un processus ouvert, encore je l'espère entendre toute personne ayant une expérience similaire. Merci d'avance pour votre attention.

Answer 1

Avez-vous lu les Rangers ALM TFS Branching la documentation d'orientation? Ce que vous proposez ressemble beaucoup à leur branche « Plan Branch Standard », bien qu'ils encouragent ayant à la fois une libération et « service pack » (un peu comme vos branches de sortie et d'entretien ci-dessus).

http://vsarbranchingguide.codeplex.com/

Je l'ai mis en œuvre le plan Branching standard à quelques clients et n'ont pas eu un problème avec elle. Si vous envisagez d'adopter des flux simultanés de travail (équipes de fonction, etc.) l'orientation Branching a des plans solides pour cela aussi.

Une autre chose à considérer peut-être un modèle d'escalier où vous créez de nouvelles branches de Dev à chaque sortie et geler l'ancien comme une libération. Cela éviterait puisque vous pouvez RIs juste correctif l'ancien et le correctif FI à la nouvelle branche Dev si nécessaire. Je travaille dans ce modèle aussi bien et il était génial.