Créer une branche de façon stratégique

Le code source est une ressource importante de votre effort de développement. Cependant, il peut s'avérer difficile de gérer et faire évoluer efficacement des fichiers sources lorsque plusieurs développeurs travaillent simultanément sur des mises à jour de fichiers. Vous pouvez utiliser un système de contrôle de version pour stocker le code source dans des référentiel partagés, pour isoler les efforts de développement en parallèle, pour intégrer des modifications de code et pour récupérer des versions de fichiers précédentes. Un élément clé du contrôle de version est la création de branches qui permet un développement simultané. Si vous créez des branches de façon stratégique, vous pouvez conserver l'ordre et la cohérence de plusieurs versions de votre logiciel.

Team Foundation fournit un système de contrôle de version flexible et fiable. Vous pouvez utiliser le contrôle de version Team Foundation pour gérer plusieurs révisions au cours du développement du code source, de documents, d'éléments de travail et d'autres informations critiques traitées par votre équipe. Pour plus d'informations sur le contrôle de version dans Visual Studio Team Foundation Server, consultez Utilisation du contrôle de version.

Comment votre équipe gère-t-elle le code tout en introduisant simultanément plusieurs modifications dans plusieurs versions du projet ?

Lorsque vous travaillez avec un système de contrôle de version, vous devez réfléchir à la façon dont vous souhaitez installer une structure de branche. Vous pouvez créer une branche en mettant en miroir le fichier de code source. Vous pouvez ensuite modifier la branche sans affecter la source. Par exemple, comme le montre la structure de branche de l'illustration suivante, la branche principale (MAIN) contient des fonctionnalités terminées qui ont réussi les tests d'intégration, tandis que la branche de développement (DEVELOPMENT) contient le code en cours de construction. Lorsqu'une nouvelle fonctionnalité de la branche DEVELOPMENT est terminée et peut réussir les tests d'intégration, vous pouvez faire passer le code de la branche DEVELOPMENT à la branche MAIN. Ce processus est connu sous le nom d'intégration inverse. Inversement, si vous fusionnez le code de la branche MAIN vers la branche DEVELOPMENT, le processus est connu sous le nom d'intégration en aval.

Pour plus d'informations sur la création et la fusion de branches de code, consultez la page suivante du site Web CodePlex : Team Foundation Server Branching Guide 2.0.

La création de branche et la fusion impliquent les principes suivants :

1. Chaque branche doit avoir une stratégie définie à propos de l'intégration du code dans cette branche. Par exemple, dans la structure de branche de l'illustration précédente, vous pouvez assigner un membre de l'équipe qui possède et gère la branche principale (MAIN). Ce membre est chargé de l'exécution de l'opération de branche initiale, de l'intégration inverse des modifications de la branche de développement (DEVELOPMENT) vers la branche principale (MAIN) et de l'intégration en aval des modifications de la branche MAIN vers la branche DEVELOPMENT. L'intégration en aval est importante lorsque la branche MAIN intègre également des modifications d'autres branches.

2. La branche MAIN doit contenir le code qui a réussi les tests d'intégration afin qu'il soit toujours prêt pour la création d'une version.

3. La branche de développement (ou travail) évolue constamment car les membres de l'équipe archivent régulièrement des modifications.

4. Les étiquettes sont des instantanés des fichiers dans une branche à un moment donné.

   Pour plus d'informations, consultez Utiliser des étiquettes pour prendre un instantané de vos fichiers.

Team Foundation Build vous permet de choisir entre plusieurs types de builds pour vos branches : manuelle, en continu, contrôlée, enchaînée et planifiée. Nous recommandons le type de build d'archivage contrôlé pour la branche principale (MAIN). Cela signifie que la branche DEVELOPMENT doit satisfaire toutes les exigences de la branche MAIN pour permettre la validation d'une intégration inverse. La branche DEVELOPMENT doit exécuter un type de build continu, car votre équipe doit être avertie dès que possible lorsqu'un nouvel archivage affecte la branche DEVELOPMENT.

À quelle fréquence votre équipe doit-elle procéder à une intégration inverse et à une intégration en aval ?

Comme indiqué dans l'illustration suivante, l'intégration inverse et l'intégration en aval doivent au minimum être effectuées lorsqu'un récit utilisateur est terminé. Bien que chaque équipe puisse définir la fin d'un processus de façon différente, la fin d'un récit utilisateur implique en général que vous ayez effectué à la fois les fonctionnalités et les tests unitaires correspondants. Vous pouvez effectuer l'intégration inverse vers la branche MAIN uniquement après que les tests unitaires ont vérifié la stabilité de la branche DEVELOPMENT.

Si vous avez plusieurs branches de travail (DEVELOPMENT), l'intégration en aval doit être effectuée dans toutes les branches de travail dès qu'une branche est intégrée dans la branche MAIN. Étant donné que la branche MAIN reste stable, l'intégration en aval est sécurisée. Des conflits ou échecs peuvent survenir au niveau des branches de travail car vous ne pouvez pas garantir leur stabilité.

Il est important que vous résolviez tous les conflits dès que possible. Le fait d'utiliser un archivage contrôlé pour la branche MAIN facilite considérablement l'intégration inverse, car les contrôles de qualité peuvent permettre d'éviter des conflits ou des erreurs sur la branche MAIN. Pour plus d'informations, consultez Archiver des modifications en attente contrôlées par une build d'archivage contrôlé.

Comment votre équipe gère-t-elle les sources qui implémentent des récits utilisateur différents ?

Comme le montre l'illustration suivante, vous pouvez régulièrement archiver les modifications d'une branche de travail pour compléter un récit utilisateur. Vous pouvez implémenter plusieurs récits utilisateur dans la même branche en même temps. Toutefois, vous ne pouvez effectuer une intégration inverse dans la branche principale (MAIN) que lorsque vous terminez tout le travail en cours. Il est recommandé de regrouper les récits utilisateur en fonction de leur taille pour éviter qu'un grand récit utilisateur ne bloque l'intégration de nombreux petits. Vous pouvez fractionner les deux ensembles de récits utilisateur en deux branches.

À quel moment l'équipe doit-elle ajouter une branche ?

Vous devez créer des branches dans les situations suivantes :

• Lorsque vous devez diffuser du code sur une planification/un cycle différent des branches existantes.

• Lorsque votre code requiert une stratégie de branche différente. Si vous créez une nouvelle branche avec la nouvelle stratégie, vous pouvez ajouter une valeur stratégique à votre projet.

• Lorsque des fonctionnalités sont publiées à l'intention d'un client et que votre équipe prévoit d'apporter des modifications qui n'affectent pas le cycle de publication planifié.

Vous ne devez pas créer de branche pour chaque récit utilisateur car cela génère des coûts élevés d'intégration. Bien que Team Foundation Server 2010 facilite la création de branche, la charge de gestion des branches peut devenir importante en cas de branches nombreuses.

Comment l'équipe gère-t-elle les versions finales du point de vue du contrôle de version ?

Votre équipe doit être en mesure de diffuser du code à la fin de chaque sprint. Grâce à Team Foundation Server, vous pouvez étiqueter une branche pour effectuer un instantané du code à un moment précis dans le temps. Comme le montre l'illustration suivante, vous pouvez étiqueter la branche principale (MAIN) pour une version. Cela vous permet de rendre à la branche son état à ce stade précis.

Étant donné que vous devez implémenter des mises à jour sur des versions, la création d'une branche pour une version permet à l'équipe de continuer de travailler indépendamment sur le sprint suivant sans générer de conflits avec les versions à venir. L'illustration suivante montre une branche qui contient le code pour une mise à jour, puis fait l'objet d'une intégration inverse dans la branche MAIN après la version créée à la fin du deuxième sprint.

Lorsque vous créez une branche pour une version, vous devez la créer à partir de la branche MAIN, car il s'agit de la branche la plus stable. Si vous créez une branche pour une version à partir d'une branche de travail, vous risquez de rencontrer des difficultés d'intégration, car la stabilité des branches de travail n'est pas garantie.