Sélectionner une stratégie de branchement efficace

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

La création de branches pour vos référentiels TEAM Foundation Version Control (TFVC) est utile pour isoler les risques. Considérez les difficultés que rencontrent généralement les membres d'une équipe composée de plus de cinq ou dix personnes travaillant sur un projet de logiciel :

• Le groupe se compose de quelques équipes de fonctionnalité, chacune travaillant sur un jeu de fonctionnalités raisonnablement discret. Mais chaque équipe dépend également des fonctionnalités générées par les autres équipes. Vous devez isoler les risques liés aux modifications introduites par chacune de ces équipes, même si au final, vous devrez fusionner le fruit de leurs efforts dans un seul et même produit.

• L’équipe de test a besoin d’une version stable du code pour conduire des tests, mais en parallèle, les développeurs doivent continuer à faire progresser les nouvelles fonctionnalités qui peuvent parfois déstabiliser le produit.

• Le logiciel dispose de deux versions antérieures et d'une version actuelle. Bien que la majorité de l'effort de développement soit concentré sur la version actuelle, les versions antérieures doivent encore être prises en charge par le biais de la diffusion occasionnelle de Service Packs, de correctifs critiques, de mises à jour de sécurité et d'autres modifications.

Cet article explore quelques stratégies courantes de branchement pour vous aider à prendre la bonne décision.

Contrairement aux branches Git, qui sont délimitées par le référentiel, les branches TFVC sont délimitées par le chemin d’accès et ne sont pas aussi légères. Définissez votre barre pour créer des branches élevées et uniquement lorsque vous avez besoin d’un code ou d’une isolation de mise en production.

Principal uniquement

La stratégie Principal uniquement peut être basée sur des dossiers ou avec le dossier principal converti en branchepour activer des fonctionnalités de visibilité supplémentaires. Vous validez vos modifications dans la branche principale et indiquez éventuellement des jalons de développement et de mise en production avec des étiquettes.

RISQUE : la mutabilité et l’absence d’historique avec les étiquettes TFVC peuvent ajouter un risque de contrôle des modifications.

Commencez par la stratégie de branchement Principale uniquement, branchez stratégiquement et adoptez d’autres stratégies pour évoluer en stratégies plus complexes si nécessaire.

Isolation du développement

Lorsque vous devez maintenir et protéger une branche principale stable, vous pouvez brancher une ou plusieurs branches de développement à partir de la branche principale . Cela permet l’isolation et le développement simultané. Le travail peut être isolé dans les branches de développement par fonctionnalité, organisation ou collaboration temporaire.

Il est possible qu’il y ait des changements dans la branche principale. Faites toujours l’intégration avancée (FI) principale à la branche de développement et résolvez les conflits de fusion. Ensuite, l’intégration avancée (RI) revient à principale. Maintenez la même barre de qualité entre les branches. Générez et exécutez des tests de vérification de build (BVT) sur développement de la même façon que vous l’effectuez sur principale.

REMARQUE : Avec cette stratégie, les équipes sont susceptibles de conserver la branche de développement à jamais, ce qui peut entraîner la création d’un grand historique des tickets de fusion.

Isolation des fonctionnalités

L’isolation des fonctionnalités est une dérivation spéciale de l’isolation de développement, ce qui vous permet de brancher une ou plusieurs branches de fonctionnalités à partir des branches principales, comme indiqué ou de vos branches de développement.

Lorsque vous devez travailler sur une fonctionnalité particulière, il peut être judicieux de créer une branche de fonctionnalité.

Conservez la durée de vie des fonctionnalités et la branche de fonctionnalité associée à courte durée de vie. L’intégration avancée change fréquemment de la branche parente. L’intégration inversée revient au parent uniquement lorsque certains critères d’équipe convenus, par exemple la définition de terminé, sont remplis. La restauration des fonctionnalités sur principale peut être coûteuse et peut réinitialiser les tests.

Isolation des mises en production

L’isolation des mises en production introduit une ou plusieurs branches de mise en production à partir de principale. La stratégie permet la gestion simultanée des mises en production, les mises en production multiples et parallèles et les captures instantanées codebase au moment de la publication.

Lorsque la version est prête à être verrouillée, il est temps de créer une branche pour la mise en production.

Ne jamais faire l’intégration avancée à partir de principale. Verrouillez les branches de mise en production à l’aide des autorisations d’accès pour empêcher les modifications involontaires apportées à une version. Les correctifs et correctifs logiciels apportés à la branche de mise en production peuvent être intégrés de façon inversée à la branche principale.

REMARQUE : Aucun des scénarios de branchement n’est immuable, c’est pourquoi vous remarquez des correctifs logiciels d’urgence effectués sur les branches de mise en production. Faites évoluer chaque stratégie pour répondre à vos besoins, sans perdre de vue la complexité et les coûts associés.

Isolation de maintenance et de mise en production

La stratégie d’isolation de maintenance et de mise en production introduit des branches de maintenance. Cette stratégie permet la gestion simultanée des service packs et des instantanés codebase au moment de la mise en production.

Utilisez cette stratégie si vous avez besoin d’un modèle de maintenance pour que les clients effectuent une mise à niveau vers la prochaine version majeure et d’autres Service Packs par version.

Comme l’isolation de mise en production, l’isolation de maintenance et les branches de mise en production sont créées lorsque la version est prête à être verrouillée. Ne transférez jamais l’intégration du principal au maintenance, ou de la maintenance à la mise en production. Verrouillez la branche de mise en production pour empêcher les modifications. Les futures modifications de maintenance peuvent être effectuées sur la branche de maintenance.

Créez de nouvelles branches de maintenance et de mise en production pour les versions ultérieures si vous avez besoin de ce niveau d’isolation.

Maintenance, correctif logiciel, isolation des mises en production

Bien que ce ne soit pas recommandé, vous pouvez continuer à développer les stratégies en introduisant des branches de correctif logiciel supplémentaires et des scénarios de mise en production associés.

À ce stade, vous avez exploré avec succès quelques-uns des scénarios courants de branchement TFVC. Vous pouvez les faire évoluer ou examiner d’autres stratégies telles que le basculement des fonctionnalités, l’activation et la désactivation du basculement des fonctionnalités pour déterminer si une fonctionnalité est disponible au moment de l’exécution.

Questions et réponses

Pourquoi les branches devraient-ils être de courte durée ?

En conservant les branches à courte durée, les conflits de fusion sont conservés le plus peu possible.

Pourquoi uniquement une branche si nécessaire ?

Pour adopter DevOps, vous devez vous appuyer sur l’automatisation de la génération, du test et du déploiement. Le changement est continu, fréquent et les opérations de fusion sont plus difficiles, car les conflits de fusion nécessitent souvent une intervention manuelle. Il est donc recommandé d’éviter le branchement et de s’appuyer sur d’autres stratégies, telles que le basculement des fonctionnalités.

Pourquoi supprimer des branches ?

Votre objectif doit être de ramener les modifications en principale dès que possible, afin d’atténuer les conséquences de fusion à long terme. Les branches temporaires, inutilisées et abondantes provoquent une confusion et une surcharge pour l’équipe.

Un codebase peut-il être mis en branche entre les projets ?

Oui. Il n’est pas recommandé, sauf si les équipes doivent partager la source et ne peuvent pas partager un processus commun.

Qu’en est-il de la stratégie de promotion du code ?

La stratégie de promotion du code semble être une relique de l’ère du développement en cascade. Il s’agit généralement de cycles de test longs et d’équipes de développement et de test distinctes. La stratégie n’est plus recommandée. Pour plus d’informations sur cette stratégie, consultez les instructions de branchement.

Lors de la fusion du développement vers la branche principale, pourquoi aucune modification n’est-elle détectée ?

Vous avez probablement ignoré les modifications apportées aux fusions précédentes, par exemple à l’aide de l’option de résolution de conflit keep source. Consultez la fusion de la branche de développement vers la branche principale : aucune modification n’a été apportée à la fusion pour plus d’informations.

Existe-t-il des similitudes entre TFVC et les stratégies de branche Git ?

La stratégie de branchement d’isolation des fonctionnalités TFVC est similaire aux branches de rubrique Git.

Auteurs : Jesse Houwing, Marcus Fernandez, Mike Fourie et Willy Schaub de l’ALM | DevOps Rangers. Vous pouvez les contacter ici.

(c) 2015 Microsoft Corporation. Tous droits réservés. Ce document est fourni « comme tel ». Les informations et opinions exprimées dans ce document, y compris les URL et autres références à des sites Internet Web, peuvent changer sans préavis. Vous assumez les risques liés à leur utilisation.

Ce document ne vous fournit aucun droit légal de propriété intellectuelle de tout produit Microsoft. Vous pouvez copier et utiliser ce document pour votre information uniquement.