Stratégie Gitflow pour les versions multiples d'un projet

Question

Je suis en train de concevoir une stratégie de branchement et de fusion pour mon projet (nous utilisons TFS). Le projet prévoit d'avoir plusieurs versions publiées. Actuellement, nous testons la v1.0alpha et travaillons sur la v2.0.

Le plan est le suivant :

• Après le feu vert imminent des testeurs, version v1.0 sera libéré pour un client.
• Version v1.1 (déjà en cours de développement) sera déployé auprès de 5-6 clients.
• Version v1.2 serait installé sur des dizaines de clients.
• etc.

Nous essaierons de forcer la mise à niveau des anciens clients vers les versions les plus récentes, mais en raison de la nature du projet et du marché, il peut s'écouler des mois (années ?) avant que les clients ne soient mis à niveau.

Nous voulons utiliser le gitflow standard mais cela semble plus approprié pour avoir une seule version. J'ai conçu une simplification de gitflow :

L'approche est la suivante :

• Si un client souhaite qu'un bogue soit corrigé, nous le ferons dans la branche Release de sa version et il devra passer à la dernière révision de sa version. Par exemple, un client de la version 1.0 qui a un bogue doit passer à la version 1.0.5. Si le bogue se produit dans d'autres versions, nous le corrigerons dans celles-ci.
• Si le client veut un nouvelle fonction nous le développerons dans la dernière version et les obligerons à faire une mise à niveau s'ils le souhaitent. Par exemple, les clients de la version 1.0.5 qui veulent la nouvelle version devront passer à la version 1.2.
• Si tous les clients d'une version donnée sont mis à jour, nous supprimons cette branche de la version. Par exemple, lorsque le client de la v1.0 sera mis à jour, nous supprimerons la branche de la version v1.0.

Mes questions, par ordre d'importance, sont donc les suivantes :

1. Mon approche fonctionnera-t-elle ? Voyez-vous des problèmes ?
2. Est-ce que git-flow a un modèle pour ce "scénario de versions multiples" ?
3. Gitflow a une branche Master. Est-il acceptable de ne pas avoir de branche Master ? Pourrions-nous considérer les différentes branches de la version comme "Master" ?
4. Comment allez-vous nommer les branches de Dev et de Releases ?

Answer 1

1. Votre approche devrait fonctionner. Il n'y a rien de magique dans GitFlow, et des variations répondant à vos besoins sont acceptables. Git lui-même n'a aucun problème avec un flux de travail différent. Un bon exemple est le flux Github, jetez un coup d'œil à http://scottchacon.com/2011/08/31/github-flow.html .

Quelques éléments que vous pourriez envisager :

a) "Principe de la moindre surprise" : Essayez de rester aussi proche que possible d'une norme. Cela signifie que vous i) dirigez les développeurs vers la documentation disponible sur le web au lieu de tout écrire ii) rendez plus facile pour les nouveaux développeurs d'entrer ou simplement de travailler avec vos projets. Ainsi, vous devriez conserver la branche master, non pas parce qu'elle est nécessaire - elle ne l'est pas, mais parce qu'elle pourrait perturber les gens lorsqu'elle n'est pas là, et vous auriez à l'expliquer pendant des années. Les branches dans git sont "juste" des noms (enfin, un peu plus, mais vous voyez ce que je veux dire), donc la seule raison de les nommer de la même façon est la convention - rendre les choses plus faciles pour les gens.

b) Combien de développeurs travaillent sur les projets ? S'ils sont nombreux, vous pouvez considérer la branche Dev comme une branche d'intégration, et utiliser la branche master comme branche stable. Avoir une branche de développement que vous autorisez à être instable pourrait résoudre de nombreux problèmes avec de nombreux développeurs. Deux équipes s'engagent, l'une à partir d'une fonctionnalité et l'autre à partir d'un correctif, le build devient rouge, les équipes se rejettent la faute, la troisième équipe essaie de sortir une nouvelle branche de release, mais n'y arrive pas. Disposer d'une branche maîtresse stable, toujours verte, que l'on peut même protéger avec des pull requests, est très agréable et permet de créer un environnement plus détendu.

2) Gitflow de base est centré sur une version, donc pas tout à fait. Vous avez plusieurs versions en même temps. Vous y êtes donc presque, mais les outils standard, comme ceux de [Jakob Ehn] ( https://github.com/jakobehn ) Extension de Gitflow à Visual Studio - qui est super génial - vous obligera à essayer de fermer une version avant d'être autorisé à en ouvrir une nouvelle. Demandez à Jakob d'assouplir cela, et l'outil fonctionnera pour vous. Sinon, suivez simplement la convention, mais faites-le manuellement - cela fonctionne aussi.

3) Voir le point 1 ci-dessus sur le maître et pourquoi ce n'est pas une bonne idée de ne pas l'avoir. Mais bien sûr, vous pouvez considérer les branches de publication comme des sortes de maîtres, mais ils ne se comportent pas vraiment de cette façon dans votre description. Et si c'est le cas, lequel est le vrai maître, celui à partir duquel vous créez des branches de fonctionnalités et celui que vous considérez comme le plus récent ? Le fait d'avoir un master stable résout beaucoup de questions qui se posent sans.

4) Dev ou Develop, alors les fonctionnalités devraient avoir un nom de la fonctionnalité aussi proche de ce qu'elle fait que possible, comme Dev/NewHelpPage, ou Feature/NewHelpPage (pour être plus proche de la convention gitflow). Branches de version, il semble que vous suiviez déjà le versioning sémantique ( http://semver.org ), alors pourquoi ne pas l'utiliser : Release/V1.0, Release/V1.1 et ainsi de suite. Une branche hotfix est alors Release/V1.0.1 .
Que la dénomination soit telle que les développeurs comprennent facilement de quoi il s'agit, de préférence sans avoir à demander à qui que ce soit.

Restez simple, suivez les conventions autant que possible, et tout se passera bien. Git lui-même fonctionne pour presque tous les schémas de branchement.

[Edit] J'ai eu une discussion rapide avec Jakob, et il a dit qu'il avait des demandes pour supporter les branches de support, ce qui est probablement ce que vous recherchez vraiment. Il a également indiqué cet excellent poste sur différents scénarios de gitflow, en bas il y a le flux pour les branches de support.