Modèle de branchement TFS pour prendre en charge un cycle d'AQ (test de système) long

Question

Disons que vous avez une application. Cette application doit être testée QA et déployée en production. Il y a des contraintes sur le cycle de vie de l'application.

1. Une seule version de l'application existera en production.
2. Une fois déployé en production si nécessaire, des fixations à chaud peuvent devoir être développées. Les correctifs à chaud sont étroitement ciblés pour corriger un défaut spécifique de grande sévérité et ne pas introduire de nouvelles fonctionnalités. Le changement de code hot-fix doit être intégré à d'autres branches.
3. Avant de relâcher en production pour la nouvelle version de fonctionnalité, il doit passer par le cycle QA.
4. Après la libération de QA, il faut beaucoup de temps pour tester l'application. Au premier cycle d'assurance qualité, si le contrôle qualité ouvre 20 défauts, ils doivent être résolus dans la prochaine version pour le contrôle qualité sans autres fonctionnalités à tester. Si l'équipe QA rouvre alors 10 défauts, alors à la prochaine version de QA, ils veulent seulement que ces 10 défauts soient corrigés. Pas d'autres défauts ou de nouvelles fonctionnalités. La prochaine version de fonctionnalité ne peut avoir lieu qu'après que le nombre de défauts soit 0 (ou que certains défauts ne soient pas corrigés ou améliorés, etc.).
5. Étant donné que le cycle d'assurance qualité prend du temps, le développement ne peut pas s'arrêter pendant ce temps. De nouvelles fonctionnalités devraient être développées pour la prochaine version.

Comment voulez-vous configurer votre modèle de branchement TFS.

Answer 1

On dirait que vous êtes un candidat idéal pour la stratégie « Standard » de la branche TFS/guidage de fusion: http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785

En substance, cela prend votre base Dev < -> Principal < -> modèle de sortie, puis ajoute un plus de couche d'indirection. Les correctifs apportent leur propre branche du côté Release de la hiérarchie, de sorte que leur développement + testing ne perturbe pas le cycle d'AQ ordinaire qui se déroule dans Main ni ne pollue le caractère sacré de Release. Vous pouvez voir une illustration visuelle à la page 7 du PDF. Existe-t-il une exigence absolue que les branches de publication représentent un instantané exact de la production (c'est-à-dire qu'il existe une relation 1: 1 entre les vérifications vers la version et les déploiements et/ou une branche de publication distincte par déploiement)? Si ce n'est pas le cas, vous n'avez peut-être même pas besoin de la branche de correctif - effectuez des correctifs directement dans Release. Ceci est couvert dans la stratégie "de base" plus tôt dans le document.

Dans tous les cas, assurez-vous de lire toute la série de documents. Ce n'est pas long, mais distille beaucoup de résultats d'implémentations du monde réel. (Les « Rangers VSTS » sont constitués principalement de MVPs et d'autres sur place consultants)

Pour plus, aspect plus théorique sur les stratégies de développement de l'équipe & leur mise en œuvre dans TFS, vérifier les papiers des modèles & de groupe pratiques : http://msdn.microsoft.com/en-us/library/bb668991.aspx http://branchingguidance.codeplex.com/Wiki/View.aspx?title=html