Comment gérer plusieurs branches de version / correctif dans Gitflow?

Question

J'implémente Gitflow dans l'entreprise pour laquelle je travaille actuellement et tout se passe plutôt bien. Je ne suis tout simplement pas tout à fait sûr que je traite plus d'une version sur le pipeline en même temps de la meilleure façon

Nos systèmes ont 5 environnements comme suit:

• Développer: déployé chaque fois qu'il y a une fusion avec develop. Utilisé pour intégrer d'autres systèmes au moment du développement
• Test interne: déployé chaque fois qu'une nouvelle branche de version est créée à partir de develop. Utilisé par l'équipe QA
• Test externe: déployé après que l'équipe QA donne son accord. Utilisé pour que les utilisateurs clés du système jettent un œil et apprennent ce qui a été fait.
• Production: déployé chaque fois que quelque chose est fusionné dans master
• Miroir: déployé chaque fois que quelque chose est fusionné dans master. Celui-ci est une copie conforme de la production pour nous aider à déboguer les bogues de production de manière sûre. Fondamentalement, un bac à sable avec le même code que la production et la base de données de production de la veille (sauf pour certaines données sensibles brouillées)

Le problème que je veux résoudre: alors que la version 1.0.0 est testée par des tests externes, je peux déjà livrer une nouvelle version 1.1.0 dans les tests internes. Mais si les tests externes trouvent quelque chose qui doit être changé dans la version 1.0.0, cela devrait être appliqué de manière récursive jusqu'au développement, où nous travaillons déjà sur la version 1.2.0.

Ce que nous faisons aujourd'hui, c'est fusionner 1.0.0 dans 1.1.0 et développer après ces changements et le renvoyer au test interne, en interrompant les tests sur 1.1.0 dans l'intervalle.

Même idée pour les correctifs. Je peux avoir 1.0.0 en production et avoir 1.1.0 en cours de test. Mais tout à coup, je dois corriger un bogue de production, donc je crée une branche de correctif à partir de master qui générera la version 1.0.1. Aujourd'hui, nous fusionnons cela dans 1.1.0, développons et maîtrisons.

Est-ce que tout cela a du sens?

Y a-t-il une meilleure façon de gérer cela?

Merci

Éditer:

L' article original sur Gitflow a déjà une solution pour le problème du correctif:

[...] lorsqu'une branche de version existe actuellement, les modifications du correctif doivent être fusionnées dans cette branche de version, au lieu d'être développées. La rétro-fusion du correctif de bogue dans la branche de publication entraînera finalement la fusion du correctif de bogue dans develop, lorsque la branche de publication sera terminée. (Si le travail en développement nécessite immédiatement cette correction de bogue et ne peut pas attendre que la branche de publication soit terminée, vous pouvez déjà fusionner le correctif de bogue avec develop maintenant.)

Answer 1

Le processus que vous avez décrit est logique, en particulier s'il est assez rare que vous ayez plusieurs branches de version active et / ou de correctif en même temps.

Pour garder la fusion contrôlée, vous pouvez convenir que les corrections de bogues sur une branche de version (ou hotfix) ne sont fusionnées avec d'autres branches de version qu'une fois que QA a donné son accord pour un test externe sur cette branche.

Selon Gitlow, la fusion pour développer devrait se produire en même temps que la fusion pour master, à moins qu'il n'y ait des raisons pressantes pour lesquelles le correctif est nécessaire plus tôt lors du développement. Vous pouvez choisir de faire la fusion pour développer également au moment où la branche de publication est mise à disposition pour des tests externes.

Answer 2

On dirait que vous travaillez sur une application Web, ou quelque chose de similaire dans le sens où une seule version est généralement utilisée à la fois - quelle que soit la dernière mise en production. Compte tenu de cela, je suggérerais que Git Flow ne convient probablement pas. Comme l' écrit Vincent Driessen, qui a décrit Git Flow à l'origine :

... Les applications Web sont généralement livrées en continu, non restaurées, et vous n'avez pas à prendre en charge plusieurs versions du logiciel s'exécutant à l'état sauvage.

Ce n'est pas la classe de logiciels que j'avais en tête lorsque j'ai écrit le billet de blog il y a 10 ans. Si votre équipe fournit des logiciels en continu, je suggérerais d'adopter un flux de travail beaucoup plus simple (comme le flux GitHub) au lieu d'essayer de faire du git-flow dans votre équipe.

Ma suggestion serait de rechercher plutôt une forme de développement basé sur le tronc .