Intro
Git Flow tu connais ?
non ? Et Git tu connais ?
non…ouais faut faire un effort la monsieur (ou madame).
Alors git j’explique pas. Si tu connais pas reviens me voir, mais va tout de suite apprendre qq commandes car c’est juste une tuerie ce truc. Quand t’as connus vss, svn ou team foundation server, tu sais que git te sauve la vie. Il est juste incontournable aujourd’hui. Ho tu pourras faire semblant qq heures, mais tu vas vite te retrouver dans l’impasse. Un conseil, tarde pas trop, apprends git ! Et en ligne de commande, pas avec un outil (quoi qu’un outil peut éventuellement t’aider, mais crois moi, fait tout en ligne de commande…)
J’ai personnellement tardé à y passer. Trop. Et j’ai aussi utilisé des outils graphiques. Personne n’est parfait !
Alors si tu es encore la, tu sais ce qu’est une branche, un merge ou un rebase, un commit…
C'est quoi Git Flow ?
A lire, surtout le premier : voici 3 liens :
https://danielkummer.github.io/git-flow-cheatsheet/index.fr_FR.html
https://grafikart.fr/tutoriels/git-flow-742
https://git-flow.readthedocs.io/fr/latest/presentation.html
Ca cause Git Flow mieux que moi. Je suis ici pour vulgariser. Alors Git Flow c’est un ensemble de commandes git qui permettent de s’organiser autour du code source d’une application. Git Flow propose une stratégie pour gérer le cycle de vie d’une application coté code source, du développement locale jusqu’aux versions releases finale en passant par des branches qui auront un but précis.
En vrai, c’est juste des commandes git ! C’est une surcouche qui facilite la vie. Enfin en théorie. Perso j’utilise les principes de Git Flow mais pas ses commandes.
Pour expliquer Git Flow, on va se mettre dans un contexte, imaginons la vie d’une application, par exemple Tonder, une app web pour flirter.
V0.0.1 alpha - naissance d'une app
Il était une fois un développeur en recherche d’amour (il veut ken à donf) et il lui vient une idée d’application qu’il nomma Tonder. Le dev est tout seul sur son projet. Il bosse dessus comme un ouf et sort sa premiere app Tonder Alpha 0.0.1
Il est content, mais c’est une version alpha. Elle tourne sur un serveur à lui dans sa piaule, bancale, comme son code.
V0.1.0 bêta
Arpès quelques jours de discussion avec son hamster, son app ressemble à quelque chose, il veut faire tester son app et la rend disponible en version bêta privé. Il a donc une « prod » (toujours dans sa piaule) et il s’appercoit qu’il devient difficile de travailler directement sur sa prod sans prendre le risque de tout péter. Alors il crée une version « staging » sur laquelle il bosse.
Mais pour le moment, il existe qu’une « version » de son code. Aucun historique, tout est en local sur un disque dur de sa machine. Un virus, un feu domestique, un coup de foudre, pire trouver une meuf et avoir des gosses… il peut tout perdre.
Notre dev se dit qu’il serait bien d’avoir un controleur de code source qui lui permettra de
- sauvegarder son code sur un cloud
- le rendre accessible à d’autre dev via ce cloud
- pouvoir gérer l’historique de son code
Alors il crée son repo Git, qq part où il sait qu’il sera accessible et disponible.
V1.0.0 Première release officielle
Ca y est, notre dev sort enfin au grand publique sa super App. Il est fiert. Il est content. Son poil brille (il a pas pris de douche depuis 72h, 15 cannettes de coca trainent sur le bureau, il ne sait même plus quel jour on est, et si d’ailleurs c’est le jour ou la nuit …)
Les retours utilisateurs arrivent. Il les traite comme il peut, avec le mécanisme suivant : « je code en dev locale, puis si ca marche je passe sur staging puis si ca plante pas je balance sur la production« . Il fait tout à la main, pas d’automatisation, il se dit qu’il a pas le temps pour ça et que c’est qu’une petite release de plus, ça prendra 5 min…
Ils se dit qu’il aimerait bien un peu d’aide… et prendre l’air…
V1.0.547 Ca build à donf
Notre développeur ne compte plus le nombre de build qu’il a fait. Toujours à la main. Ce coup ci il décide d’automatiser sa chaine de livraison/deploiement continue. Il passe par :
- son premier build automatisé : https://reactor.fr/azure-devops-pipeline-ci-cd-first-build
- son premier deploiement automatisé : https://reactor.fr/azure-devops-pipeline-ci-cd-deploy
- ses versions automatisées : https://reactor.fr/azure-devops-pipeline-ci-cd-versioning
- multi environnement : https://reactor.fr/azure-devops-pipeline-ci-cd-environnement
V1.1.41 1er co développeur
Enfin un peu d’aide ! Un nouveau dev arrive en renfort. Git devient indispensable.
Jusque là, le repo git contient 2 branches, une master et une develop.
La branche develop est celle que les développeurs utilisent.
La master sert de branche « release ». Quand on estime que l’on a quelque chose, on pousse du code depuis la branche develop vers la master.
Une pipeline s’occupe de mettre à jour le staging dès que la branche develop reçoit un commit.
Une pipeline s’occupe de mettre à jour la prod dès que la branche master reçoit un commit.
Nos deux devs travaillent en simultané sur la branche dev. A chaque commit, on a run de pipeline, ca fait bcp de deploiement pour parfois pas grand chose. Alors nos deux devs décident de travailler en branche.
Chacun aura sa branche au départ. Mais nos développeurs se rendront compte qu’avoir une branche chacun revient à avoir deux versions de la branche develop (en plus de celle ci). Il ne profite pas des avancés de chacun et attendent que la branche develop soit à jour pour récupérer le travail de l’autre, via des cherry-pick ou des rebases hasardeux. C’est un peu confu, et nos deux devs décident d’appliquer Git Flow avec des branches feature (fonctionalités).
Ainsi, ils peuvent travailler tous les deux sur une feature si il le souhaite, ou chacun sur la sienne. C’est du travail commun qu’il faut faire avancer. Quand c’est prêt, on bascule ce travail sur la branche develop commune. Chacun s’occupe alors de « distribuer » ce nouveau code sur les branches qui le souhaite pour mettre à disposition ce code (merge ou rebase).
Nos deux devs utilisent des concepts de Git Flow. Ce dernier permet avec quelques commandes simple de créer nos branches feature et de les merger sur la develop.
V1.2.54 équipe "agile"
L’équipe a évolué.
Notre premier dev est passé product owner/CTO/CEO/Comptable/Directeur Artistique/Growth Hacker/Mac Gyver, en altérnance et pas dans l’ordre.
Notre deuxième dev est passé lead tech.
Ils ont embauché 3 devs. Ils ont un backlog (listing de fonctionalité à faire, bug a corriger…), c’est comme un tableau avec des post-it collés partout.
Ca y est, on peut dire qu’ils sont sortis de la piaule du gars, ils utilisent des méthodes de travail (scrums, kanban, alarache), ils ont un beau bureau, ou pas (full remote pour tout le monde).
Comment s’organisent t-ils ?
Ils travaillent toujours sur des branches features, seul ou à plusieurs. Lorsque qu’une feature est terminée, celle ci est intégrée dans la branche develop et détruire. Pour cela, ils utilisent toujous les principes de git flow, sauf que cette derniere action n’est pas faite directement par une commande git mais pas une Pull Request.
La pull request (PR), c’est une « demande » d’intégration d’une branche dans une autre. Ici feature –> develop. La pull request est liée avec un logiciel devops comme bitbuket ou azure devops qui présente la PR sur une interface web.
La PR peut avoir quelques critères de validation comme un build qui compile, un ensemble de tests unitaires sont validés et aussi une ou des validations d’autres développeurs. En général, ceux sont des développeurs expérimentés qui vont vérifier le code source (respect de la syntaxe, de la gestion des erreurs, de l’architecture logiciel, du code propre et lisible).
A ce stade, quelques échanges peuvent avoir lieux pour refactoriser le code . Tout est « tracé » sur la page web pour suivre tout ces échanges (commentaire, code; commit, approvals).
Quand tout est validé, l’outil devops propose de merger le code de feature sur develop et en général détruit la branche feature. (il existe plusieurs facon de merger, moi j’aime bien le squash).
V5.2.12 usine logicielle
2 ans plus tard, notre équipe a encore grossi. Ils sont entre 150 et 200 chez Tonder. A Paris, San Fransico, Hong Kong et bien sûr le siège à Rennes.
Les outils devops ne sont plus nésessaires mais juste indispensables. Comment organiser tout ce monde ? Et je vous parle que des équipes dev. Maintenant on a une équipe support, une équipe QA, une équipe devops qui est aussi en charge des services sur le cloud, un service marketing et commercial…
Les principes Git Flow sont plus ou moins respectés. On a ajouté plusieurs branches:
- une branche hotfix pour réparer rapidement des bugs en prod
- une/des branches support qui permet d’avoir des historiques d’applications spécifiques (par exemple une version Tonder spécial communauté rencontre pour chien) qui doit être maintenu mais ne fait pas parti du produit initial ou est trop spécifique (un client relou par exemple, mais qui paie)
- une branche release pour suivre les versions
La livraison continue est agrémenté de test d’intégration/fonctionelle voir meme UI. On a mis en place des versions Test A/B. Le service marketing a des trackers dans l’app qui lui permet de gérer ses opérations. Et j’en passe…
Et notre développeur du départ ?
Il code sa prochaine app car il comprend plus rien à ce qu’il vient de créer…
