Bruno:
[0:51] Faire un épisode sur Git en 2024 peut paraître incongru. Nous pourrions croire que ce serait un peu comme faire un épisode sur la meilleure façon d'utiliser un clavier. Git, ou en tout cas le versionning en général, est une évidence. On ne peut que l'applaudir, d'ailleurs, que cette pratique soit devenue la norme. Mais il existe beaucoup de façons d'utiliser Git, et selon votre contexte, il peut y avoir de mauvaises stratégies. Mais alors, quelle est la meilleure stratégie Git ? Qui est impacté par cette stratégie en dehors des devs ? Et surtout, va-t-on vraiment faire un épisode sur des claviers ? Pour répondre à ces questions de version, je ne reçois pas Richard Darbois, mais il s'y connaît en comite. Olivier, bonjour.
Olivier:
[1:30] Oui, bonjour Bruno.
Bruno:
[1:31] Alors Olivier, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Olivier:
[1:35] Merci beaucoup. Bonjour à tous. Je m'appelle Olivier Jacques. Je suis consultant ProServe à Amazon Web Services. Et donc j'accompagne nos clients sur alors à la fois l'adoption de DevOps, en même temps qu'ils font l'adoption du cloud, l'expérience développeur, la Devex, et puis aussi tout ce qui est platform engineering et j'ai effectivement un background sur tout ce qui est développement depuis un peu plus de 25 ans maintenant.
Bruno:
[2:01] Ok. Donc est-ce que Git c'est un acteur, un contournable quand on parle de developer experience ?
Olivier:
[2:10] Ben alors...
Bruno:
[2:11] Enfin, Git ou d'autres systèmes de versionning.
Olivier:
[2:13] Aujourd'hui, tu ne vas pas développer sans gestion de version. En fait, déjà, c'est quoi Git ? C'est quoi la gestion de version ? Et en fait, tu dis, est-ce que ton intro, c'était est-ce que finalement, c'est une bonne idée de faire un épisode sur Git ou aujourd'hui, c'est un standard ? C'est une très bonne idée parce que dans quelques mois, ça va être les 20 ans de Git. Donc, en avril 2025, c'était donc en 2005, que Linus Torvald en a eu marre de son version control et qui s'est dit, je vais créer quelque chose à moi et qu'il a appelé Git. Et Git, il faut savoir qu'en anglais, je peux être impoli, mais ça veut dire connard. C'est peut-être une info aussi que tout le monde n'a pas, mais ça montre un petit peu l'extrait d'esprit de notre gourou Linus Torvald. Donc il a créé ça en 2005. Et au final, pourquoi ? Parce qu'il n'était pas satisfait de la façon dont il gérait le code du kernel Linux et de toutes ses modifications. Est-ce que Git est nécessaire aujourd'hui ? En tout cas, on a besoin de faire de la gestion de code. Ça répond à quel problème ? Ça répond au problème de ne pas avoir à nommer ces fichiers version 1, version 1 finale, version 1 finale finale, et de partager ça sur un chair ou sur une clé USB.
Bruno:
[3:36] Ce qui est aussi peut-être pas forcément connu c'est comment est-ce qu'il a créé Git, parce que moi l'histoire que j'ai entendue c'est que donc il savait effectivement qu'il voulait refaire un système de versionning et donc il s'est imposé pendant deux ans à gérer lui-même au travers d'une mailing list la réception de tous les commits de tous les gens qui bossaient sur le carnel de Linux, par mail, de les diffuser par mail les différentes branches et compagnie dans le but de se dire, on va voir un peu quels sont les différents usages, les différentes problématiques qui peuvent se poser. Et donc, aujourd'hui pour tous les devs, effectivement, Git ou d'autres sites de versioning sont effectivement la norme, mais il faut imaginer qu'à l'origine il y a un gars qui s'est paluché tout ça, par mail, c'est-à-dire qu'il écrivait lui-même les mails pour diffuser les codes, il recevait tout par mail, il faisait les merges à la main avant de les diffuser par mail. Donc c'est quand même, une dévotion c'est quand même une application au truc qui est quand même assez louable.
Olivier:
[4:38] Oui on peut se poser la question c'est pourquoi se concentrer sur la gestion du code alors que tu as à travailler sur la kernel Linux et qu'il y a d'autres problèmes sur la gestion des fichiers, le réseau et d'autres sujets rigolos, Git n'est pas du tout éloigné de cette gestion par mail on sait que finalement c'est quoi ? C'est des diff qu'on envoie et on se rend compte que Git est atomique comme ça pour justement être compatible avec cette gestion par email.
Bruno:
[5:10] Alors donc tu viens aujourd'hui nous présenter cinq stratégies Git qui ont différentes manières d'utiliser Git au sein d'une équipe ou d'une entreprise. La première question avant de d'aider sur ces cinq stratégies est-ce que ça existe encore des entreprises qui n'ont je dirais même pas de stratégie Git mais qui n'ont même pas de versionning ?
Olivier:
[5:33] Alors, j'en trouve plus aujourd'hui, il y en a eu, j'en ai rencontré, peut-être il y a même une dizaine d'années, donc pas si longtemps que ça. Aujourd'hui, ça n'existe plus, j'en vois pas. Euh... Alors, je mettrais un bémol, parce qu'il peut y avoir des plateformes et des outillages où en fait, Git, ou en tout cas la gestion de code, est faite différemment. Donc Git n'est pas forcément la solution universelle. Tu peux collaborer sur du code sans savoir vraiment que tu utilises Git, même peut-être qu'en back-end c'est Git, sur des plateformes où en fait tu vas pouvoir collaborer, changer ton code, et sans avoir à savoir comment faire un push, un merge ou un rebase.
Bruno:
[6:16] Sur les 5 stratégies est-ce que ta vocation au travers de cet épisode, c'est de présenter 5 nouvelles stratégies ou est-ce que pour toi dans les 5 tu inclues une stratégie que tu vois à peu près partout qui est un peu la stratégie par défaut en.
Olivier:
[6:33] Fait l'idée de cet épisode quand on en a discuté, qu'on a préparé c'était pas de forcément dire voilà la bonne stratégie git il y a des choses que je vois, aujourd'hui, il y en a une dont j'aimerais parler parce que vraiment ça serait bien qu'on la voit plus, et peut-être qu'on va en parler et voir pourquoi c'est pas une bonne idée mais c'est de montrer un petit peu un panel des différentes stratégies et pourquoi prendre l'une plutôt que l'autre et par rapport à son contexte il y a autant de bonnes versions, mais je pense que c'est important de faire son choix en conscience et puis je peux aussi partager quelle est la stratégie Git d'Amazon quand on écrit du code, WS et comment tout ça, ça fonctionne. Donc encore une fois, l'idée, c'est pas de montrer qu'il y a une bonne ou une mauvaise stratégie, c'est de voir ce que moi je vois dans la nature avec nos clients et nos partenaires et puis peut-être parler des différents avantages et inconvénients de chacune.
Bruno:
[7:26] Eh bien, allons-y, lançons-nous. Quelle est pour toi, encore une fois, on va dire la première, mais ça veut pas dire que c'est la meilleure ou la plus répandue, ou en tout cas, c'est la première de la liste que nous on fait, qui n'a aucun tri, aucun ordre particulier. Donc, en premier, je crois que tu voulais nous parler de la trunk-based stratégie, qui, je pense, est quand même une des plus répandues, non ?
Olivier:
[7:50] Alors, la plus répandue, pas forcément. Aujourd'hui, c'est peut-être celle qui serait la plus favorisée ou reconnue comme quelque chose d'avancé. Alors, pourquoi je dis ça ? C'est que, je ne sais pas si vous connaissez, dans la littérature, il y a notamment un groupement qui s'appelle DORA, DevOps Research et Assessment, et Dora faisait, enfin elle le fait toujours d'ailleurs, chaque année une étude sur les pratiques de développement ou de gestion de son SDLC et le lien avec les résultats de l'entreprise. Donc enfin on pouvait mettre en corrélation combien de chiffres d'affaires ou combien de bénéfices faisait une entreprise avec les pratiques de développement et de gestion du SDLC, ce qui est assez incroyable. Et donc ça ils l'ont écrit, en tout cas ils ont un petit peu compilé tout ça avec notamment le docteur Nicole Force Green qui a compité tout ça dans un bouquin qui s'appelle Accelerate. Qu'on mettra dans le podcast, et Accelerate a réussi à faire le lien entre la stratégie de branche, Git, et l'efficacité des développeurs, et donc comme résultat, en lien avec le résultat de l'entreprise. Donc aujourd'hui, le trunk base est vraiment reconnu comme quelque chose d'intéressant.
Olivier:
[9:03] Et ça force un certain nombre de pratiques. En fait, pourquoi on dit ça ? c'est que finalement, quand on fait du code, on a besoin de gérer des branches. Alors, je ne parle pas de branches Git. On va mettre Git un petit peu de côté. On a besoin de gérer des comportements différents. Peut-être que cette version-là, on va l'envoyer à ce client-là avec telle fonctionnalité. Peut-être que ça, dans notre application SaaS, on va mettre ça pour telle population de personnes, en tout cas les trois premiers pourcents qui sont des early adopters. Il y a besoin d'avoir des comportements différents sur le code qu'on va écrire et qu'on va mettre à disposition donc ce sont des branches il y a plusieurs façons de faire des branches on peut faire des branches via le gestionnaire de source on peut faire des branches dans son code ça s'appelle un if, On peut faire des branches avec ce qu'on appelle des features flag qui permettent de dire cette fonctionnalité-là, je la mets à disposition, je ne la mets pas à disposition. Elle est là dans le code, mais elle n'est juste pas activée. Ce besoin de branches, on en a besoin. Comment on y répond ? Il y a plusieurs façons. Git, dans le code, ou des features flag. Il y a d'autres techniques. On pourra parler de plugins ou de choses comme ça pour faire ça.
Bruno:
[10:18] Et donc avec le trunk base du coup tu n'as plus de branches tu ne fais que du feature flag ou du if à l'ancienne.
Olivier:
[10:26] Voilà en fait le trunk base development donc il y a un site qui s'appelle trunk base development que vous allez pouvoir trouver facilement et donc l'idée c'est de pas avoir de branches d'accord donc on a cette branche trunk ou main, et on fait tout dans main donc ça veut dire quoi quand on dit ça ça veut dire attention mais quand on pense à d'autres stratégies git on va se dire mais moi comment je fais ma fonctionnalité qui n'est pas entièrement prête, entièrement développée et comment je fais pour pas déstabiliser ce qu'il y a dans main, ça on va se protéger en faisant peut-être en mettant derrière des features flag, peut-être en faisant donc je parlais d'implémentation de plugin peut-être qu'on peut avoir un plugin qui va gérer cette nouvelle fonctionnalité là qu'on va mettre à disposition uniquement envoyé à tel client ou mettre à disposition pour les personnes qui payent un premium sur notre plateforme SaaS, mais au final ne pas avoir ce lien direct entre la gestion du code avec git et les branches dont on a besoin de faire et que ce soit forcément gestion des branches égale git donc trunk base pas de branches par contre il ya beaucoup de choses que ça veut dire derrière sur les pratiques de développement et comment on code est.
Bruno:
[11:42] Ce qu'il n'y a pas du coup aussi un, Est-ce que c'est une stratégie qui ne serait pas inadaptée pour les entreprises qui sont justement en phase de recherche, de prospection et qui testent un peu des features de droite à gauche et qui donc ont quand même besoin de tester plein de trucs en même temps ou du coup cette mécanique de branche peut justement permettre de plus facilement explorer et tester quoi ?
Olivier:
[12:05] Alors en fait la question qu'on peut se poser quand on dit ça, c'est les besoins d'entreprise qui ont besoin d'explorer, de faire plein de choses différentes et d'avoir plusieurs options, donc ce sont des besoins qui viennent du métier ou en tout cas qui viennent des commerciaux, ou en tout cas de ceux qui ont envie de vendre la solution ou en tirer de la valeur. Est-ce qu'on veut mettre cette possibilité d'avoir plusieurs choix et plusieurs options et plusieurs chemins dans les mains des devs, que j'adore parce que je considère que je m'en fais partie, ou dans les mains des PO, des product owners c'est-à-dire que est-ce que c'est peut-être plus pertinent pour le métier, pour la valeur métier de mettre à disposition ces fonctionnalités-là en tant que feature flag par exemple pour que ça soit déployé et disponible mais ça soit activé la différence entre le déploiement et l'activation et la mise à disposition aux utilisateurs finaux et donc mettre cette mise à disposition, aux utilisateurs finaux dans les mains des product owners ou peut-être même des commerciaux et c'est pour ça que je pense que, j'adore Git mais je pense qu'il ne faut pas lui faire porter tous les problèmes et c'est vraiment l'idée du trunk base en fait en disant qu'on ne fait pas de branches c'est que du coup on a quand même besoin de faire des branches ce ne sont pas juste des branches Git et du coup on va, résoudre ce problème de branches mais ailleurs et je pense qu'il est mieux résolu dans certains cas ailleurs.
Bruno:
[13:34] Donc ça implique quand même d'avoir une certaine on va dire maturité dans son approche du code, et en même temps je recoupe avec un épisode qui est sorti très récemment sur la convergence des bases de données et sur le fait que on a de plus en plus de codes qui commencent à s'exécuter dans la base parce qu'en final quand tu nous dis que, on va gérer cette notion de branche dans le code, c'est un peu comme quand on disait, on ne va pas avoir de code dans la base de données parce qu'en fait ça nous fait trop de trucs à gérer et compagnie. La base de données elle est juste là pour stocker la data et toute l'intelligence tout le logiciel tout le savoir métier, on le met dans le code au même endroit. Donc c'est un peu ça au final, c'est que tu nous dis la branche, on va gérer ça dans le code et on ne se base pas sur un outil de versionning. Comme l'expliquait dans cet épisode, non c'était pas Frédéric je suis désolé j'ai oublié son nom j'ai un trou on commence à remettre du code dans la base parce que ça permet d'avoir du code qui est plus proche de la base, qui est mieux géré c'est plus rapide et compagnie. Est-ce que du coup cette notion de trunk base elle va pas aussi disparaître à mesure qu'on se dit en fait dans le code il faut qu'on ait uniquement des logiques métiers et on va relaisser à nouveau la notion de branche à l'outil versionnique qui fait ça bien mieux que nous.
Olivier:
[14:59] Je pense que tu as évoqué deux sujets. Tu as évoqué un premier sujet de la maturité. Notamment, je pense que tu dis maturité, c'est plutôt l'expérience des développeurs ou des leads techniques qui peuvent faire le sujet. Puis après, il y a un sujet sur technologiquement, où est-ce qu'on met ces changements de code, en tout cas. Sur la maturité, le trunk-based, c'est un vrai choix. Ou du CTO, ça dépend de la taille de l'entreprise, ou du lead technique. Parce que ça va tirer tout un tas de choses et potentiellement aussi complètement sur l'architecture de l'applicatif, donc ça va être un choix qui va besoin de ne pas être porté uniquement par des développeurs qui contribuent sur le projet mais au niveau du CTO parce que vraiment ça va avoir un impact même sur comment on va s'organiser, donc effectivement il y a un sujet de maturité je crois que c'est vraiment une maturité mais c'est un choix technique qui va faire que ça va amener, différents éléments et les pratiques vont être différentes avec cette mise en place du trunk base en disant on n'a pas de branche dans le code, après sur l'aspect est-ce que tu parlais du code au plus proche des données par exemple ou des choses comme ça.
Olivier:
[16:16] Aujourd'hui dans les bases de données quand on met des stored procedures ou du code qui est au plus proche des datas, souvent on essaye quand même de gérer ce même code, aussi avec git ou avec un gestionnaire de code source pour pouvoir gérer les versions et puis monter en version et puis pouvoir rétrograder potentiellement s'il y a besoin donc la complexité git elle reste là enfin de gestion du code elle reste là par contre effectivement le code peut potentiellement être plus compliqué et faire du je ne sais pas si on peut faire du feature flag sur des sortes procédures pourquoi pas c'est ce finalement sont uniquement des if par contre il un sujet qui était intéressant, qui m'a fait penser à l'aspect dette technique. Faire des branches différentes, donc dans le code ou dans le guide. Finalement, c'est quoi ? C'est que tu vas accumuler de la dette technique. Pourquoi ? Parce qu'au final, il va y avoir des choses, des branches mortes que tu ne vas plus utiliser au bout d'un certain temps parce qu'on est passé à autre chose, on a fait des choix et puis on a avancé dans le produit.
Olivier:
[17:18] Donc, il faut... Autant du feature flagging, ça peut être très intéressant, mais ça se contrôle. C'est-à-dire que ce n'est pas une bonne idée d'avoir trop de code mort. Donc il faut avoir conscience de toutes tes branches dans ton code, parce que ça a aussi une complexité de test, pour que finalement ça soit uniquement là, cette dette, elle ne soit pas trop profonde, pour pouvoir contrôler ça et enlever du feature flag quand tu n'en as plus besoin, parce que tu sais que tu as fait ton choix et que cette fonctionnalité-là, elle est disponible pour tout le monde et que ce n'est plus un problème. Donc, il faut quand même contrôler ces aspects branches, mais comme dans Git, où on pouvait, dans cette autre stratégie de branches, avoir énormément de branches, il faut aussi contrôler pour qu'on comprenne, en fait, ce qui tourne en production ou ce qu'on a été envoyé au client A ou au client B.
Bruno:
[18:08] Ok. Si, aujourd'hui, c'est une stratégie qui est mise en avant sur certains aspects, est-ce que pour toi, ça reste quand même une... Alors j'ai bien compris qu'on ne peut pas parler de meilleure stratégie, on est d'accord, dans le monde du dev, il n'y a jamais one size fits all, il y a quand même un... Mais est-ce que pour toi c'est une bonne stratégie par défaut, c'est-à-dire si jamais tu ne veux pas te poser la question de sa stratégie Git, celle-là peut fonctionner dans pas mal de contextes ?
Olivier:
[18:38] Ouais, en fait, alors ce qui est bien, c'est de commencer simple et de complexifier après. Donc, C'est assez simple. En tout cas, la stratégie Trunk-Best Development, elle est très simple à décrire. Elle induit des comportements et des pratiques pas forcément simples à mettre en place, mais à décrire, elle est très simple. Tu n'as qu'une branche.
Olivier:
[19:00] Après si tu as des complexités sur encore une fois je dois envoyer ce code là à tel client qui est dans un environnement déconnecté dans une usine, déconnectée d'internet pour des besoins industriels par exemple ça ça peut amener des choses que tu as à gérer potentiellement au niveau de tes branches git, mais c'est quelque chose, c'est de la complexité qu'on va résoudre plus tard donc si on commence un projet, Quelque part, Trunk Based Development, on va dire, c'est le choix un peu safe. Et ça va être en tout cas un environnement qui peut t'emmener très, très loin. D'accord ? Donc après, derrière, si tu veux gérer des complexités qui arrivent par derrière, tu les amènes, mais plus tard. Et un peu souvent un biais qu'on a en tant qu'ingénieur, on va penser à tout ce qui peut mal se passer ou tout ce qui peut poser problème et donc amener dès le départ une solution complexe. Alors qu'en fait, la question, c'est un peu la question du bénéfice et du coût. Le bénéfice, c'est quelque chose que tu auras plus tard, si effectivement, ce risque se réalise et que tu as à le résoudre. Et donc, voilà. Le coût, tu vas le payer tout de suite. C'est-à-dire avoir la complexité dès le départ, alors que tu n'en as pas besoin, ça va te coûter tout de suite.
Bruno:
[20:21] Oui l'exemple qu'on prend aussi souvent dans ce podcast c'est les gens qui construisent un service qui peut absorber un million de users en simultané, jour 1 compte en toi de 10 déjà tu prendras moins de temps et on verra le million si un jour t'en as besoin faut être un peu pragmatique parfois.
Olivier:
[20:38] L'idée c'est d'être pragmatique donc la complexité donc partons simple effectivement TrunkBest ça peut être un bon choix.
Bruno:
[20:45] En deuxième il y a une stratégie où, alors moi j'avoue j'ai déjà été coupable de la mettre en place à un certain moment, après je suis passé à autre chose, mais donc c'est d'avoir des branches par environnement avec l'idée de se dire que tu as ta branche de dev, de test et puis après petit à petit tu rechanges en fait ton main change, donc ça c'est une stratégie aussi qui est, répandue, appréciée ou c'est quoi toi ton...
Olivier:
[21:17] Alors, c'en est une de stratégie. On la voit. Un peu plus tard qu'il y a quelques semaines, on me l'a encore proposé pour un projet chez un client. C'est quelque chose que, généralement, en discutant, en fait, pourquoi on fait ça ? Donc, avoir une branche par environnement. Donc, on a notre code. Alors, c'est souvent le cas pour... Enfin, c'est le cas pour le code applicatif ou même plutôt d'infrastructure, mais on a effectivement une déviation entre l'environnement de développement qui peut être plus petit ou qui peut avoir un certain nombre de choses qui ne vont pas être en production tout de suite et donc on va se dire cette branche mentale où est-ce que je la mets ? On va mettre dans le git. Donc c'est un assez mauvais choix. Alors pourquoi ? Si on parle du code d'infrastructure, par exemple, si on prend le cas de Terraform, il y a d'autres outils d'infrastructure, mais si on prend le cas de Terraform, on va gérer ça comment, cette variation ? Si on le met dans Git et qu'on fait une branche pour le dev et une branche pour la production, à chaque fois, on va être obligé de fusionner entre le dev et la prod et les différentes différences, puis on va avoir une déviation sur comment ça se comporte en développement et comment ça se comporte en production. Et garder ça à jour c'est compliqué ça prend en tout cas c'est quelque chose qu'on va assez vite oublier et il y a de fortes chances qu'on se plante parce qu'il y a des choses qui fonctionnent en dev et qui fonctionnent pas en production.
Olivier:
[22:44] En Terraform la façon de résoudre ça c'est d'avoir des fichiers TFVars qui vont être injectés au moment de faire son Terraform plan et hop là ils sont passés trop dans les détails mais l'idée c'est finalement, dans la CI qui va faire le déploiement donc avec GitLab ou GitHub, ou d'autres outils, c'est.
Olivier:
[23:04] Mettre, suivant la cible, que ce soit développement ou production, d'avoir le bon fichier de variable, le bon fichier de TFVars et d'appliquer la commande avec ce fichier-là. Donc, le code reste le même, c'est juste qu'on a variabilisé et on a créé au niveau de Terraform une branche, mais qui n'est pas dans Git. Là où c'est problématique, c'est vraiment la différence entre les différents, entre les environnements. Et ce qui se passe, c'est que, quand on fait une branche, Ce n'est pas uniquement ce qui change, enfin ce qui est différent, qui va être différent on va dire dans le repo, c'est que quand on est dans la branche dev ou dans la branche production, on a un repo qui est, complètement différent. Donc ça va être toujours de la fusion entre les deux. Et alors ça, vraiment, il y a de fortes chances de se tromper et d'oublier des choses.
Bruno:
[23:54] Moi, c'était la difficulté que j'avais rencontrée quand j'avais mis ça en place. Parce que ça me semblait une bonne idée au début. Mais c'est vrai que petit à petit, tu commences à avoir des branches qui partent vraiment dans deux directions très différentes. Et puis à un moment, tu te dis comment je fais ? Est-ce que j'en coupe une ? Et puis tant pis pour ce que j'ai gagné d'un côté. La réunion, le merge est toujours un peu compliqué.
Olivier:
[24:19] Mais tu vois ce qu'on essaye de faire avec Git, c'est d'avoir des branches c'est très vrai pour le trunk based development c'est d'avoir des branches ou qui n'existent pas ou qui sont très courtes dans la durée de vie, les environnements il y a de fortes chances qu'ils soient plutôt longs dans leur durée de vie et donc on voit que là on est en train de créer quelque chose qui n'est pas pertinent.
Bruno:
[24:40] Très bien en deuxième stratégie, pardon, tu nous proposes GitFlow. Est-ce que tu peux nous détailler un peu le fonctionnement ?
Olivier:
[24:52] Alors, GitFlow, extrêmement populaire. Alors, GitFlow est arrivé, je pense qu'il y a quasiment 10 ans maintenant, au moment où Git était là, un super outil, complexe quand même, à maîtriser. Et il n'y avait pas vraiment de recommandations sur comment utiliser. Au final, les seuls cas d'usage qu'on avait, c'était le kernel Linux, et puis après il y a eu Android, plein de gros projets qui sont passés à Git.
Olivier:
[25:20] GitFlow a amené une méthodologie. Et au final, le... Le postulat, c'était un blog post, un article de blog qui a été posté, et c'était de dire, voilà une stratégie de branche qui fonctionne pour moi. Il n'a pas dit grand chose de plus, sauf qu'en fait, il y avait un vide énorme sur le sujet, et donc, je crois que son nom, c'est Vincent, son prénom, c'est Vincent, celui qui a proposé ça. Mais au final il a proposé quelque chose qui fonctionnait pour eux dans leur contexte et vu qu'il y avait un vide il n'y avait pas de méthodo associé à Git et bien ça a été on va dire la stratégie par défaut, alors Gitflow ça fonctionne comment ? C'est qu'on a une branche main on a une branche dev ou développement et puis on a plein d'autres branches potentiellement des branches release alors ça fonctionne comment ? Main est censé être vraiment ce qu'on a en dernier, ou en tout cas, le dernier code, mais qui a été déployé à un moment en production. Dev, c'est la branche active, et c'est la branche où tout le monde poste son code. Tous les développeurs d'une équipe vont développer à partir de Dev. C'est-à-dire que quand on commence une nouvelle fonctionnalité ou un bug fixe, on part de Dev. C'est censé être la dernière version. Au dessus de dev on va créer des feature branch.
Olivier:
[26:44] Supplémentaires donc tu es en train de voir la ramification que c'est en train de créer, et ces feature branch vont avoir des durées alors malheureusement avec avec Gitflow qui était souvent assez longue c'est à dire feature branch c'est la branche dure le temps de la création enfin le développement de la feature, on peut parler en jour en semaine en mois ça.
Bruno:
[27:05] Peut être vite long.
Olivier:
[27:05] Voilà ça peut être vite long et donc tu vois que tout ça va se recroiser à un moment pour être fusionné dans Dev à un moment. Et qu'est-ce qui se passe ? C'est qu'on va avoir au final quelqu'un qui va être nommé « Release Manager ». Qui va avoir pour mission ingrate, de fusionner tout ça pour que pouvoir créer une release et que ça parte peut-être en qualification et en production et on voit que c'est pas on est clairement pas en train de faire de l'intégration continue, le but de l'intégration continue c'est que tous les développeurs, tous les changements évoluent au fur et à mesure ensemble pour qu'on arrive à avoir quelque chose qui soit efficace t'es.
Bruno:
[27:44] Obligé d'avoir une personne voire même une équipe qui va s'occuper de choisir à chaque fois qu'est-ce qu'on prend, qu'est-ce qu'on prend pas et de pousser.
Olivier:
[27:53] Et c'est ce qui se passe et c'est plutôt confortable pour les développeurs pourquoi GitFlow est aussi populaire c'est que je suis développeur je m'occupe de ma feature, je fais ma feature branch en isolation, je propose dans Dev et puis derrière j'arrive à aligner assez vite à Dev mais je m'occupe pas de l'aspect, homogène d'une release ou en tout cas quelque chose qui doit fonctionner de bout en bout moi je m'occupe de mon petit bout c'est pas péjoratif, c'est juste que c'est très confortable intellectuellement de faire comme ça, par contre encore une fois, les bénéfices de l'intégration en continu ne sont pas là, et donc on travaille bien en isolation, et c'est pas hyper pertinent, sauf que il y a des cas où ça peut être quand même intéressant, et je le vois notamment quand il y a des projets qui sont sous-traités, avec différents sous-traitants, avec différents, on va dire périmètres pour chaque sous-traitant, dans certaines entreprises ça peut se passer comme ça, où là, effectivement ça peut être une isolation qui peut fonctionner ça reste très compliqué je t'imagine bien le setup mais c'est quelque chose qui peut, dans certains cas, peut être appliqué.
Bruno:
[29:02] C'est peut-être même encore plus compliqué quand justement c'est des prestataires différents qui vont faire chacun leur leur commune, parce que du coup tu as encore moins de liens avec les personnes qui ont produit le code.
Olivier:
[29:13] Ça c'était des choses qu'on voyait, on voit beaucoup moins maintenant. C'est-à-dire qu'il y a eu un effet de réinternalisation de ces développements, le développement externe. Je ne sais pas que ça n'existe pas, mais aujourd'hui, on a plus des développeurs qui arrivent, des sociétés de services, qui vont être intégrés dans les équipes, et donc qui vont avoir accès aux dépôts de code, alors que précédemment, même, ils étaient entièrement isolés et n'avaient pas accès aux dépôts entiers de code. Donc, ils avaient un périmètre très défini et ça permettait d'intégrer les différents choses. avec la réinternalisation des développements ou en tout cas un mode de fonctionnement un peu différent. C'est une stratégie de branche qu'on voit moins et en tout cas elle est complexe à gérer. Elle peut être intéressante parce qu'elle isole les développeurs de cette problématique de gestion des releases. Mais elle est... C'est ça. On n'est pas dans les très bonnes pratiques.
Bruno:
[30:07] En troisième, ce sera en quatrième stratégie. Oui, c'est ça, on en est à la quatrième. On a la feature branch qui est aussi je pense peut-être une des plus répandues aujourd'hui enfin moi j'entends plus souvent parler de ça je suis plus surpris quand j'entends un trunk based qu'un feature based.
Olivier:
[30:25] Alors donc la feature branch c'est quoi ? c'est qu'on a cette fameuse branche main, et à chaque fonctionnalité qu'on veut amener ou potentiellement un bug fix on va créer une branche donc la durée de la branche va durer le temps de la fonctionnalité, donc il faut un petit peu faire attention à ça, l'idée c'est encore une fois si on fait ça on s'isole du main et on s'isole des autres développeurs sauf que ça a un intérêt, potentiellement on a que cette branche main et puis on fusionne assez fréquemment.
Olivier:
[30:58] Ça c'est le feature branch, c'est un modèle qui est hyper populaire, pourquoi ? Parce qu'en fait ça nous permet de connecter la CI, l'intégration continue, donc GitHub CI, GitHub actions ou d'autres sur les features branch donc ça se passe comment c'est que donc il y a main j'ai besoin de développer quelque chose de nouveau on fait une nouvelle branche à partir de main donc une branche dans le guide c'est très simple c'est pour ça que c'est devenu très populaire dans le guide c'est juste un label sur un commit donc c'est hyper léger et c'est très très très léger à mettre en place donc on fait on fait cette nouvelle branche pour cette feature là on va à développer dessus. Généralement la CI va être automatiquement connectée à cette branche, donc à chaque commit et push qu'on fait sur cette branche, on va avoir des résultats de tests, donc d'analyses statiques, il peut y avoir potentiellement des tests end-to-end qui sont faits. Et puis on va faire à la fin une merge request ou une pull request suivant quel outil on utilise.
Olivier:
[32:00] Pour demander une revue finale ou merger ça dans main donc l'aspect feature branch est confort et hyper populaire et pour raison bien plus populaire que le trunk based aujourd'hui on le voit beaucoup plus, pourquoi ? Parce qu'on a cet aspect CI qu'on sait parfaitement connecté et aujourd'hui, il y a quelques années c'était un petit peu pénible avec Jenkins, maintenant il y a des plugins qui font ça très bien et puis avec GitLab CI ou d'autres outils maintenant c'est parfaitement intégré dans l'ensemble.
Bruno:
[32:30] Et en dernier c'était le forking, alors c'est là moi j'en suis un peu moins familier donc je te laisse nous faire la démo.
Olivier:
[32:37] Alors ça ça vient de GitHub donc il y a Git et puis au dessus il y a les plateformes d'hébergement de Git comme GitHub, comme GitLab, j'en profite pour placer une autre plateforme d'ALM d'Application Lifecycle Management qui s'appelle Tulip, de la société Enalim qui est française.
Olivier:
[32:56] Mais au final c'est quoi c'est que l'idée de ce fork c'est pour répondre à un besoin des projets open source, un projet open source tu vas avoir une liste de contributeurs habituels qui font partie de l'équipe du projet et puis tu vas avoir des équipes ou en tout cas tu vas avoir des contributeurs externes auxquels tu vas a priori pas faire confiance, en tout cas tu vas vouloir déjà tu ouvres à la contribution ce qui est une chose excellente donc tu as l'aspect open source mais tu as l'aspect dans l'entreprise inner source donc tu peux le faire aussi à l'intérieur de ton entreprise, donc encore une fois les contributeurs ne font pas partie de l'équipe par contre tu veux autoriser les contributions mais tu veux que ces contributions là soient revues, alors à la fois par la CI, automatiquement et aussi par des pairs qui vont pouvoir discuter de la contribution et puis potentiellement la fusionner le fork, permet, en fait, finalement, le fork, c'est quoi ? C'est que tu vas faire une copie complète du repo ailleurs, donc généralement sous ton nom d'utilisateur ou dans une organisation, et tu vas travailler en isolation jusqu'à temps que tu sois prêt, en tant que contributeur, à faire cette pool request. Donc, c'est une demande de tirage, de regarder, tirer mon code que j'ai là, qui est prêt, ou une merge request qui nous demande de fusion, c'est la même chose, c'est juste un nom différent.
Olivier:
[34:20] Mais donc l'idée c'est quoi ? c'est de pouvoir pour les développeurs qui sont externes de ton équipe ou carrément du projet de faire des contributions et d'ouvrir ça, donc c'est pas à faire dans un environnement c'est pas une stratégie de branche qu'on doit appliquer dans une même équipe, faire du forking parce que pourquoi ça demande une maintenance de l'alignement des deux repositories, du repository source et du repository qui a été forqué, donc il y a de la guiterie à mettre en place, c'est pas hyper agréable, donc si les développeurs doivent contribuer de façon pérenne, ils sont connus et on leur fait confiance, c'est mieux d'avoir une autre stratégie de branche. Mais par contre elle est très utile pour des contributeurs externes auxquels tu fais pas confiance. Alors fais pas confiance, c'est pas péjoratif c'est juste que tu as besoin de revoir ce que tu vas potentiellement fusionner.
Bruno:
[35:17] Il me ne me souviens plus qui, je ne me souviens vraiment plus de l'épisode mais je crois que j'ai déjà eu quelqu'un ici nous expliquer qu'il avait une stratégie où il y avait une branche par développeur. C'est un peu ça au final ?
Olivier:
[35:29] Alors, sauf que là, c'est un repo complet par développeur. Ce n'est pas juste une branche. Là, tu as vraiment le repo en entier qui a aussi son propre système de branches. C'est une copie mais qui garde un lien avec le repository source. C'est intéressant ce que tu dis sur avoir une branche par développeur.
Bruno:
[35:50] Il m'a dit ça, je me suis dit tu parlais d'un release manager là c'était ça en fait c'est-à-dire que tu avais une personne dont le taf c'était de réunir toutes les branches, et je crois qu'en plus ils arrivaient à faire, ils faisaient un déploiement par jour je crois quelque chose comme ça, Donc genre à 18h, je ne sais plus quelle était la mécanique, je suis peut-être en train d'inventer de fantasmer un truc, mais j'ai ce souvenir-là d'une branche par développeur, et genre tous les jours à 18h, toutes les branches sont mergées.
Olivier:
[36:24] Je pense que ça dépend de la taille de l'équipe tu vois si c'est une entreprise qui est on va dire petite 3, 5 développeurs, 10, travaille tous ensemble côte à côte c'est pas forcément un problème d'ailleurs, c'est un autre sujet que je voulais mentionner c'est que Git n'est pas forcément la solution pour la collaboration proche entre les devs je m'explique, l'idée de gérer son code avec deux codes c'est d'avoir différentes versions de pouvoir tracer qui fait quoi et puis de faire des revues et d'avancer comme ça, quand tu fais du trunk based par exemple t'as plus de branches donc comment tu vas gérer cet aspect collaboration et potentiellement peer reviews en tout cas on discute du code avant qu'on le mette dans main il y a des techniques comme du pair programming ou du mob programming donc le mob programming c'est pas à deux le mob programming c'est carrément, c'est pas l'équipe entière mais c'est quatre cinq développeurs qui se mettent derrière un clavier donc je sais pas si t'as déjà eu un épisode sur le mob programming mais c'est peut-être.
Bruno:
[37:30] On en a déjà parlé j'ai déjà eu le cas de le pratiquer je trouve ça génial.
Olivier:
[37:33] Je trouve ça d'une efficacité incroyable alors que c'est très difficile à justifier, au management au dessus tu te dis quoi il y a cinq personnes qui travaillent sur le même bout de code, mais bon ça résout d'autres problèmes qui sont la collaboration et puis donc si tu as déjà traité dans l'autre épisode donc tu as des techniques entre le pair et le mob programming qui sont bien plus efficaces que faire une pull request ou une merge request quand on parle du future branch, qui va amener une grosse latence pourquoi ? c'est que tu vas avoir, J'ai fait mon code, il passe mes tests, je suis prêt à le faire revoir, mais cette revue, elle va prendre un jour, deux jours, une semaine, tant que quelqu'un d'autre est disponible dans l'équipe, ou alors, je vais dire pire, il y a un lead tech qui est en congé, et qui ne peut pas, ça demande forcément son approbation. Donc ça, ça crée une latence énorme, et tu vois, il n'y a plus cette fluidité d'intégration continue à cause de ça. Donc Git n'est pas c'est un gros marteau mais tout ne peut pas prendre la forme d'un clou et donc il y a des solutions, parce qu'on parlait d'expérience développeur de Devex et il y a des solutions pour que les développeurs se parlent beaucoup plus entre eux et soient beaucoup plus fluides sur l'aspect, partage de la connaissance sur le code et voir même arriver aux bonnes conclusions sur l'implémentation parce qu'avec du mode programming, tu le fais ensemble.
Bruno:
[39:01] Ah, je vois. Et de la même manière, j'entends que ce n'est pas forcément adapté pour des petites équipes qui sont dans le même bureau et qui bossent ensemble, c'est un peu ce que tu dis. Est-ce qu'à l'autre bout du scope, est-ce que tu penses qu'il y a un moment, il y a une taille d'équipe qui fait que là, ça ne devient plus adapté à... Il faut passer sur une autre catégorie ou un autre mode de travail. Ou au contraire, plus il y a de gens, plus Git est efficace.
Olivier:
[39:26] Alors là ça va, on va peut-être commencer, enfin la taille d'équipe elle est hyper importante pour être productif sur quelque chose, et donc tu sais qu'à Amazon on a cette fameuse notion de two pizza team, alors c'est deux pizzas américaines, donc une équipe l'idée c'est que la taille de l'équipe soit la taille qui peut être nourrie par deux pizzas, généralement ça fait à peu près huit personnes, et pourquoi c'est qu'en fait l'idée c'est par rapport aux structures de communication, En fait, quand tu as 8 personnes qui ont besoin de collaborer ensemble, donc tu as un certain nombre de relations, de structures de communication qui sont faites. Quand tu commences à avoir une équipe, tu parlais d'augmenter la taille de l'équipe de 15, 20, 50 développeurs, ce qui n'est pas commun.
Olivier:
[40:14] Là, ça y est, on ne peut plus communiquer. C'est trop complexe. Après on revient sur cette approche micro-service ou en tout cas réduire la taille, pas seulement des livrables mais du périmètre qu'une équipe a géré donc par rapport à Git, quand tu as une équipe de 8, ça se fait très très bien de faire du trunk base et de faire des potentiellement des peer review ou du mob programming, c'est vraiment adapté, quand tu commences à avoir une équipe qui est plus grande là il faut commencer par la loi de Conway.
Olivier:
[40:49] Donc la loi de Conway pour rappel c'est qu'en fait une organisation aura tendance à créer des solutions qui sont le reflet de leur structure de communication ça veut dire quoi ? Ça veut dire que si on a une équipe qui a un produit et puis il y a une équipe qui s'occupe par exemple si on prend le store Amazon si on a l'aspect catalogue on a l'aspect gestion du panier, si on avait créé une équipe au début c'était le cas d'ailleurs Amazon fonctionnait comme ça qui faisait tout pour gérer cette expédition de livres on commence à comprendre qu'on va créer beaucoup de latence et donc l'idée c'est que en suivant cette fameuse on comprend la loi de Conway mais on fait la manoeuvre de Conway inverse c'est à dire qu'on va structurer les équipes différemment, donc avec ces two pizza teams pour que au final elles ne puissent pas faire plus que ce que 8 personnes peuvent faire et donc finalement oui elles vont gérer alors même pas le panier Amazon parce que c'est très compliqué mais un bout du panier Amazon, et un bout du catalogue et ça sera une autre équipe et par contre elles sont indépendantes donc comment tu vas t'organiser, c'est pour ça que je disais qu'on ne résout pas tout avec Git mais l'aspect organisation des équipes est hyper important pour avoir une efficacité, qui est adaptée.
Bruno:
[42:11] Mais du coup quand on a mettons on a été à une entreprise avec, plusieurs dizaines de développeurs qui sont forcément pas tous dans la même équipe donc t'as un ensemble de squads qui sont répartis ils ont pas au final il y a un code commun qui est poussé en prod, tu penses que avec, on a 10 squads tu penses que tu peux avoir 10 squads en trunk based development ?
Olivier:
[42:43] Je ne sais pas trop où est le souci. En fait, la question, c'est plus du périmètre de ton équipe.
Bruno:
[42:48] Parce que du coup, ils vont tous quand même comiter sur la même branche. Donc, il y a quand même un moment où...
Olivier:
[42:53] Oui, alors, d'accord. Donc, effectivement, en fait, c'est la question du... C'est quoi le périmètre de ton repo de code ? De ton dépôt de code. Donc, c'est connu que dans certaines entreprises, il y a un dépôt de code pour... Donc, c'est ce qu'on appelle du mono-ripo pour tout le monde. Donc oui c'est possible d'avoir une grande équipe avec un repo de code, c'est un certain nombre d'avantages ça demande un outillage par dessus qui est hyper important, alors c'est un outillage au niveau du, ce qu'on appelle les sparse checkouts, on peut juste faire un check out un check out de, ce qui nous intéresse et pas de l'intégralité du repo c'est connu aujourd'hui Windows c'est du mono repo, c'est un mono repo, donc il faut imaginer ce que c'est que Windows et puis il y a certains produits Google qui sont aussi monoripo donc ça demande d'outiller énormément ce que tu fais y compris au niveau de la CI et donc, c'est possible, je pense que quand tu as une équipe, ou en tout cas tes produits qui sont volumineux comme ça, tu peux te permettre d'investir dans cet outillage là, la question c'est est-ce que tu veux investir dans cet outillage là parce que tu es un Amazon un Google, un Facebook, ou est-ce que tu veux passer ton argent en fait. Et donc peut-être que la structure d'équipe va te permettre d'avoir quelque chose qui est plus isolé mais en même temps qui va fonctionner et qui va répondre aux besoins.
Bruno:
[44:22] Parce que dans l'extension de cette fameuse loi de Conway, en fait comme justement tu reproduis le système à l'image de tes systèmes de communication interne, de ton organisation, Si t'es en mono-repo, t'as plus de chances que tes équipes communiquent entre elles, parce que tout le monde travaillant sur le même repo, effectivement, t'es obligé d'avoir quand même une communication entre les équipes. Là où si tu dis chacun son repo, tu favorises aussi le silotage, et donc tu favorises le fait d'avoir un système où les trucs sont hyper silotés, avec du coup des lacunes de communication entre environnements.
Olivier:
[44:59] Donc complètement et en fait ce silotage ça se gère aussi avec quasiment des API et en fait c'est ce qu'on appelle je ne connais pas l'analogie en français mais c'est ship your orc chart, donc en fait t'as ton organigramme, et les produits que tu vas sortir sur le marché ça va être un reflet complet de ton organigramme et à AWS on est assez connu, et on voit qu'on a des services qui sont, alors certains services sont assez énormes il y a beaucoup de développeurs qui travaillent dessus on a des services assez unitaires où c'est vraiment très peu de développeurs dessus qui non seulement développent mais qui aussi opèrent les solutions donc c'est, ça va se refléter sur ton produit au final et comment tu organises nous c'est bien parce que voilà finalement on fournit des, tu te souviens de l'analogie sur le panier de fruits voilà donc on fournit ça, c'est plutôt des services élémentaires, des briques de Lego alors que d'autres solutions peuvent être beaucoup plus complexes et plus importantes.
Bruno:
[46:06] Sur ces différentes stratégies que tu as évoquées encore une fois, il n'y a pas un classement ni les 5 seules stratégies qu'il faut appliquer d'ailleurs dans la liste, il y en a une que tu semblerais vouloir plutôt disparaître, est-ce qu'on peut passer de l'une à l'autre et si oui, est-ce que est-ce que tu penses qu'il faut mieux éviter de changer trop fréquemment ou au contraire il faut être prêt à s'adapter, est-ce que dès que tu sors un nouveau projet il faut être capable de se dire ok là on va changer de fonctionnement.
Olivier:
[46:36] Ouais je pense que le passage déjà tu restes dans le même outil donc c'est pas, comme si avant on était passé entre CVS Subversion, Git, Perforce que sais-je encore, Synergy, Clearcase mais donc déjà on a potentiellement on va retrouver les mêmes branches et les mêmes outillages donc si on reste dans Git, et je ne dis pas que Subversion est mort d'ailleurs, mais, il y a vraiment des aspects intéressants de Subversion, mais si on reste dans Git, on peut changer.
Olivier:
[47:07] Quand est-ce qu'on doit changer ? C'est effectivement quand la stratégie de branche qu'on a utilisée nous pose problème, et on voit qu'il y a une technique qui va faire que ça va être un souci. Très souvent, on On commence avec du Feature Branch, en ayant des features qui ne soient pas longues dans l'implémentation, donc avec des branches plutôt courtes. Le nommage feature branch n'est pas bon, ça serait bien que ce soit plutôt des time branch, où on a une branche peut-être au maximum au niveau de la semaine, qui est une segmentation, la journée c'est idéal, mais qui est une segmentation dans le temps. Donc on commence généralement comme ça, et ensuite on va se dire, c'est problématique, on n'intègre pas correctement, on a cette latence que je te parlais avec les pull requests les merge requests et on va commencer à se poser la question du trunk based, et cette fois on va commencer à et ça veut dire quoi, ça veut dire aussi réarchitecturer souvent l'application pour mettre en place des future flags, pour mettre en place une notion de plugin par exemple, donc d'amener des fonctionnalités pas parce que le code monolithique, doit être, shippé d'un seul bloc mais avec des plugins ou des interfaces amener ces fonctionnalités-là au fur et à mesure. Et donc, souvent, le trunk-based, je pense, est l'état ultime.
Olivier:
[48:33] Mais c'est toujours possible de transiter d'un modèle à un autre. J'ai souvent le cas d'équipes et de clients qui étaient sur GitFlow, parce que quand même, aujourd'hui, c'est encore quelque chose qui est très, très populaire, et qui... Au moment, dans le temps, à partir d'une release donnée, en fait, ils ont bien tout mis dans main et qu'ils sont passés soit sous du feature branch ou sous du trunk-based. Mais il y a eu un effort de réarchitecture de l'applicatif derrière et de la CI et des aspects déploiement, qu'on parle de déploiement progressif, pour que ça soit possible.
Bruno:
[49:11] Donc on ne change pas du jour au lendemain, il y a quand même un... il faut le préparer.
Olivier:
[49:15] Non, parce qu'en fait, la complexité d'avoir des branches, que ce soit dans le guide, dans le code ou ailleurs, elle est là savoir où tu la mets, où tu la déplaces, pour que ce soit plus pratique en gros où tu mets le bouton dans les mains du développeur ou dans les mains du product owner ou du commercial, ça va forcément toucher à l'architecture de l'application donc il y a du code à faire donc c'est pas.
Bruno:
[49:39] C'est pas anodin Dans toutes ces stratégies qu'on a évoquées il y a majoritairement le, comment j'ai du mal à former ma question on est sur le, comment on fait travailler plusieurs personnes sur le même code ce qui est clairement un des avantages premiers du versionning mais c'est pas le seul avantage du versionning le versionning c'est aussi une capacité de faire des rollbacks, c'est aussi une capacité de pouvoir on va dire mieux maîtriser l'évolution de ton code, est-ce que tu penses que parmi les différentes stratégies qu'on a évoquées est-ce qu'il y en a une qui est peut-être plus adaptée à ce genre de choses ou qui porte plus de complexité sur des notions de par exemple de rollback, ou est-ce qu'il faut à ce moment là envisager plutôt une autre, une sixième stratégie.
Olivier:
[50:32] C'est intéressant parce que ce qu'on n'a pas, Autour de Git, il y a un univers. Donc on n'a pas parlé déjà du nommage des versions. Donc il y a aujourd'hui quelque chose qui est très populaire qui s'appelle Semver, donc le Semantic Versioning. Et l'idée du Semantic Versioning, c'est donc tu as des versions en X.Y.Z, donc 1.3.0, sachant que tu as un majeur, un médium et un mineur. Ton mineur, c'est, tu vas l'incrémenter, donc le dernier chiffre dans ce trio, tu vas l'incrémenter quand tu as du bug fixe ou quelque chose d'assez de mineur, tu vas incrémenter le deuxième chiffre quand tu vas avoir des nouvelles fonctionnalités donc en fait avec ta numérotation de version tu vas signaler à l'extérieur à tes dépendances ou en tout cas les gens qui dépendent de toi donc tes clients mais ça peut être d'autres micro services ce qui se passe en fait à l'intérieur du code donc des fixes des fonctionnalités et puis le majeur c'est quand tu vas casser ta rétro-compatibilité où là tu ne peux pas adopter juste cette version-là, sans rien faire, il faut étudier.
Olivier:
[51:40] Donc quand tu fais des versions avec Git donc tu vas numéroter ces versions-là et une bonne idée c'est d'utiliser le Semantic Versioning je crois que c'est semver.org aussi pour ceux qui cherchent à se documenter, pour expliquer comment ça va se passer une autre connexion il y a un autre élément dans l'univers de la gestion du code c'est comment tu mets à jour tes dépendances, tu as toute un tas de dépendances tu vas avoir des dépendances au niveau de tes briques logicielles de tes SDK, tu peux avoir des dépendances au niveau de ta librairie de InfraAS Code par exemple, de Terraform qui va changer de version ou CDK qui va changer de version, des dépendances au niveau de tes jobs CICD.
Olivier:
[52:24] Et tout ça tu veux le mettre à jour mais de façon gérés mais automatisés parce qu'en fait on sait que, du code auquel on ne touche pas, ça ne vieillit pas comme le bon vin, ça vieillit plutôt comme le lait, et donc il y a un moment, ça va poser problème donc il faut le mettre à jour, tout code doit être mis à jour et donc cette gestion des dépenses c'est l'important il y a des outillages comme Renovate par exemple qui vont te permettre de, potentiellement tu peux dire tous les mineurs je les prends automatiquement et donc tu vas avoir des manage requests qui vont être, pas renovés, tu as un outillage comme ça où il y en a des équivalents mais qui vont être qui vont te proposer les changements et qui vont te permettre de mettre à jour sans prendre de risque sur ton produit final. Donc ta question c'était par rapport à, Est-ce qu'il y a des choses, des stratégies de branches qui sont plus amènes à durer et à pouvoir gérer tout ça dans la durée ? Je pense que le trunk base...
Bruno:
[53:29] Tu as une préférence quand même.
Olivier:
[53:30] J'ai l'impression que ça se voit, oui. Et le feature branch, mais du moment que tu arrives à taguer et que tu as une discipline sur comment tu tag tes versions, va te permettre d'avoir un univers autour qui va te permettre d'être confort sur ta pratique du SDLC et ses mises à jour et de gérer ça. Et donc de ne pas travailler en isolation, de dire, tu vois, on est le 1er janvier 2025, je fais un cut et je prends ces versions-là de tout ça, et ça, ça reste là jusqu'en 2035. Non, il faut réussir à le prendre en compte. Donc ça va être important de pouvoir gérer ça et bon, la stratégie.
Bruno:
[54:05] Pour terminer, j'aimerais revenir sur un point que tu as évoqué, sur la gestion de la complexité qui vient plus ou moins avec Git, où tu parlais des tailles d'équipe, tu disais que ce n'était pas forcément nécessaire d'avoir de Git. Alors peut-être que je grossis un peu le trait, mais est-ce que pour toi quand on est 1, 2, 3, 4, 5, est-ce que tu penses qu'on peut se passer de Git ? Est-ce que tu penses qu'il faut se passer de Git ? Est-ce que pour toi il y a une taille minimale sur un projet de dev à partir.
Olivier:
[54:39] Duquel il faut se dire là maintenant il faut Git mais avant c'est pas nécessaire, je vois pas donc j'ai aussi des projets solo je connais beaucoup de développeurs qui ont des projets solo, pourquoi se passer de Git en fait il y a tellement d'avantages, aujourd'hui déjà Git est open source donc potentiellement si t'as un NAS ou un Raspberry à la maison et que tu veux vraiment que ça reste chez toi tu peux quand même héberger git, c'est pas un souci, et ça amène beaucoup de choses autour, on en a parlé tout au long, donc non, aujourd'hui c'est pas comme si avant on avait à payer des outillages, très chers et très compliqués à maintenir aujourd'hui c'est hyper accessible, donc c'est aussi pour ça que d'ailleurs on se pose plus trop la question et qu'aujourd'hui donc non, aujourd'hui il ne faut pas se passer de git ou en tout cas d'un gestionnaire de code avec Git.
Bruno:
[55:35] Et si on choisit de ne pas prendre Git parce qu'on n'a pas envie de faire comme tout le monde, parce que pour des tas de raisons valables ou pas, ce serait quoi pour toi le contender, le concurrent que tu suggérerais ?
Olivier:
[55:50] Ouais, alors déjà je pense qu'au niveau de la gestion du code, il y a des alternatives.
Olivier:
[56:00] J'allais dire, la guerre est finie. Je ne sais pas si les autres ont capitulé, mais il y a beaucoup d'outils qu'on voyait, qu'on ne voit plus. Aujourd'hui, on voit principalement Git quand même. On arrive à voir ce version, donc SVN. Et SVN va être surtout dans... Git est notoirement mauvais sur la gestion des gros fichiers. Donc, il y a des mécaniques comme LFS pour gérer des gros fichiers. Mais par exemple, quand on a des projets industriels où on doit gérer peut-être des images binaires ou des vidéos de référence, des choses comme ça. Donc on peut les mettre dans des dépôts différents pour gérer des versions comme Artifactory, Nexus, il y a plein de choses, mais des fois on a besoin de les gérer à côté de son gestionnaire de code et Git là-dessus, ce n'est pas super. Donc on va trouver SVN dans des... Alors, ce n'est pas génial SVN pour gérer des gros fichiers, mais c'est un peu mieux que Git. Et puis SVN aussi dans des cas ou sur des projets industriels où il n'y a pas eu nécessité de migrer vers Git, et d'ailleurs Git supporte l'API de SVN, enfin je pense qu'on peut faire des commandes SVN avec Git, en tout cas ça a existé pendant un temps ça, mais donc SVN se trouve aussi quand on n'a pas voulu migrer.
Olivier:
[57:23] En bac, je pense que la question, ce n'est pas tant Git, ça va être surtout la plateforme au-dessus, GitHub ou GitLab ou Enalyn, Tulip. Qu'est-ce que tu mets au-dessus ? Parce que Git, en tant que tel, ça ne suffit pas. Il faut aussi autre chose. Après, ça, ça va dépendre. En France, moi, je vois beaucoup plus de clients utiliser GitLab aux US ou souvent ailleurs, c'est plutôt GitHub. Bon, c'est un constat. Je ne dis pas que c'est une règle. En tout cas, c'est ce que je vois.
Bruno:
[57:58] Très bien. Merci beaucoup, Olivier, pour cette discussion. J'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast. La première, c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeurs ?
Olivier:
[58:09] Oui, oui. Alors, je lis un peu. Mais il y a toute la littérature d'un éditeur qui s'appelle IT Revolution, où il y avait le projet Phoenix, Phoenix Project, Unicorn Project, il y avait notamment Accelerate c'est presque une bibliothèque entière, de superbes références y compris un bouquin de Matthews Kilton et de Manuel Pais qui s'appelle Team Topologies qui est vraiment excellent et puis c'est sans oublier, plus récemment je peux vous parler d'expérience développeur et de plateforme engineering tout ce qui est cloud stratégie et plateforme stratégie de Grégoire Hoppe qui est vraiment quelque chose à la fois rigolo à lire, et je fais un petit teaser, on est en train de travailler pour mettre ça en français, pour économiser quelques cellules.
Bruno:
[59:03] Très bien et la question la plus importante est-ce que tu veux plutôt espace ou tabulation ?
Olivier:
[59:09] Alors je suis espace juste un petit anecdote là-dessus, il y a une étude qui a été faite par Stack Overflow sur tous les développeurs et ça a été prouvé à l'heure, corrélation n'est pas causalité, mais que quand tu as été espace, tu étais quand même mieux payé que quand tu as l'étabulation. Ah oui, c'est vrai.
Bruno:
[59:28] On me l'avait envoyé forcément.
Olivier:
[59:29] Je crois que la différence, c'est à 43K et 59K sur le salaire médian. C'est significatif.
Bruno:
[59:34] Il commence à être significatif. Non, alors, j'avais vu ça, mais forcément, il y a des moyens de l'expliquer. Et pour le coup, moi, les stats que j'ai sur le podcast, alors peut-être que mes invités ne sont pas assez bien payés, mais moi mes stats sont plutôt tant penches plutôt pour tabulation que pour espace mais après parfois ça fluctue je crois que si je fais des stats par année il y a aussi des, mouvances merci beaucoup Olivier pour cette discussion autour de Git.
Olivier:
[1:00:08] Merci à toi Bruno, merci à tous.
Bruno:
[1:00:10] Merci à tous d'avoir écouté cet épisode j'espère que vous avez donné des idées.
Bruno:
[1:00:15] De stratégie Git de formaliser un peu des choses parce que ça c'est un point qu'on n'a pas forcément évoqué avec Olivier, mais c'est important de formaliser des usages avec son équipe, et c'est un choix d'équipe, il n'y a pas une bonne ou une mauvaise façon de faire c'est un choix global d'équipe mais donc c'est important quand même de formaliser les choses pour être sûr que tout le monde s'y retrouve à un moment.
Bruno:
[1:00:37] Donc voilà, j'espère que vous avez donné du coup des billes pour formaliser les choses d'un côté ou de l'autre et aussi, moi comme toujours, je vous remercie de partager ce podcast autour de vous je vous souhaite une très bonne fin de semaine je vous dis à la semaine prochaine et d'ici là, codez bien.
