Quelle est la meilleure façon de gérer la gestion des versions des produits et le branchement des projets à long terme?

D'une manière générale, pour les projets à long terme qui peuvent avoir plusieurs versions au cours du cycle de vie des produits et nécessiter la prise en charge des produits précédents, quelle est la meilleure façon de gérer les versions des produits et la ramification de la base de code?

Dans un sens plus spécifique, supposez qu'un contrôle de version distribué approprié est en place (c'est-à-dire git) et que les équipes sont de petite à grande taille et que le développeur peut travailler sur plusieurs projets à la fois. Le problème majeur auquel nous sommes confrontés est qu'il existe une obligation contractuelle de prendre en charge les anciennes versions telles qu'elles existaient à l'époque, ce qui signifie que les nouveaux développements ne peuvent pas corriger l'ancien code (les produits Microsoft Office pourraient en être un exemple, vous n'obtenez que des correctifs pour l'année de référence que vous possédez).

Par conséquent, la version actuelle du produit est un peu compliquée car chaque produit principal a plusieurs dépendances, chacune avec ses propres versions qui peuvent changer entre les versions annuelles. De même, alors que chaque produit a son propre référentiel, la plupart du travail n'est pas effectué sur le tronc source principal, mais plutôt sur une branche pour la même année, la version du produit avec une nouvelle branche étant créée lorsque le produit est publié afin qu'il puisse être pris en charge. Cela signifie à son tour qu'obtenir la base de code d'un produit n'est pas une question simple comme on pourrait le penser lors de l'utilisation du contrôle de version.

La quantité (et le type) de structure dont vous avez besoin dépend beaucoup de ce que vous voulez pouvoir faire. Découvrez ce dont vous ne pouvez pas vous passer, ce que vous voulez avoir et ce qui vous importe peu.

Un bon exemple d'ensemble de décisions pourrait être:

Des choses dont nous ne pouvons pas nous passer:

• être capable de reconstruire n'importe quelle version passée à tout moment
• pouvoir gérer à tout moment plusieurs versions principales prises en charge du produit

Ce que nous aimerions avoir:

• être en mesure d'effectuer le développement de fonctionnalités majeures en cours (pour la prochaine version majeure) sans se soucier des fusions de succursales
• pouvoir effectuer des mises à jour de maintenance des versions précédentes

Des choses sans lesquelles nous pouvons vivre:

• rétroportage automatisé des modifications du travail en cours vers les versions précédentes
• n'interrompez jamais le développement de fonctionnalités majeures même pendant quelques jours ou une semaine à la fois

Si ce qui précède était vos objectifs, vous pourriez alors adopter un processus comme celui-ci:

1. Faites tout le travail de développement sur le tronc de votre VCS ("master" dans git)
2. Lorsque vous êtes proche d'une version majeure, arrêtez le développement des fonctionnalités principales et concentrez-vous sur la stabilité du système pendant environ une semaine
3. Lorsque le tronc semble stable, créez une branche pour cette version majeure
4. Le développement de fonctionnalités majeures peut désormais se poursuivre sur le tronc, alors que seules les corrections de bugs et la préparation des versions sont autorisées sur la branche
5. Cependant, toutes les corrections de bogues à apporter à la branche doivent d'abord être testées sur le tronc; cela garantit qu'ils seront également présents dans toutes les futures versions
6. Créez une balise (VCS) sur la branche lorsque vous êtes prêt à publier; cette balise peut être utilisée pour recréer la version à tout moment, même après un travail ultérieur sur la même branche
7. D'autres versions de maintenance de cette version majeure (versions mineures) peuvent désormais être préparées sur la branche; chacun sera étiqueté avant la sortie
8. En attendant, le développement de fonctionnalités majeures axées sur la prochaine version majeure peut se poursuivre sur le tronc
9. Lorsque vous vous approchez de cette version, répétez les étapes ci-dessus, en créant une nouvelle branche de versions pour cette version . Cela vous permet d'avoir plusieurs versions majeures, chacune sur leur propre branche, dans un état pris en charge en même temps, avec la possibilité de publier des versions mineures distinctes pour chacune.

Ce processus ne répondra pas à toutes vos questions - en particulier, vous aurez besoin d'un processus en place pour décider quels correctifs peuvent être apportés à une branche de publication et pour vous assurer que les bogues ne sont pas corrigés en premier sur une branche de publication (ces correctifs doit toujours être testé sur le tronc si possible). Mais cela vous donnera un cadre dans lequel prendre de telles décisions.

"Long terme" indique que vous avez besoin de versioning, mais il n'implique aucune stratégie de versioning et de branchement spécifique. La question la plus intéressante est le nombre de lignes de produits ou de lignes de versions principales que vous souhaitez prendre en charge (cela dépend du contrat avec vos clients). Vous aurez au moins besoin d'une succursale pour chaque ligne de produits / version principale pour laquelle vous avez un contrat de maintenance.

En revanche, cela dépend de la taille de votre équipe. Si vous avez une grande équipe de développement, avec différentes personnes travaillant sur différentes fonctionnalités en parallèle, vous aurez évidemment besoin de plus de branches de fonctionnalités que si vous avez une équipe d'une ou deux personnes. Si vous travaillez avec une équipe plus importante, vous devriez envisager d'utiliser le contrôle de version distribué, ce qui rend le travail parallèle sur différentes branches (et les réintégrer plus tard dans le tronc) beaucoup plus efficace.

Git est un outil de contrôle de version - il gère les versions des fichiers. Ce que vous recherchez est un outil de gestion de configuration. Il y en a plein de disponibles, mais surtout à des prix élevés de la part d'IBM.

Les outils de contrôle de version fournissent des branchements et des balises, ce qui permet une gestion de configuration grossière sans prise en charge d'outils supplémentaires, les développeurs de menay ne comprennent donc pas la différence. Vos besoins vont probablement au-delà de ce que GIT est conçu pour faire.

Je ne connais pas, mais je suis certain qu'il existera, un ajout d'outil CM pour Git.

Cette question semble être très similaire à une autre question à laquelle j'ai répondu récemment.

En bref, cela ressemble plus à un problème de conception et de distribution de produits qu'à un problème de contrôle de version / de branchement. Bien sûr, il est facile pour moi de dire cela et plus difficile à résoudre si vous êtes déjà au fond du problème.

Sans connaître plus en détail les spécificités de votre problème particulier. En général cependant, si j'avais plusieurs versions de produits basées sur une base de code qui avait une grande quantité de code partagé entre les produits, si c'était faisable, je chercherais à refactoriser les produits d'une manière qui les rendrait plus modulaires, et à assurez-vous que les modules eux-mêmes ne nécessitent pas de branchement de code supplémentaire. Je regarderais également mon modèle de déploiement pour voir s'il y avait un meilleur moyen de soutenir mes clients tout en conservant une grande partie de la base de code unifiée. Lorsqu'une personnalisation spécifique du client est requise, une plus grande granularité des modules peut être nécessaire pour réduire la quantité de code dupliqué dans le système.

Ce n'est pas une tâche facile, mais réparable par étapes si vous gérez bien le travail et si vous pouvez planifier le travail de sorte que vous n'ayez pas besoin de «tout mettre à niveau» tout à la fois.