Le blog de la Forge Zola 2020-12-17T00:00:00+00:00 https://staging.lafor.ge/tags/gitops/atom.xml 2020-12-17T00:00:00+00:00 2020-12-17T00:00:00+00:00 Unknown https://staging.lafor.ge/gitworkflow/ <p align="center"> <img src="https://media.giphy.com/media/cFkiFMDg3iFoI/giphy.gif" alt="la guerre"/> </p> <p>A partir du moment où j’ai dû faire de la programmation à plusieurs ( mes personnalités multiples ça compte pas 🤪 ).</p> <p>Un problème s’est toujours posé: comment ne pas se marcher sur les pieds.</p> <p>Durant ma courte expérience de dev, j’ai déjà tester plusieurs principes tout fait. Je vais vous avouez que je n’ai été convaincu par aucun d’entre eux.</p> <p>Avant de présenter YAGW. Je vais faire un tour d’horizon de ce que je connais pour les avoir essayés.</p> <h2 id="no-flow-yolo-8000-av-jc">No Flow : YOLO ( -8000 av JC )</h2> <p>Tout le monde écrit dans la master et personne ne fait de branche, let’s rock baby !</p> <p><img src="../assets/images/gitworkflow/no-flow.png" alt="" /></p> <p>Il peut y avoir des tags mais c’est pas dit.</p> <h3 id="avantages">Avantages</h3> <ul> <li>Pas de charge mentale</li> <li>Idéal lorsqu’on est seul</li> <li>Très automatisable</li> </ul> <h3 id="desavantages">Désavantages</h3> <ul> <li>C’est mort pour collaborer</li> <li>Tester c’est douter</li> </ul> <p>Bon maintenant qu’on a évacué le troll, passons aux choses sérieuses. 😉</p> <h2 id="gitflow-le-premier-arrive-2010">Gitflow : le premier arrivé (2010)</h2> <p>Quand le développement a commencé à se structurer autours de git. Une méthode appelée <a rel="nofollow noreferrer external" href="https://danielkummer.github.io/git-flow-cheatsheet/index.fr_FR.html">gitflow</a> a vu le jour. Elle se voulait apte à résoudre toutes les problématiques ou presque.</p> <p>Mais comme toujours la flexibilité vient souvent avec son lot de complexités. Et ça n’a pas raté. Gitflow est véritablement une usine à gaz, voyez plutôt:</p> <p><img src="../assets/images/gitworkflow/gitflow_1.png" alt="" /></p> <p>Oui c’est pas évident du tout.</p> <p>Pour expliquer la philosophie: elle part du principe que la branche <code>master</code> ne sert qu’à tagger un historique.</p> <p>Cette <code>master</code> est isolée du reste par des branches éphémères appelées <code>releases</code>.</p> <p>Le coeur de la vie du projet est situé sur la branche <code>develop</code>, celle ci doit <strong>impérativement</strong> contenir <strong>tous</strong> les commits du projet.</p> <p>De cette branche on va dériver tout une série de branches. Celles ci sont appelées des branches de <code>features/X</code>. Elles peuvent n’avoir que 2 fins. Mourrir ou être mergées dans la <code>develop</code>.</p> <p>Lorsque l’on désire créer une release, on va dériver à partir d’un commit de la <code>develop</code> une branche <code>release/X</code>, ce <code>X</code> peut représenter un hash de commit un nom explicite ou une version. 3 destins attend cette branche: mourrir, être remergé dans la <code>develop</code> après modifications. Ou être mergé à la fois dans la <code>master</code> et dans la <code>develop</code>.</p> <p>Dans la littérature ils appellent ça des <code>back-merge</code>. Je trouve personnellement cette solution très peu élégante. Et surtout difficilement intégrable dans un environnement comme gitlab/github.</p> <p>Une dernière série de branches sont appelées <code>hotfix</code>, elles sont destinées à être mergées à la fois dans la <code>master</code> et dans la <code>develop</code>. Elle permette de corriger des bugs critiques qui seraient passés lors d’un merge d’une branche release dans la <code>master</code>. Il est impératif que la <code>develop</code> contiennent l’intégralité des <code>hotfix</code> qui ont été mergées dans la <code>master</code>.</p> <p>Si ces processus de <code>back-merge</code> des hotfix vers la develop ou des commits ayant eu lieu sur les branches de release vers la develop sont oubliés ou qu’une automatisation échoue. La <code>develop</code> et la <code>master</code> vont finir par être disjointes. Ce qui pourrait causer plus tard des soucis de merge de branche <code>release/</code>.</p> <p>Un autre point que je trouve vraiment dérangeant c’est le manque total d’élégance et de lisibilité d’un arbre ayant subit le principe gitflow. Je suis pas le <a rel="nofollow noreferrer external" href="https://www.endoflineblog.com/gitflow-considered-harmful">seul</a></p> <p>Voilà le résultat d’un arbre après quelques temps d’utilisation de gitflow.</p> <p><img src="../assets/images/gitworkflow/gitflow-mess.png" alt="" /></p> <p>Biensûr il est possible de rendre ça lisible avec <code>git log --graph --oneline --first-parent develop</code>. Mais je ne pense pas que ça soit un bon point de devoir changer de référentiel pour comprendre un problème.</p> <h3 id="avantage">Avantage</h3> <ul> <li>Il permet de gérer plusieurs versions en production</li> </ul> <h3 id="desavantages-1">Désavantages</h3> <ul> <li>Beaucoup trop complexe</li> <li>Peu automatisable et intégrale dans une CI sans faire des concessions</li> <li>Un arbre de commit très peu lisible</li> </ul> <h2 id="github-flow-une-simplification-drastique-2011">Github Flow : Une simplification drastique (2011)</h2> <p>A l’époque déjà certaines personnes n’avait pas le besoin de la complexité de gitflow, dans cet <a rel="nofollow noreferrer external" href="http://scottchacon.com/2011/08/31/github-flow.html">article</a>.</p> <p>Oui à l’époque chez github ils étaient 30 😁.</p> <p>Ce workflow se base sur 6 grands principes:</p> <ol> <li>Tout ce qui est sur la master est déployable et déployé.</li> <li>Tout ajout à la master doit préalablement passer par une branche lisiblement nommée dérivée de la <code>master</code></li> <li>Le développeur travail jamais sur la <code>master</code> toujours sur sa branche</li> <li>Lorsqu’il doit collaborer avec une autre personne, une pull-request doit-être crée.</li> <li>Une fois la pull-request vérifiée, le reviewer merge la branche sur la <code>master</code></li> <li>Si c’est mergé ça doit être déployé!</li> </ol> <p><img src="../assets/images/gitworkflow/github-flow.png" alt="" /></p> <p>C’est déjà plus clean 🤩.</p> <p>Par contre chaque merge de feature peu planter la master si le café du matin n’était pas assez fort. Il faut donc un code très automatisé en terme de vérification pour éviter de déployer des régressions.</p> <p>J’appellerai ça le déploiement sans filet 🤪.</p> <h3 id="avantages-1">Avantages</h3> <ul> <li>Très facile à automatiser dans une CI/CD</li> <li>On peut lire le graphe de commit !</li> </ul> <h3 id="desavantages-2">Désavantages</h3> <ul> <li>Dépendant du système externe des pull-requests</li> <li>La master peut être instable à tout merge</li> <li>Non adapté à des cycles de déployement ( sprint )</li> <li>Non adapté au maintient de plusieurs versions</li> </ul> <h2 id="gitlab-flow-automatisation-a-tout-prix-2014">GitLab Flow : Automatisation à tout prix (2014)</h2> <p>Dans un <a rel="nofollow noreferrer external" href="https://about.gitlab.com/blog/2014/09/29/gitlab-flow/">article</a> paru en 2014. Les équipes de GitLab nous exposent leur manière de procéder.</p> <p>Ce processus s’appuie sur 11 règles:</p> <ol> <li>Ne jamais faire de commit direct sur la master</li> <li>Tout commits doit bénéficier de tests automatisés, pas seulement sur la branche <code>master</code></li> <li>On lance tous les tests, tout le temps. Pas seulement ceux de la feature que l’on développe</li> <li>On fait la code review avant le merge sur la <code>master</code> pas après.</li> <li>Tout est automatisé</li> <li>Les tags doivent être apposés par un humain, pas un robot</li> <li>Une release = un tag</li> <li>Un commit partagé est considéré immutable, <strong>jamais</strong> de rebase!</li> <li>Le référentiel est la <code>master</code>, tout le monde commence d’elle, et finit à elle</li> <li>Les bugs sont fixés d’abord sur la <code>master</code> puis sur les releases.</li> <li>Soignez vos messages de commits !</li> </ol> <p><img src="../assets/images/gitworkflow/gitlab-flow.png" alt="" /></p> <p>Si l’on ne prend que la partie haute du schéma, on retrouve le GithubFlow.</p> <p>Ce qui diffère ce sont les deux branches <code>staging</code> et <code>production</code>. Celles ci, ne sont et doivent pas être modifiés par un humain. Elles servent à déployer des environnements différents avec des niveaux de criticité différents.</p> <p>La <code>master</code> est destiné aux développeurs, le but ultime n’est pas de la flinguer. Mais si elle est sur le carreau cela n’impacte entre guillemets que les devs.</p> <p>La <code>staging</code> est plus critique, ce qui est en staging est mis à disposition des équipes internes. Un down peu impacter le travail des équipes de QA et de produits. Elle ne devrait pas avoir de down mais l’erreur est humaine.</p> <p>Les bugs post-release sont corrigés dans cette environnement, autrement dit les hotfix internes, dérivent de la <code>staging</code> et sont reportées dans la <code>master</code> puis dans la <code>staging</code>.</p> <p>Le lourd pour finir, la <code>production</code>, jamais de down, tout ce qui est sur <code>production</code> a obligatoirement passé par le <code>staging</code>!</p> <p>Comme d’habitude si un bug critique est découvert et qu’il faut absolument déployer en urgence. Il est possible de générer des branches de hotfix depuis la <code>production</code> et de les merger à la fois dans <code>staging</code> puis <code>production</code>.</p> <p>Une fois le hotfix dans la <code>staging</code>, il faut encore la faire descendre dans la <code>master</code>.</p> <h3 id="avantages-2">Avantages</h3> <ul> <li>Par construction, automatisable dans une CI</li> <li>Un arbre de commit très propre</li> <li>Donne un filet de sécurité avant de déployer des régressions</li> </ul> <h3 id="desavantages-3">Désavantages</h3> <ul> <li>Se base sur un code très automatisé à la base, TU, tests de régression, etc…</li> <li>N’est pas conçu pour gérer plusieurs versions en production en parallèle</li> <li>Les hotfix sont gérées d’une manière très peu élégante</li> </ul> <h2 id="yagw-mon-approche-du-probleme">YAGW : Mon approche du problème</h2> <p>Tout d’abord énonçons le contexte.</p> <p>Je travaille sur un projet basé sur un sytème de release cadencé de 3 semaines.</p> <p>La base de code est en début d’automatisation des tests ( il y a des TU mais très localisés ). Aucun tests e2e. Et l’automatisation de la CI est encore balbutiante.</p> <p>Notre environnement de collaboration est GitLab et nous utilisons la version Core de celle ci. Nous utilisons déjà les issues et les merge-request.</p> <p>L’idée est d’arriver à une séparation d’environnement de production et de développement, tout en s’assurant de gestion plus élégante des hotfix que ce que GitLab Flow peut proposer.</p> <p>La CD devra être capable de déployer des environnement différents en fonctions des contextes d’utilisation.</p> <p>Mon système se base sur 10 principes:</p> <ol> <li>Tout ce qui est sur la master est déployable en production</li> <li>Tout ce qui est sur la develop est testable par des équipes non techniques et non déployé publiquement</li> <li>Un humain ne peut pas faire de commit ni sur la <code>develop</code> ni sur la <code>master</code></li> <li>Chaque release part de la master et se finit dans la develop</li> <li>Chaque sprint possède sa branche de release</li> <li>Chaque feature possède sa branche feature</li> <li>Toute feature avant d’être mergé dans la release passe par une merge-request</li> <li>Toute release avant d’être mergé dans la develop passe par une merge-request</li> <li>Tout merge de develop vers master se fait par merge-request</li> <li>Les hotfix dérive de develop et finissent dans develop</li> <li>Les branches master et develop sont immutables, un commit ajouté n’est jamais modifié encore mois supprimé</li> <li>Les branches de release peuvent être rebase sur la develop si besoin</li> <li>Les déploiements de production sont conditionnés par l’ajout d’un tag</li> </ol> <p><img src="../assets/images/gitworkflow/yagw.png" alt="" /></p> <p>Quelques précisions concernants certains points:</p> <p>Le tag <code>1.0-fix3</code> est nécessaire pour des cause de process lecacy qui ont besoin d’un tag pour fonctionner.</p> <p>Il est donc autoriser de tagger les commits de la develop à des fins de pre-release internes.</p> <p>La branche <code>feature/4</code> est une sorte d’anomalie dans le processus. Elle peut soit être dû à un développeur qui fini ses tickets de la release courante et qui s’attaque en avance de phase à des fonctionnalité de la release suivante. Soit c’est une feature qui a pris plus de temps que le sprint et qui n’est donc pas terminée.</p> <p>Que cela soit l’une ou l’autre l’idée sera de rebase <code>feature/4</code> sur la <code>release/1.2.0</code> lorsque celle existera.</p> <p>On remarque que la <code>feature/2</code> ne provient pas du <code>tag 1.0.0</code> mais du commit de merge de la <code>feature/1</code>. Je considère que les tests de features peuvent s’étaler tout au long d’un sprint et ne sont pas obligatoirement à faire à la toute fin de celui-ci.</p> <p>Les branches de release ne sont pas forcé de provenir du commit taggé sur la <code>master</code> mais je trouve plus clean ainsi.</p> <p>Par contre je considère comme une anomalie d’avoir deux <code>release</code> actives.</p> <p>L’intérêt du sytème qui on doit se l’avouer est très proche de Gitlab Flow est de ne pas considéré les hotfix comme des commits d’exception.</p> <p>Le deuxième intérêt est de merger qu’une seul fois une branche et de pouvoir la détruire ensuite. Ce qui s’intègre très bien au processus de merge request de GitLab.</p> <p>Enfin, les branches de release peuvent servir d’environnement de dev, la develop de staging et la master de production.</p> <p>A la fois develop et master peuvent accueillir des processus de CD.</p> <h3 id="avantages-3">Avantages</h3> <ul> <li>Peut-être automatisé mais ce n’est pas obligé</li> <li>Le code peut ne pas être automatisé en test, les vérification humaines sont présentes</li> <li>Permet une séparation en environnement</li> <li>Fix le problème de gestions d’hotfix en ne les considérant pas comme des cas particuliers</li> </ul> <h3 id="desavantages-4">Désavantages</h3> <ul> <li>Les merge request peuvent-être nombreuses</li> <li>Ne gère qu’une version en production à la fois</li> <li>Se base activement sur GitLab/Github et ses outils de merge/pull request</li> </ul> <h2 id="conclusion">Conclusion</h2> <p>Je n’ai pas la prétention d’avoir révolutionné quoique ce soit.</p> <p>Je vous présente un système que j’ai éprouvé et qui m’a semblé pertinent.</p> <p>N’hésitez surtout pas à venir dans les commentaires.</p> <p>Merci beaucoup de m’avoir lu et à la prochaine pour de nouvelles aventures. 😀</p>