Quelle est la différence entre GitHub Flow et GitLab Flow?
Récemment, j'ai trouvé les trois concepts d'un workflow dans GIT: GitFlow, GitHub Flow et GitLab Flow. J'ai lu l'article de Nice à ce sujet ( https://docs.gitlab.com/ee/workflow/gitlab_flow.html ) mais je ne comprends pas très bien GitLab Flow. Peut-être parce que je ne suis pas natif :)
Brièvement.
GitFlow ( https://docs.gitlab.com/ee/workflow/gitdashflow.png ).
Nous avons une branche maître en tant que branche de production. Nous avons également une branche de développement où chaque développeur fusionne ses fonctionnalités. Parfois, nous créons une branche de publication pour déployer nos fonctionnalités en production. Si nous avons un bug dans la branche release, corrigez-le et introduisez les modifications dans la branche develop. Si nous avons un bug critique en production, créez une nouvelle branche hotfix, corrigez le bug et fusionnez la branche avec la production (master) et développez des branches.
Cette approche est très bien si nous montrons rarement les résultats de notre travail. (Peut-être une fois toutes les 2 semaines).
GitHub Flow ( https://docs.gitlab.com/ee/workflow/github_flow.png ).
Nous avons une branche maître en tant que branche de production. Et nous (en tant que développeurs) ne pouvons que créer des branches pour ajouter de nouvelles fonctionnalités ou corriger des bugs et les fusionner avec la branche de production (maître). Cela semble très simple. Cette approche convient à la programmation extrême où la branche de production est déployée plusieurs fois par jour.
GitLab Flow ( https://docs.gitlab.com/ee/workflow/production_branch.png , https://docs.gitlab.com /ee/workflow/environment_branches.png , https://docs.gitlab.com/ee/workflow/release_branches.png ).
J'ai vu de nouveaux termes comme une pré-production, une production, une branche de publication (stable) et un environnement de transfert, un environnement de pré-production, un environnement de production. Quelles relations entretiennent-ils entre eux?
Je le comprends de cette façon: si nous devons ajouter une nouvelle fonctionnalité, nous déployons une branche de pré-production à partir de la branche principale. Une fois la fonctionnalité terminée, nous déployons une branche de production à partir de la branche de pré-production. Une branche de pré-production est l'étape intermédiaire. Et ensuite, la branche principale extrait tous les changements de la branche de production.
L'approche est bonne si nous voulons voir chaque fonctionnalité distincte. Nous vérifions simplement dans la succursale ce dont nous avons besoin et regardons.
Mais si nous devons montrer notre travail, nous créons une branche de publication avec une balise le plus tard possible. Si plus tard, nous corrigeons des bogues dans la branche principale, nous devons les sélectionner dans la dernière branche de version. À la fin, nous avons la branche de publication avec des balises qui peuvent nous aider à passer d'une version à l'autre.
Ma vision est-elle correcte? Quelle différence entre tirer et cueillir?
GitLab Flow propose d'utiliser également les branches master et feature. Une fois la fonctionnalité terminée, nous la fusionnons à la branche master. Cette partie ressemble à celle de GitHub Flow.
Ensuite, je comprends qu'ils nous donnent 2 options sur la façon de le faire selon qu'il s'agit de l'application SAAS ou de l'application mobile (qui peut être publiée dans le monde).
S'il s'agit de l'application SAAS, nous utilisons des branches d'environnement, par exemple pre-production et production. Ces branches sont créées à partir de master lorsque nous sommes prêts à déployer notre application. Le fait d'avoir différentes branches par environnement nous permet de configurer l'outil CI/CD pour qu'il se déploie automatiquement sur les validations effectuées dans ces branches. S'il y a un problème critique, nous le résolvons dans la branche feature ou master, puis le fusionnons dans les branches environment.
En ce qui concerne les applications qui peuvent être publiées dans le monde (par exemple, les applications mobiles ou de bureau), je crois comprendre qu'elles proposent d'utiliser un modèle différent en utilisant des branches release au lieu de branches d'environnement. Nous travaillons toujours dans les branches feature et les fusionnons à nouveau dans la branche master une fois terminé. Ensuite, lorsque nous nous assurons que la branche master est suffisamment stable, c'est-à-dire que nous avons déjà effectué tous les tests et la correction de bogues, nous créons la branche release et publions notre logiciel. S'il y a un problème critique, nous le résolvons d'abord dans la branche master et choisissons un correctif dans la branche release.
Cela fait maintenant un an que ce message a été publié, mais compte tenu des futurs lecteurs et du fait que les choses ont un peu changé, je pense que cela vaut la peine d'être rafraîchi.
GitHub Flow as décrit à l'origine par Scott Chacon en 2011 supposait chaque changement une fois revu sur un feature branch et fusionné dans master doit être déployé immédiatement en production. Alors que cela fonctionnait à l'époque et était conforme à la seule règle de flux GitHub, qui est tout ce qui se trouve dans la branche principale est déployable, il a été rapidement découvert cela afin de garder master un véritable enregistrement du code de production connu le déploiement réel en production doit se produire à partir du feature branch avant de le fusionner en master. Déploiement à partir du feature branch est parfaitement logique, car dans le cas de tout problème, la production peut être inversée instantanément en y déployant master. Veuillez consulter ne courte introduction visuelle à GitHub Flow.
GitLab Flow est une sorte d'extension de GitHub Flow accompagnée d'un ensemble de directives et meilleures pratiques qui visent à normaliser davantage le processus. Outre la promotion de branches de fonctionnalité et de branche master prêtes à déployer (comme GitHub Flow), il introduit trois autres types de branches:
Productionbranche- branches Environnement :
uat,pre-production,production - Libérer les branches :
1-5-stable,1-6-stable
Je crois que les noms et les exemples ci-dessus sont auto-descriptifs, donc je ne développerai pas davantage.