La réponse dépend de la taille de votre équipe, de la qualité de votre contrôle de source et de votre capacité à fusionner correctement des ensembles de modifications complexes. Par exemple, dans le cas d'un contrôle de source à branche complète comme CVS ou SVN, la fusion peut être difficile et il est préférable d'opter pour le premier modèle, tandis que si vous utilisez un système plus complexe comme IBM ClearCase et une équipe plus importante, il est préférable d'opter pour le deuxième modèle ou une combinaison des deux.
Personnellement, j'opterais pour le modèle des branches de fonctionnalités, où chaque fonctionnalité majeure est développée sur une branche distincte, avec des sous-branches de tâches pour chaque changement effectué par un développeur individuel. Au fur et à mesure que les fonctionnalités se stabilisent, elles sont fusionnées dans le tronc, que vous maintenez raisonnablement stable et qui passe tous les tests de régression à tout moment. Lorsque vous approchez de la fin de votre cycle de publication et que toutes les branches de fonctionnalités fusionnent, vous stabilisez et créez une branche de système de publication sur laquelle vous ne corrigez que les bogues de stabilité et les rétroportages nécessaires, tandis que le tronc est utilisé pour le développement de la prochaine publication et que vous vous séparez à nouveau pour les nouvelles branches de fonctionnalités. Et ainsi de suite.
De cette façon, le tronc contient toujours le code le plus récent, mais vous parvenez à le garder raisonnablement stable, en créant des étiquettes stables (tags) sur les changements majeurs et les fusions de fonctionnalités, les branches de fonctionnalités sont des développements rapides avec intégration continue et les sous-branches de tâches individuelles peuvent être souvent rafraîchies à partir de la branche de fonctionnalités pour que tout le monde travaille sur la même fonctionnalité en synchronisation, tout en n'affectant pas les autres équipes travaillant sur des fonctionnalités différentes.
En même temps, vous disposez, à travers l'historique, d'un ensemble de branches de publication, où vous pouvez fournir des rétroportages, un support et des corrections de bogues à vos clients qui, pour une raison quelconque, restent sur des versions antérieures de votre produit ou même sur la dernière version publiée. Comme pour le tronc, vous ne configurez pas l'intégration continue sur les branches de publication, elles sont soigneusement intégrées après avoir passé tous les tests de régression et autres contrôles de qualité de la publication.
Si, pour une raison quelconque, deux fonctionnalités sont co-dépendantes et nécessitent des modifications mutuelles, vous pouvez envisager de développer les deux sur la même branche de fonctionnalité ou d'exiger des fonctionnalités qu'elles fusionnent régulièrement les parties stables du code vers le tronc et qu'elles rafraîchissent ensuite les modifications du tronc pour échanger du code entre les branches du tronc. Ou si vous avez besoin d'isoler ces deux fonctionnalités des autres, vous pouvez créer une branche commune à partir de laquelle vous ramifiez ces branches de fonctionnalités et que vous pouvez utiliser pour échanger du code entre les fonctionnalités.
Le modèle ci-dessus n'a pas beaucoup de sens avec des équipes de moins de 50 développeurs et un système de contrôle de source sans branches éparses et sans capacité de fusion appropriée comme CVS ou SVN, ce qui ferait de ce modèle un cauchemar à configurer, gérer et intégrer.
2 votes
Remarque : certains diront que même si de nouvelles fonctionnalités sont ajoutées, tout devrait toujours être stable. D'un autre côté, c'est peut-être un peu idéaliste.