GitFlow: fusionner pour maîtriser d'abord ou après la sortie de prod?
Apprendre GitFlow et moi avons des inquiétudes que je ne vois pas abordées dans aucun des documents/articles que j'ai lus à ce sujet.
À un moment donné, le code de la branche develop doit être déployé dans un environnement d'assurance qualité/de transfert et testé rigoureusement. Ainsi, avec GitFlow, vous coupez une branche release de develop, puis vous déployez release dans ledit environnement de transfert.
Tout d'abord, je voulais simplement clarifier quelque chose de très rapide: la toute première fois qu'un projet/référentiel particulier passe par ce processus, vous allez réellement créer/créer cette nouvelle branche release à partir de develop, - oui? Et que toutes les autres fois dans le futur, vous fusionnez simplement develop en release, oui?
Ainsi, QA teste la branche release sur l'env intermédiaire, tout semble bien, et nous sommes prêts à déployer vers prod. Le faites vous:
- Déployer vers prod et puis fusionner
releasedansmaster? ; o - Fusionner
releaseenmasteret puis déployer vers prod?
Je demande parce qu'il semble que dans le premier cas, vous auriez besoin de déployer la branche release vers prod, puis de déployer vers prod, et puis fusionnez vers master. Ce qui semble correct, mais souvent les environnements prod et non prod ne sont pas identiques et le code qui fonctionne parfaitement dans la mise en scène s'étouffe dès qu'il se déclenche sur les serveurs prod. Je sais que GitFlow prend en charge les concepts de branches de correctifs mais ils sont réservés aux corrections mineures. Dans le cas d'un correctif compliqué qui nécessite une version rollback/backout, nous avons maintenant "code sale" (code qui casse prod pour une raison quelconque) fusionné dans master.
Et dans ce dernier cas, cela peut prendre des heures, voire des jours (en particulier si vous devez impliquer des IT/Ops pour effectuer des déploiements de prod) à partir du moment où vous fusionnez et placez la demande de version de prod dans, jusqu'au moment où le déploiement de prod se produit réellement . Et pendant ce temps, vous avez une branche master qui dit "les fonctionnalités X, Y et Z sont en prod" mais elles ne le sont pas.
Je me demande si GitFlow résout ce problème d'une manière ou d'une autre ou quelles sont les solutions de contournement connues dans les deux cas.
La branche de publication que vous créez est de courte durée, semblable aux branches de fonctionnalités que vous créez. Une fois la publication terminée, vous supprimez la branche. Par exemple, je créerais un release/0.1.0 branche, effectuez le travail, puis fusionnez.
Lors du déploiement en production, je récupère toujours le code de la branche principale, ce qui signifie que je fusionne d'abord la branche de publication en maître, avant le déploiement.
GitFlow consiste davantage à avancer, pas à reculer. Par conséquent, pourquoi les correctifs sont utilisés pour créer des correctifs pour les problèmes identifiés.
En termes de temps pris pour entrer dans la production, ce n'est vraiment pas une préoccupation de GitFlow, et je ne pense pas que cela apportera beaucoup d'aide dans ce domaine. Ce serait un problème pour vous quelle que soit la stratégie de branchement que vous utilisez.
Le projet dans lequel je travaille est très chaotique, les décisions changent en minutes, donc ma stratégie est pour tergiverser autant que possible les décisions de gestion de la configuration logicielle.
En particulier, fusionner en master: nous ne fusionnons en master qu'après notre déploiement en production et nous avons un e-mail de confirmation que les tests de fumée ont fonctionné fine. De cette façon, nous embrassons le chaos en gérant le risque de changements de décision, de retours en arrière dans le déploiement, de problèmes techniques ou de tout problème pouvant survenir.
Au début, nous avons fusionné en master avant de passer en production, mais des problèmes techniques, des retours en arrière, des décisions de gestion à la toute dernière minute ... nous ont causé beaucoup de problèmes, nous avons donc changé de stratégie, et cela a bien fonctionné au cours des 3 derniers. années.
Si, finalement, après la mise en production, une régression est trouvée, c'est un correctif et doit être géré comme ça :)
Vous allez réellement créer/créer cette nouvelle branche de version à partir de develop, oui?
C'est exact. La première fois, votre seule option consiste à créer la branche release à partir de votre branche principale, et c'est ce que vous déploierez pour QA/Staging, puis pour Production.
Et que toutes les autres fois à l'avenir, vous fusionnez simplement le développement en version, oui?
Ça dépend. Selon la description de Git Flow, la branche de publication est de courte durée . Il peut dériver de develop uniquement et fusionné dans master. En théorie, release devrait être réintégré dans develop une fois votre version terminée, puis supprimé . La seule chose que vous devriez fusionner dans la version est hotfix. C'est un joli nettoyage article sur le débit.
Cela varie d'une équipe à l'autre. J'ai travaillé sur des équipes qui suivent exactement la description de GitFlow, et d'autres qui choisissent de simplement supprimer release et de le recréer depuis develop comme si c'était la première fois.
Déployer sur prod puis fusionner la version dans master ?; ou fusionner la version à maîtriser puis déployer vers prod?
En théorie, le maître devrait toujours contenir du code prêt pour la production, et le seul moyen de garantir que ce qui est déployé en production est exactement ce qui se trouve dans la branche principale. Cela dit, nous ne pouvons probablement pas vous donner de réponses parfaites sur ce qui fonctionne pour votre équipe en particulier.
Par exemple, je travaille actuellement sur une équipe avec un pipeline CI/CD qui ne nous laisse pas d'autre choix que de fusionner avant: le déploiement se fait automatiquement à partir de master. J'ai vu des équipes où les versions sont trop éloignées, et je me sens plus confiant en déployant la branche release à la place et en fusionnant par la suite. Cela évite de déployer une erreur humaine faite lors de la fusion release -> master (qui inclut probablement des conflits désagréables construits au fil du temps).
Je pense que vous devez choisir la solution qui vous convient le mieux, car le GitFlow peut ne pas couvrir tous les scénarios et contextes possibles.