Hervé Lourdin, Benoit Lafontaine
Transcription
Bonjour à tous.
Bonjour.
Bienvenue. Ah, on est en train de... C'est pas bien ça.
Hein?
C'est pas bien fait.
Pardon?
Je vais vous montrer ça. Alors, on fait pas mal. Hop.
Femme, chef, chef.
C'est pas grave.
Ça, ça a marché.
Presque. Allez.
On va faire comme ça. Et là, on bat le truc.
Voilà, c'est super.
C'est bien Google.
Bon.
Eh bien, non, mais non, ça me revient.
Ok, on va vous parler de... Ça va être une presse un peu dans la continuité de ceux qui étaient déjà dans cette salle tout à l'heure, un peu plus technique, moins purement méthodo, mais quand même très connecté à ça, qui va parler des stratégies de versionning et de leur impact sur les dynamiques d'équipe. Donc on en douceront deux à faire cette présentation.
Benoît Lafontaine, directeur technique Octo Technologies.
Et Arnaud Urbain, CTO chez Vite Dressing.
Alors, pourquoi cette session? Non, on va commencer tout de suite. Comment nous est venue cette idée?
Est-ce que vous savez qui c'est?
C'est qui?
C'est ça, c'est ce qu'elle a dit, c'est Melvin Colway. Donc ce monsieur, en 68, avait une super idée, une grosse révélation, il a formalisé sa loi. qui est la suivante, qui dit que les organisations qui font des systèmes, on va dire des logiciels, ça va nous arranger, sont contraints à produire des systèmes qui copient ou reproduisent leurs systèmes de communication. Alors si on s'arrange un peu avec tous ces mots-là, qu'on fait moins compliqué, souvent on se dit, en gros, les organisations répliquent, enfin on retrouve nos organisations dans les structures, dans le design du code qu'on produit. En tout cas, notre organisation a un impact assez fort sur la façon dont on fait notre code. Donc ça, ça nous a beaucoup inspiré, ça a inspiré plein de gens. Et ça a amené pas mal de réflexions, notamment on a bien compris que la façon dont on allait s'organiser quand on fait un projet, quand on crée plusieurs équipes agiles, allait avoir un impact assez direct dans la façon dont on allait faire notre code, dans notre time to market. Et donc du coup, on a essayé vraiment de courir après, de trouver les bonnes lignes de fracture les plus élégantes entre nos équipes, à constituer des équipes
dites cross-fonctionnelles, dans lesquelles on va retrouver plutôt toutes les fonctions d'entreprise, du produit jusqu'au développement, au test, à la mise en prod, pour éviter justement de créer ces silos trop forts qui vont avoir un impact sur la façon même dont on conçoit notre code. Bon, ça nous a donné quelques idées diverses et variées. On s'est dit avec Benoît, mais en fait, ces histoires de future team, component team, etc., vous avez peut-être entendu parler, c'est bien, mais il doit y avoir aussi d'autres choses qui influent sur la façon dont on travaille. dans la rapidité à laquelle on réalise un logiciel et la façon dont on communique ensemble. Et on pense que les stratégies de versionning, de gestion de notre code, ont probablement elles aussi un impact sur la façon dont on communique. Donc là, c'est un peu dans l'autre sens. Et on s'est dit, bon, allez, investiguons sur cette voie-là. On ne sait pas trop ce qu'on va trouver. Mais on pense que ça doit avoir un certain impact. Alors du coup, très humblement, on a fait appel aux gens qu'on connaît ou qu'on rencontre. Donc on a été rencontrer plein de personnes qu'on connaissait dans notre entourage ou avec qui on a eu le cas de travailler.
Et qui ont travaillé sur pas mal de projets différents, sur des entreprises différentes. Donc on n'a pas étudié en détail l'ensemble des pratiques de chaque entreprise, mais on a appris à chaque fois des projets dont on a entendu parler, sur lesquels les gens sont intervenus. Donc c'est des petits extraits de différents projets des sociétés. Et on n'ira peut-être pas non plus dans le détail de chaque société, on ne nommera pas forcément, parce que des fois on n'a pas le droit de les nommer, mais on a essayé de regarder un panel assez large de projets.
Ce qui est assez intéressant, c'est que ça a combiné nos petits liens du web, du mobile, des technos assez variés. Du coup, on a eu un panel qu'on trouve... représentatif, on a envie de continuer, on a appris des choses. Et c'est ce qu'on se propose de partager avec vous, c'est de regarder ce qu'on y a appris et de le partager avec vous.
Mais pour commencer, qu'est-ce qu'une branche ? Donc ça c'est un peu la première question, si on veut causer branching, versionning, écho, et tous ces mots barbares, affreux, qu'est-ce que ça peut bien être?
Alors du coup, on est bien élevé, on va d'abord regarder sur Wikipédia. Donc sur Wikipédia, ça dit la chose suivante. En gestion de configuration logicielle, une branche est une dérivation dans l'histoire de l'évolution des éléments de configuration. Une branche est une évolution d'un élément ayant pour origine une version précise, produisant une branche de version. Une branche de version correspond à un axe d'évolution de version. Elle est rattachée à une branche source et peut en découler sur plusieurs sous-branches. La gestion de l'ensemble des branches et des versions d'un produit constitue le versionnage et est l'objet de la gestion de configuration. Ok. En cours, une branche, c'est ça. Donc, voilà, vous avez plusieurs versions qui vont s'enchaîner. Puis, à un moment donné de la vie de votre projet, pour des raisons diverses et variées, votre code va dériver sur une autre version, une version alternative. Alors là, on a pris le cas où, à un moment donné, on a commencé à vouloir préparer le futur et puis travailler sur une version 2.1+. Et on a fait une branche.
Alors, si vous regardez sur le web ce que c'est que des branches, il y a des débats infinis sur ce que c'est, comment ça marche, qu'est-ce qu'il faut faire, etc.
On va essayer d'aborder les différents modèles de branches qui existent, parce qu'on va voir que ce n'est pas juste ça forcément. Donc du coup, Benoît et moi, on s'est... Zardé, il y a une autre propre définition des branches, qui est de dire une branche, c'est une version alternative du code source d'un logiciel.
Très simple. À un instant T, le logiciel a une version alternative de lui-même, enrichie ou modifiée, ou peu importe, et on va convenir pour la simplicité de cette présentation que c'est ça une branche. Pourquoi? Parce qu'on va voir les branches très formelles telles qu'on les a vues juste avant, mais il y a d'autres types de branches. Il y a des branches qu'on appellera implicites, qui sont par exemple une version du logiciel qui vit en local sur le poste d'un développeur, mais qui n'a pas encore rencontré une autre version, qui n'a pas encore été confrontée à une version sur un serveur centralisé ou à celle d'un autre développeur. Et puis il y a encore d'autres types de branches qui sont ceux-là beaucoup plus vicieux, qu'on abordera un peu plus en détail, donc on dira branchés par abstraction. Donc exploiter une version alternative du logiciel en production. Donc deux versions alternatives du logiciel vont vivre à un instant T. Alors vous pouvez commencer à réfléchir à différents cas d'usage de ça, on le verra juste après. Mais voilà, tout pour vous dire que finalement, ce n'est pas juste une branche qu'on a tirée dans un serveur SVN ou Git, ça peut être d'autres choses. Donc on va s'attacher à dire qu'une branche, c'est une version alternative du code. Merci.
Alors, deuxième question, pourquoi on branche en fait? Pourquoi on fait ça? Alors, pas juste parce qu'on a envie de se complexifier les distances. Vraisemblablement, la plupart des personnes qui ont été amenées à faire ça répondent tous pour les mêmes raisons. La première, c'est parce que quand même, on aimerait bien pouvoir être un peu tranquille pendant qu'on fait notre travail et ne pas avoir à s'enquiquiner avec la version du collègue qui est en train de faire un autre truc pas pareil que moi.
C'est la première raison. Et puis souvent, quand on commence à creuser, une autre raison, c'est tout simplement, j'aimerais pouvoir livrer les choses au fur et à mesure, sans pouvoir m'embêter à tenir compte de ce que
mon voisin est en train de faire, mais il n'a pas terminé, donc du coup, je ne vais pas l'attendre, je vais pouvoir envoyer tout de suite. Et donc du coup, c'est une des raisons majeures aussi qui nous amènent à vouloir créer cette version alternative du code dans un endroit un petit peu plus isolé.
Le problème des branches, c'est que qui dit branche, dit à un moment donné qu'il va falloir merger. Et ça, c'est le grand moment où tout le monde se rencontre. C'est le moment où on dit, ok, il y a des versions alternatives qui cohabitent ensemble, il va falloir les faire se rencontrer. Et ça, c'est le moment le plus important. Donc on parlera beaucoup de branches, mais on va aussi beaucoup parler de merger, c'est-à-dire faire se rencontrer les deux versions alternatives pour n'en réaliser, n'en laisser qu'une seule à la fin, celle qui sera exécutée en premier.
Une fois qu'on a partagé ce vocabulaire-là, on peut continuer. Et on va regarder les différents modèles de versioning, slash branching au sens très large du terme qu'on a rencontré chez ces différents acteurs, et quel impact sur la communication.
Alors tout d'abord, je vais vous présenter celui qu'on appelle le tronc. Finalement, c'est une stratégie de branching qui vise à éviter les branches, justement. En fait, on va essayer d'avoir au maximum de travailler sur la dernière version à jour du code, donc de partager tout. Concrètement, finalement c'est ça. Donc si on a deux développeurs qui travaillent ensemble, j'en prends deux pour la simplicité, on a une première version, et puis il y a le développeur B qui fait quelques commits, enfin qui fait des modifications, et qui va les pousser en centrale sur le master. À ce moment-là, l'autre développeur et les autres développeurs doivent récupérer cette version pour la fixer en local, et pour pouvoir travailler encore eux leur côté, et pour pousser ensuite leur développement par la suite. Ce qui est intéressant de voir, c'est que finalement, à un moment, on va se rencontrer pour dire« bon ben là, on aimerait bien faire réaliser en production, ou en tout cas montrer ça quelque part». Et comment ça se passe dans les équipes qui utilisent souvent cette technique? C'est que finalement, on lève la tête, on dit« moi j'aurais envie de pousser, est-ce qu'on est tous d'accord que ça marche? » Et là tout le monde se regarde et dit« ouais, moi c'est bon, j'ai fini, ou c'est un état plutôt stable, donc on peut y aller». Il y a peut-être quelqu'un qui dit« Ah non, attendez un petit peu, parce que là, j'ai poussé quelque chose qui ne marche pas forcément, donc attendez-moi, je fais un commit dans une heure et puis on repart. » Donc, on parle de communication. Finalement, ce pattern-là, ce qu'on voit, c'est que c'est souvent des équipes assez réduites, 10 personnes ou moins. donc parfois plus, mais la plupart du temps c'est ça, qui sont généralement colocalisés, ou en tout cas qui communiquent très facilement entre eux, pour pouvoir justement résoudre tous ces conflits qu'ils ont assez régulièrement, rapidement et d'une façon assez collégiale.
La plupart du temps, ça s'appelle trunk-based, ça vient plutôt du répertoire SVN, et après, dans les slides, on voit souvent master, qui est plutôt la définition git, mais sinon, c'est la même chose, c'est d'avoir vraiment un flux continu de commits, et tout le monde, au fur et à mesure des développements, essaye de pousser. Donc ce qu'on voit aussi dans les équipes, c'est que forcément, comme on a une intégration continue, qu'on n'a pas envie d'embêter tout le monde, les développeurs se forcent quand même à pousser des modifications qui sont relativement stables, et en tout cas qui ne font pas casser tous les tests unitaires, sinon ça embête tout le monde et tout le monde est bloqué. Ce qui fait que Hervé parlait de branches implicites. Si on a un développeur typiquement qui fait une grosse tâche et qui ne commite jamais, on a une branche qui commence à durer dans le temps sur son poste local. Qu'on soit sur n'importe quelle gestion de versionning, c'est pareil.
Expérience du coup ce genre de patinage c'est en fait ça marche si c'est une petite équipe qui communique super beaucoup ou alors on l'a vu dans des contextes où il y avait beaucoup beaucoup de personnes mais ça marchait parce qu'il y avait une qui était extrêmement développée avec des tests dans tous les sens, où globalement, l'objectif était de jamais, jamais, jamais la casser. Et donc du coup, un, d'avoir du tooling, et deux, d'avoir des commits qui soient extrêmement fins, pour réussir à s'insérer au fil de l'eau. Donc ça a pas l'air plutôt simple, et d'éviter les branches à tout prix, d'une certaine manière, mais ça a une conséquence. Ça marche bien à pas beaucoup, ou alors à beaucoup, il faut avoir une rigueur d'exécution dans la taille des commits et dans la façon de... d'outiller le build très très poussé.
Autre chose aussi, c'est que tous les projets commencent par ça. Moi, je n'ai pas vu encore de projet qui commence avec une stratégie plus élaborée que ça. Mais par contre, au bout d'un moment, et ça, typiquement, on a un projet en interne chez Octo qui fait ça, c'est que pendant très longtemps, ils étaient trois, ça marchait bien. Et après, ils rencontrent des développeurs, enfin, il y a d'autres développeurs qui intègrent l'équipe. Et là, ils se disent, ah, on n'a plus la même confiance qu'on a avec notre équipe actuelle. Et du coup, on se met en place d'autres stratégies de branche.
Alors, c'est un peu l'histoire, c'est qu'à un moment on se dit, bon, ce serait bien qu'on suive un petit peu notre propre chemin pendant un certain temps avant de se rencontrer.
La première pattern, qui est plutôt un anti-pattern au final qu'on a vu, c'est au final d'essayer d'isoler des développeurs entre eux ou des équipes de développeurs. Donc l'idée, c'est de se dire, on a quand même plein de choses à faire, il y a deux équipes qui n'arrêtent pas de se marcher dessus, donc on va les... les isoler sur deux branches différentes, comme ça elles vont pouvoir vivre leur vie plutôt tranquillement, et on se réunit à la prochaine release, donc là on parle de cycles d'habitude plusieurs mois, c'est plutôt ça qu'on voit, on essaye de se réunir dans plusieurs mois, et puis à ce moment-là on fera cette étape de merge, de fusion de code, et on mettra en production. Donc ça c'est plutôt la théorie, parce qu'en pratique ce qui se passe, c'est plutôt ça. Bon alors déjà les deux mois là ils ont glissé parce qu'ils ont dépassé à 3-4 mois, et à partir d'un moment il y a quand même une équipe qui arrive tant bien que mal à avoir son périmètre fonctionnel couvert, et à avoir quelque chose de plutôt stable. Mais il y a l'autre équipe qui, peut-être qu'elle était à peu près stable un peu avant, mais maintenant elle a commencé le développement et donc elle, elle est dans une situation un peu compliquée. Donc peut-être qu'elle n'a pas fini. Mais en plus, quand elle essaye de merger son code avec l'autre équipe, l'équipe B, là ça ne passe pas. Donc ils se disent, finalement, c'est un peu compliqué de finaliser, c'est un peu compliqué de merger, tant pis, on recule notre date d'intégration à la prochaine fois.
Donc déjà, personne n'est très content, mais voilà ce qui se passe. La prochaine fois, donc 2, 3, 4 mois après, ou plus, il faut quand même faire ce merge, parce que les deux équipes sont quand même arrivées au bout de leur périmètre fonctionnel. Et là, c'est vraiment le merge de la mort, c'est-à-dire que quand on a deux versions de code alternatives qui ont divergé pendant plusieurs mois, ça devient très très compliqué. Et surtout que comme personne...
Tout le monde était objectivé sur leur périmètre fonctionnel. Finalement, personne n'avait pris en compte le coût du merge après. Et à chaque fois que peut-être qu'il y a des développeurs en temps en temps qui viennent, ce serait peut-être quand même bien de merger. À chaque fois, il y a souvent l'organisation qui dit« maintenant ça, on verra après, là vous êtes en train de perdre du temps». Un petit peu comme les réflexions autour du TDD qu'on avait vu un petit peu avant. Mais souvent c'est ça. Donc quand vous voyez des gens qui commencent à partir sur du team branch, heureusement ça arrive de moins en moins, ça reste un anti-pattern parce qu'on n'arrivera jamais à remerger les équipes.
C'est une poursuite du trunk base. En fait, on a rencontré un contexte où il y avait du user branching. Finalement, personne n'avait pris en compte le coût du merge après. Et à chaque fois que les... Peut-être qu'il y a des développeurs de temps en temps qui disent« Ah, ce serait peut-être quand même bien de merger. » À chaque fois, il y a souvent l'organisation qui dit« Ben non, ça, on verra après. Là, vous êtes en train de perdre du temps. » Un petit peu comme les réflexions autour du TDD qu'on avait vu un petit peu avant. Mais souvent, c'est ça. Donc, quand vous voyez des gens qui commencent à partir sur du team branch, heureusement, ça arrive de moins en moins, ça reste un anti-pattern parce qu'on n'arrivera jamais à remerger les équipes.
Et autre autre...
C'est une branche un peu alternative qu'on a rencontrée.
C'est une poursuite du trunk base. En fait, on a rencontré un contexte où il y avait du user branching. Alors ça veut dire quoi? Ça veut dire qu'à un moment donné, tous les utilisateurs sont en train de tirer une version du trunk, du master. Ils l'ont chez eux en local. Ils ne créent aucune branche. Ils vivent pendant très très longtemps avec ça. Et en fait, ils vont créer un autre repo, un autre master, mais qui va être un master d'équipe. Et ils vont faire un jeu de couches individuelles vers ce master d'équipe. Donc, ce n'est pas officiellement une branche, mais c'est un peu comme si, en fait, on avait décidé de faire dériver le master pour une équipe donnée, d'intégrer ensemble un intérieur de ce repo d'équipe pour pouvoir le déployer dans un environnement alternatif. Et exactement pour les mêmes raisons qu'a décrit Benoît, les équipes vont continuer à vivre ensemble autour de cette place de repo, qui est une branche d'équipe un peu virtuelle. Et puis à un moment donné, les deux équipes ou trois ou N qui doivent mettre en prod ensemble pour faire une seule version du soft, vont essayer de se rencontrer et de faire le merge. Donc c'est une façon de brancher, de team branching qui est un peu plus implicite, mais qui est basée là-dessus. En l'occurrence, ça marche rudement bien ce genre de pas super bon pattern avec des technos comme dites. Parce que du coup, on peut vraiment vivre sa vie avec le duplicat du repo, faire du push-pull entre les repos, entre les utilisateurs, et puis s'arranger à trouver une version stable d'équipe. de la déployer sur ce petit environnement, petit repos des réposteurs et d'équipes qui va venir après un serveur d'intégration d'équipe. Et ça, qu'est-ce que ça nous dit en dynamique d'équipe? C'est que, en fait, c'est un pattern qui est hyper vicieux parce que l'équipe, elle, elle ne se rend pas compte qu'elle prend des risques parce qu'à l'intérieur de l'équipe, la communication, elle est généralement plutôt bonne, les anges parlent entre eux, ils commettent autour de leur branche d'équipe, ils vivent leur vie. Et le problème, c'est quand des équipes A, B, X, Y, Z vont avoir envie de se parler les unes avec les autres. Et c'est là que le meurtre de la mort va arriver, pour son nom. Donc du coup, c'est un pattern de communication qui est vicieux. On se sent bien, on est en sécurité, on communique super bien à l'intérieur de l'équipe. Par contre, cross-team, on ne communique pas bien. Et on peut pour autant avoir des équipes très agiles. Il faut avoir des équipes qui vivent leur vie. Et à un moment donné, elles vont devoir se retrouver, ces équipes A, B et C.
Donc finalement, après, qu'est-ce qu'on essaie de... L'autre, en tout cas l'autre pattern de branche assez général, qui sera la base aussi pour les autres un peu plus complexes, ce qu'on verra par la suite, c'est le future branche. Donc sur le papier, ça ressemble à peu près à un team branch, sauf qu'au lieu de faire la séparation sur les hommes et les équipes, on fait la séparation sur les futures. Donc il y a une mini équipe qui prend en charge, soit une personne, soit plusieurs personnes, mais qui prend en charge cette feature et qui travaille dessus.
Pareil de l'autre côté, et à un moment, comme tout à l'heure, une fois qu'on a fini, et c'est là où c'est intéressant, c'est qu'on n'a pas essayé de délimiter le temps. extrêmement, mais on l'a délimité autour de la feature. Donc ce matin aussi dans la keynote, il parlait de cadence. Là, on arrive à faire de la cadence autour de la feature.
Donc une fois qu'on a cette feature qui est finie, on peut la pousser, en tout cas la tester, la valider, la pousser, en prod ou avant. Et pendant ce temps-là, on a une autre feature qui vivait sa vie, qui, juste au moment où la feature B arrive en prod ou sur le master, la feature 1 doit faire ce merge de cette feature et est obligée, enfin ça c'est quand même les bonnes pratiques, de le faire, de faire son merge du master pour après pouvoir se remaser. Pourquoi c'est possible dans ce cas-là et pas possible, en tout cas on le voit moins souvent sur les parties team branch, c'est que là encore une fois, on cadence sur la feature et on peut faire en sorte que notre organisation produise des features de taille réduite. Donc tout à l'heure je vous parlais, c'était souvent plusieurs mois, en tout cas ce qu'on a vu c'est plusieurs mois de développement, là on parle de quelques jours ou deux semaines maximum. C'est un petit peu ça les délais qu'on attend. Et donc tant qu'on arrive à avoir ces branches de durée un petit peu plus courte, là ça marche. Donc mon exemple de tout à l'heure où il y avait une petite équipe de trois personnes qui ont intégré des gens, l'idée c'est vraiment ça, c'est de se dire, typiquement il y a le développeur rouge là-bas qui vient d'intégrer, car pas encore tous les standards de dev, qui souvent quand ils commettent, ça fait péter l'intégration continue. Donc il faut... encore un petit peu l'accompagner. Et donc, avoir ces features branches, ça permet d'isoler les différents développements. Et dès qu'on a une feature qui est OK, on peut la pousser en production. Et on accompagne l'autre développeur pour intégrer les bonnes pratiques, corriger, etc.
Ce qui est bien avec ce pattern, c'est que ce n'est pas du tout un pattern technique, parce que finalement, on voit qu'on est à deux doigts d'avoir fait la même chose que dans l'exemple précédent. C'est plutôt la façon dont vous allez faire vos sprint planning, ou si vous êtes par une directive, vos user stories, avec quelle finesse vous allez les découper, et comment vous allez, entre développeurs, repartir le boulot. Vous utilisez le système du branching, une solution technique aussi rudimentaire que le team branching, il n'y a rien de super évolué derrière ça. Par contre, la contrainte, c'est que vous avez le droit de vous écarter du tronc commun qu'à l'échelle de temps d'une fonctionnalité. Idéalement, une user story, si on veut pousser le vice un peu plus loin. Donc là, ce n'est pas la technique qui va dicter ce modèle, c'est plutôt les pratiques méthodaux et de communication d'équipe et partage du travail qui vont permettre de soutenir ce pattern. Et pour le coup, c'est l'abri la plus élémentaire qu'on va retrouver après dans la plupart des autres.
Et pour finir sur ce pattern, l'avantage c'est qu'après on peut faire tourner les équipes et assurer une dynamique et une communication entre les personnes. Alors que tout à l'heure on figeait finalement les équipes.
Donc on passe tout de suite à un gros morceau qui est finalement le guide flow. Pourquoi est-ce qu'on part directement dessus? Parce qu'en fait, la personne qui a mis ça sur le papier n'a rien inventé, elle a juste mis ensemble plein de bonnes pratiques qui se faisaient sur différents projets. L'avantage, c'est qu'ici, on a une vue globale. Donc qu'est-ce que c'est? Ça part du constat que sur le master on n'a que le reflet de la production, donc que les livraisons complètes, et qu'on a une branche qui s'appelle develop sur laquelle on fait toutes nos modifications de code au fur et à mesure.
Donc on utilise exactement le même pattern qu'est la future branche de ce côté-là. Dès qu'on a une story, on fait une branche, on code dessus et on la rapatrie sur cette branche développe.
À ce moment-là, il est que l'équipe se dit, maintenant qu'on a un périmètre fonctionnel qui se tient à peu près, ce serait bien de mettre en production. Sauf que la plupart du temps, à ce moment-là, ça prend quelques semaines, quelques mois. Donc on a une phase d'intégration et de peaufinage. De tests manuels pour vérifier que tout va bien et qu'on n'a pas oublié de trous. Donc on crée une release branch qui permet à une partie de l'équipe de peaufiner cette release, de faire les derniers ajustements, pendant que d'autres développeurs commencent déjà les releases de la version suivante ou continuent des features qui dureraient un petit peu plus longtemps. Donc on a cette branche de release, et une fois que l'équipe est contente, elle est mise en production. Et le cycle continue. Et on a une dernière branche qui est hotfix, parce que là je vous ai parlé de 1, 2, 3 mois, sauf que dans la vie il y a des bugs régulièrement en production, suivant votre... Suivante production, mais dans la vie, il y en a de temps en temps. Et donc, on a une branche spéciale pour dire, là, je suis en train de résoudre le bug, j'arrête tout, je résous un bug, je fais cette branche à côté, et je pousse directement en production, et en rapatriant, bien évidemment, la modification sur notre branche développe. Donc ça c'est assez complet. Si vous cherchez une base pour avoir à peu près tous les cas possibles, C'est pas mal et c'est pour ça qu'il y a une assez bonne adoption dans les équipes. Ce qui est intéressant de voir, il y a deux choses.
Ces pratiques ont été instaurées historiquement, souvent par les produits qu'on livrait. Physiquement en CD, etc. Pas trop pour le web, parce qu'on a ces branches de release qui peuvent être assez fortes, assez marquées.
Alors aujourd'hui, il y a beaucoup de web, donc de temps en temps, on se dit, mais à quoi servent les release branches? Il y a quand même un cas qu'on voit, et à chaque fois, ils utilisent ce pattern-là, c'est finalement tout ce qui est mobile. Parce que même en mobile, même si on a envie de livrer en continu souvent, on est limité par les stores et les équipes sont limitées par les stores. Ou par exemple, à chaque fois qu'on balance une nouvelle version sur l'Apple Store, vos notes reviennent à zéro. Du coup, pour garder des notes correctes sur l'Apple Store, on est obligé d'avoir un temps d'environ deux mois. Sur le store, enfin c'est ce qui se pratique généralement. Donc forcer le cycle de release à deux mois. Donc même si l'équipe est assez mature, assez encambant, etc. Pour avoir des petites features qui développent tous les jours et qui s'intègrent sur cette branche développe de façon très régulière, ils forcent à avoir des branches de release pour justement cadencer en fonction de leurs intentions.
Ce qui est intéressant, c'est que... Justement, si on se dit, les releases branches, peut-être qu'on n'en a pas besoin parce que nous, on arrive à avoir des features assez petites, à avoir notre organisation qui teste au fur et à mesure ces features. Et finalement, dès qu'on passe sur Develop, nous, on envoie en production. Ça, c'est ce qu'on a vu sur certaines équipes qui étaient parties là-dessus, et qui disent, tiens, pourquoi est-ce que finalement nos features, on ne les envoie pas directement en production? Donc là, ils enlèvent finalement cette branche de release, parce qu'ils ont pu ce temps d'intégration et de peaufinage des releases. Ils ont réussi à mettre ces actions dans leur cycle de feature et de développement de feature. Donc une fois qu'on a enlevé les release branches, il y a d'autres équipes qui disent« bah oui mais en fait les hotfix et les release finalement c'est la même chose». Parce que moi mes features là, je les calibre pour qu'elles se fassent quelques jours, généralement quelques jours, les hotfix finalement c'est une demi-journée, finalement c'est à peu près pareil. Et donc, dans cette dynamique, Hotfix et Feature Branch, c'est la même chose. Donc finalement, on a enlevé ces trois-là, parce que Develop, ça devient le Master. Et en fait, on revient sur un cas classique de Feature Branch ou de GitHub Flow qu'on va voir juste après.
Le truc qui est intéressant avec GitFlow, c'est que généralement, ce ne sont pas des petites équipes qui se mettent à utiliser ça. C'est souvent que les équipes commencent à toucher des limites dans la façon de se synchroniser avec d'autres équipes agiles. Je suis une équipe agile, je dis bien, j'ai commencé à faire du future branching, ou je suis resté entre une baisse, donc pourquoi pas. Puis au bout d'un moment, on a besoin de se synchroniser. Et puis d'ailleurs, pour des raisons parfois même pas techniques, juste marketing, on a besoin de faire apparaître la notion de release parce qu'en fait on va réaliser en même temps pour faire un effet d'annonce nos fonctionnalités cross-team. Et c'est pour ça qu'on va commencer à s'intéresser à des processus comme celui-ci. Parce que sinon, il est souvent trop sophistiqué, il est un peu trop compliqué à regarder comme ça. En fait, ce qu'on a constaté, c'est que les équipes qui ont besoin de synchronisation, qui sont plusieurs à travailler en agile, vont commencer à regarder un pattern type GitFlow pour travailler ensemble.
��tre capable de virer la branche de release ou être capable de virer la branche de hotfix, c'est généralement un symptôme de grosse maturité parce que ça veut dire qu'en gros, l'équipe se dirige très sûrement vers du delivery continu. Donc ils ont des dynamiques de testing, ils sont capables de bouler hyper souvent le code le plus frais sans avoir peur de péter les développements qu'ils sont en train de faire à ce moment-là.
L'histoire que vient de raconter Benoît, elle se retrouve dès lors où on sent que l'équipe est bien à l'aise avec ses modèles de versionning et a des pratiques derrière de build, de test automatisé qui sont assez avancées. Par contre, voilà. Ça permet à tout le monde de comprendre assez, parce qu'il est un peu touffu ce modèle, mais il est quand même assez simple à capter, et ça rassemble pas mal les équipes entre elles, et les arrêts ne peuvent pas se synchroniser. Par contre, on déconseille de prendre ça from scratch si vous commencez un nouveau projet sans avoir trop joué avec des modèles plus simples, parce que sinon c'est un peu une usine égale. Le truc marrant aussi sur ce modèle, c'est que si au lieu de le regarder à l'horizontale, qu'on le met à la verticale, il y a des trucs un peu intéressants qui apparaissent, ce qui m'a pas mal avec la ville, c'est que du coup on peut commencer à regarder, on dirait bien que les features branches ont une progress finalement, c'est toutes les fonctionnalités que je fais. Donc on a un indicateur, plus j'ai de features branches, plus a priori je suis en train de jouer avec un WIP important, mais globalement ça m'indique ce que je suis en train de faire à un instant T.
Si vous regardez, la développe, c'est probablement votre donne. C'est que vous avez commencé à réconcilier votre code à l'intérieur du tronc commun d'équipe. Donc si vos definitions of don sont bien posées, vous finissez dans le développe. Et puis si vous avez derrière des phases du AT dans lesquelles vous allez un peu scouer l'ensemble de vos développements pour voir si tout ça est très consistant fonctionnellement, ça ressemble bien à une release branch. Et pour finir live. Donc on trouve ça assez intéressant, c'est que si votre process agile reproduit ça, c'est un modèle, c'est un GitFlow et un modèle assez intéressant à implémenter. Et puis accessoirement, si vous avez des expédites, vous pouvez toujours les faire passer sur une branche hotfix, ça ressemble aussi de manière assez élégante à ce qu'on ferait dans un modèle Kanban bien respecté.
Un autre pattern qu'on a vu et qui est pas mal à la mode en ce moment, Avant de parler du modèle derrière de GitHub Flow, je vais parler d'abord de ce qu'a amené GitHub par rapport à Git.
Parce que, donc, pas beaucoup utilisé sur l'open source, aujourd'hui c'est un petit peu la grosse référence de tous les projets open source, et pas que. Mais en fait, ce qu'ils ont apporté, vraiment fondamentalement différent, c'est le fork. C'est cette capacité à dire, il y a un projet que je vois, donc probablement open,
En un seul clic, j'ai fait un clone de ce repo et je peux travailler à l'améliorer. Soit dans l'optique de détrôner le roi et d'être la nouvelle référence, mais probablement plutôt pour améliorer ce projet.
Et apporter sa contribution. Et derrière le fork, comme tout à l'heure on a dit, après le fork, il y a le merge. Et ce qu'a apporté aussi GitHub, c'est cette particularité d'avoir ce pull request et cette partie de review. Donc le pull request dans GitHub, c'est j'ai fait mon fork, je pense que j'ai amélioré de façon conséquente un projet, et donc je demande au dépositaire du repository Donc soit dans l'optique de détrôner le roi et puis d'être la nouvelle référence, mais probablement plutôt pour améliorer
ce projet et apporter sa contribution. Et derrière le fork, comme tout à l'heure on a dit, après le fork, il y a le merge. Et ce qu'a apporté aussi GitHub, c'est cette particularité d'avoir ce pull request et cette partie de review. Donc le pull request dans GitHub, c'est j'ai fait mon fork, je pense que j'ai amélioré de façon conséquente un projet, et donc je demande au dépositaire du repository.
d'intégrer mon code au sien, parce que c'est vachement bien. Et là, le responsable du projet voit toutes nos modifications, donc a des petits outils comme ça pour highlighter et pour voir ce qui a été modifié, et surtout peut engager une discussion. Et ça, c'est vraiment la partie importante. Si on se demande pourquoi la personne a fait, ou si on a des remarques sur son code, les standards ne sont pas respectés, il n'y a pas assez de tests, etc., on peut entrer en communication avec lui et échanger.
Pour après faire finalement cette étape de merge à la fin. Et au final, GitHub, comme pas mal d'autres éditeurs de solutions, ont fait leur propre flow. Et GitHub Flow, finalement, c'est... C'est ça. Donc c'est exactement la même chose qu'une feature branche, sauf qu'on a cette étape de pull request où on demande à quelqu'un d'intégrer son code au master. Et surtout, on a cette partie de code review.
Donc on le voit sur tous les projets open source sur GitHub ou GitLab ou Bitbucket, mais aussi c'est ce qu'on voit sur des équipes, même petites pour le coup, qui se disent, la code review c'est quand même une partie importante de notre activité, on ne le fait pas encore assez bien, et donc on se met cet outil-là et ce flow-là, pour s'obliger finalement à avoir ce code review, cet échange entre nous autour du code pour s'approprier le code, etc. Avant finalement de le balancer sur le master.
Le truc marrant, c'est qu'à l'origine, c'est vraiment GitHub qui a dicté le mouvement via l'open source, mais c'est qu'aujourd'hui, la plupart des entreprises privées commencent à instancier à l'intérieur. Alors, soit ils prennent un compte sur GitHub de manière privée, soit elles instancient des serveurs. Donc, il y a Atlassian, ceux qui font Jira, qui ont Bitbucket Server, ou GitLab, qui a un projet à la base open source qui est aussi hébergé. Et ils intègrent ça à l'intérieur de l'entreprise pour pouvoir amener tout le monde à rentrer dans ce modèle d'échange. Et ça, c'est assez nouveau, parce qu'avant, vous ne le voyez finalement que dans la version open source, parce que les gens sont normalement très distants. Mais au sein de l'entreprise, maintenant, on reproduit ce pattern de l'open source qui provoque une communication au moment du merge. qui l'outil en faisant un truc incroyable, une espèce de forum globalement autour d'un fichier. Enfin, ce n'est pas une révolution techno. Mais par contre, on a une convention d'échange entre développeurs qui invite à la discussion avant de faire cette fusion. Alors pour les équipes distribuées, ça marche vachement bien. Mais pas que. Là où avant, il y a deux personnes qui pouvaient s'arranger autour d'un merge, maintenant, il y a tout le monde qui voit ce qui se passe, la conversation avec les collègues. Et on reproduit à demeure ce pattern qui était plutôt... Réservé au monde de l'open source.
Et c'est vraiment ça, parce qu'il y a une petite équipe chez Octo, sur laquelle j'ai travaillé, où avant on était en trunk base, et les code reviews on les faisait, vraiment c'était notre process, mais on les faisait quand on pouvait, entre guillemets, et après il fallait détricoter un petit peu l'ensemble des commits, vu que tout le monde avait commité l'un au-dessus de l'autre. Donc c'était un peu plus compliqué. Et donc cette équipe maintenant, ce qu'ils ont fait, c'est qu'ils ont mis en place ces arcanistes et fabricateurs, mais bon l'idée c'est la même, c'est qu'ils font leur développement sur une branche à eux, et après ils s'obligent à avoir le set code review.
De leur côté. Donc c'est vraiment pour obliger cette communication. Donc on parlait de communication et stratégie de branche. Là, c'est vraiment le truc important, c'est qu'en mettant en exergue ce pull request et ce code review, on force cette communication.
Un pattern un petit peu avancé sur des gens qui ne sont pas très loin d'ici, les furets. Alors eux, ils vont faire un truc assez compliqué sur lequel on va rester un petit peu au niveau, mais très intéressant.
Parce qu'en fait, ils font des... Au final, ils font des features branches. Je ne vous ai pas un livre historique, mais grosso modo, ils avaient une livraison tous les mois, et en fait, ils se disaient, tous les mois, c'est trop long. Et donc, on essaye d'accélérer ça. Donc, ils ont automatisé plein de choses. Et puis ils ont mis en place un process autour des futures branches qui est un petit peu complexe. Donc là j'ai honteusement pompé leur slide de DevOps qu'on ne voit pas, donc c'est pas grave. Mais ça c'est en ligne chez eux, il n'y a pas de problème. Ce qui se passe chez eux, c'est qu'en fait ils voulaient conserver l'avantage des futures branches pour pouvoir déployer de façon unitaire des branches. Mais en même temps, il voulait conserver un endroit unique où il y a toujours la dernière version de toutes les branches en même temps pour pouvoir tester manuellement cette intégration. Alors comment ils ont fait ça?
Donc ils récupèrent Branch Master, J'ai une fonctionnalité Ticket 3 à développer, je crée cette branche, je travaille, et à un moment, je pousse ma branche Ticket 3 sur un repo central qui s'appelle Features, sur lequel ce repo a l'ensemble de toutes les features en cours de développement. Et là, il y a un automate assez rigolo qui prend toutes ces features en cours de développement, quel que soit leur état, c'est fini ou pas, et qui fait ce gros merge, qui est un petit peu un merge unique, temporaire, qui n'a pas d'existence que d'être là, et qui le pousse en environnement d'intégration. Ce qui permet à tous les développeurs, à tous les testeurs, d'avoir cette dernière version en intégration et de tester continuellement cette version intégrée sur un environnement d'intégration.
Une fois que le développeur et l'équipe responsable des tickets est OK, ils se disent que ça passe en production, par une autre action qui soit la même. Qui pousse ses features, ses features branches, sur un autre repo. Et là, il y a le même automate qui finalement fait ce merge, mais que des tickets validés, qui fait ce merge pour pouvoir l'envoyer en production et rapatrier ce code sur le branch master. Donc la dernière flèche que vous voyez là.
Donc ça c'est assez malin, c'est assez joli. Il y a quand même deux choses pour lesquelles ça marche pas mal. C'est que leur organisation fait aussi que les tickets sont relativement séparés. Et donc il y a assez peu de conflits entre les tickets. Et la magie d'Octopus, c'est que lorsqu'il y a des conflits, les développeurs sont alertés, parce que l'automate ne peut pas les deviner tout seul, ces conflits. Et donc les développeurs sont alertés qu'il y a un conflit par exemple entre ticket 2 et ticket 3, résolvent le conflit dans Git comme n'importe quelle résolution de conflit, et le poussent dans cet automate. Et cet automate, quand il refait cette intégration, voit ticket 2, ticket 3, conflit, ah, je vois qu'il y a un développeur qui a déjà résolu ce conflit, et donc il fait passer cette résolution. Et donc ils arrivent toujours à avoir cette version consolidée à n'importe quel instant. Mais encore une fois, c'est vraiment intéressant parce que même si techniquement ils arrivent à résoudre les conflits, leur organisation, déjà les équipes sont séparées et travaillent plutôt sur des composants séparés. Donc ces équipes intrinsèquement n'ont assez peu de conflits et les équipes travaillent avec un WIP relativement réduit, donc il y a assez peu de tickets qui peuvent être en conflit les uns les autres.
En fait, si on prend du recul sur la combinaison de pratiques qu'ils ont, en fait, ils font deux trucs intéressants. Ils disent, on va future brancher à l'étrange. C'est-à-dire, dès qu'on fait quelque chose, pas, on future branche.
On crée un environnement, une espèce de branche développe virtuelle dans laquelle tout le monde va pouvoir déployer son code, même s'il n'est pas super fini, pour voir comment ça va cohabiter avec le reste des autres features actuellement développées. Et donc du coup, on va automatiquement merger tout ce qui arrive. Et en fait, ça amène un indicateur assez... intéressant et inattendu, on en a discuté avec une personne des Furets au port tout à l'heure, qui est qu'aujourd'hui ils ont une organisation qui est assez indépendante, c'est-à-dire qu'ils ont créé des feature teams qui ont des zones de recouvrement faibles. Donc en fait ils n'ont quasiment jamais de conflit. Pourquoi? Parce que quand ils font une feature, ça ne jarmonne que dans un périmètre relativement bien segmenté, et donc il n'y a pas de conflit, le merge le fait tranquillement. Quand en fait il y a un conflit, là les personnes lèvent la tête de leur clavier, ils ont reçu un message, attends ça ne marche pas, viens on se cause. Donc là, il y a une conversation qui apparaît et ils résolvent le conflit. Très bien. L'indicateur qui apparaît là, c'est que plus il va y avoir de conflits, plus on va avoir d'informations finalement sur l'organisation. Deux possibilités. Soit en fait on a une fonctionnalité qui est très cross, mais c'est ponctuel. C'est un projet qui est très transverse d'entreprise. Et ouais, celui-là, il va être un peu rude, parce qu'avec cette histoire de merge automatique, autant vous dire qu'on ne peut pas reculer. La sortie, c'est devant, on pense à merge tout le temps. Donc du coup, ils vont causer souvent, souvent, souvent, souvent. Mais ça ne s'arrêtera peut-être qu'avec le projet. Si ce n'est pas le cas, ça veut dire que globalement, l'entreprise est peut-être en train de croître, les fonctionnalités sont en train de bouger, le périmètre de l'équipe commence de moins en moins à être adéquat avec la façon dont on fait les fonctionnalités. Donc du coup, une espèce d'indicateur technique commence à dire, fais gaffe, ton organisation qui était plutôt élégante, qui n'avait pas trop d'adhérence entre équipes et qui du coup te permettait d'avoir un type de market assez intéressant, Il est en train de se dégrader parce qu'il y a des conflits de codes qui apparaissent de manière de plus en plus fréquente. Donc du coup, ce qu'on a trouvé élégant dans ce pattern-là, même s'il ne s'applique pas facilement à tout contexte, c'est qu'un indicateur très technique donne finalement un indicateur de santé sur les modes de communication inter-équipe et possiblement sur l'orga à date qui bouge tout le temps dans une entreprise. Donc voilà, on trouvait ce pattern intéressant. Encore une fois, il y a plein de prérequis à ça. Et si vous étiez en Scrum, ça serait un peu dur. Chez les Furets, ils sont en Kanban, donc ils font du flux continu. Donc en fait, ils n'ont pas d'unité de temps qui les contraint fortement à devoir se synchroniser entre eux, sauf s'il y avait une unité de rythme particulière, comme je disais tout à l'heure, pour des raisons marketing. Donc quand on est en flux continu sur du Kanban, ça, ça marche bien. Si c'était du Scrum, je pense que ça ne marcherait pas aussi bien. Et la deuxième chose, c'est que les stories, les features sont plutôt petits. La granularité est faible. C'est une des raisons pour lesquelles ça marche. Donc c'est pas magique, mais le pattern est assez inédit.
Deuxième pattern, enfin dernier pattern, on va commencer à revoir d'autres choses. On parlait tout à l'heure de façon de brancher par abstraction, c'est le feature toggling ou feature flipping. Donc qu'est-ce que c'est ce truc en fait? Donc c'est un pattern qui a été très très, comme on dit, remis en avant par Martin Fowler, il a écrit pas mal de trucs là-dessus, et puis tous les gens qui font du delivery continu justement cherchent à faire ça. Parce que d'une certaine manière, le 5 grades d'un delivery contenu, ça serait de revenir au premier slide de la présentation, ce serait de dire en fait on fait que du tron de baisse, comme ça on n'a pas de complexité liée à ces... branches qui doivent fusionner ensemble. Mais bon, quand même, des fois, notre code, il n'est pas fini. Donc, si on dit qu'on n'a qu'une seule version à un instant T et qu'on la shoot en prod, qu'est-ce que je fais de mon code pas terminé? Et donc, là, arrive ce pattern qui est l'idée de dire, finalement, si mon code n'est pas terminé, je vais l'entourer d'une condition, donc en gros, un if, pareil, on va parler de haute technologie ici, et on le désactive. Donc, on dit officiellement cette partie du code-là, tu ne l'exécuteras pas en prod. Donc, ça fait un peu peur, c'est-à-dire que globalement, on va envoyer du code pas terminé en prod, mais il ne sera pas exécuté. Alors, il se trouve que le feature flipping ou token flipping, ça a d'autres vertus, la b-testing, la capacité à exécuter du code sur une population segmentée bien particulièrement, parce que dans le IF, on peut mettre autre chose que des clauses de désactivation parce que le code n'est pas terminé. Mais dans cette conf là, on parle plutôt de cette pratique là. Donc, une autre façon de brancher qui est un peu vicieuse, c'est de dire, ok, j'embarque du code qui n'est pas encore terminé, qui est en cours de construction, pour lequel je n'ai peut-être pas fait tous les verges, toutes les choses qui vont bien, et je vais le désactiver. Donc ça c'est plutôt intéressant parce que ça permet de minimiser la complexité des branches. En revanche, d'expérience, et pour le coup on a un projet commun avec Benoît où on utilisait ça, du côté produit c'est génial, tout le monde est heureux d'avoir ce genre de super pouvoir au niveau du produit, non c'est trop risqué, je shoot en prod, désactive cette partie là, on y va, on a besoin d'avoir vraiment des super pouvoirs. Par contre, vous pouvez retrouver face à un code qu'il y a une succession de diffs qu'il va falloir maintenir, et autant vous... Si vous allez trop loin sur cette pente-là, ce n'est pas joujou. Ça n'est pas très agréable à manipuler. C'est un pattern qui est beaucoup utilisé notamment pour les gens qui veulent faire du déploiement continu. Il est intéressant, mais si on pousse un peu trop loin, il peut devenir un peu délicat à manipuler parce qu'il a trop de choses. Donc il faut être bien éveillé dans le code. Donc le gros équipe, croiser vos détours du regard, une succession de ifs, si vous n'étiez pas dans l'équipe qui a codé ça, il va falloir vite aller causer avec le coin.
Autre pattern un peu transverse, enfin là du coup l'idée c'est de vous dire, on a vu les patterns plus loin, il y en a quelques autres qu'on trouve plutôt être des anti-patterns qu'on a croisés et qui ne sont pas liés à un workflow en tant que tel, mais globaux. Le premier.
Le premier, c'est la branche qui dérive. Celui-là, à peu près tout le monde le connaît. Et quelle que soit la stratégie de version unique, que ce soit trunk-based, feature-branche, user-branche, dès qu'on a une branche qui dérive, finalement, c'est le symptôme d'un problème dans l'organisation. Donc tout à l'heure, quand on faisait des team branches, on voyait que l'organisation poussait aux branches qui dérivent. Donc on avait ce problème-là. On crée physiquement des équipes qui ne se parlent pas.
On a ça, récemment j'ai vu une équipe sur laquelle je suis intervenu, où je devais développer une fonctionnalité et comme on devait s'intégrer avec des services externes, j'étais obligé de tester en intégration. Et en intégration, je ne comprenais pas, j'étais obligé de faire des guides force-push, enfin push-force, En fait, j'étais obligé d'écraser ce qu'il y avait.
Et donc ça, c'était un petit peu dommage, je ne comprenais pas. Et je voyais qu'il y avait une autre personne de l'équipe qui faisait la même chose de son côté. Et à un moment, je me suis dit, ce n'est pas normal cette situation, pourquoi? En fait, je me suis aperçu qu'elle, elle avait sa branche en local qui avait dérivé depuis assez longtemps, qu'elle n'avait pas mergé depuis plusieurs jours ou peut-être plusieurs semaines. Et après, en creusant encore un petit peu, c'était quelqu'un qui venait d'arriver et sur lequel l'encadrement n'avait pas été bien fait. C'est-à-dire que je me suis dit, qui encadre cette personne? Parce qu'en plus, c'était un stagiaire. Et là, l'équipe s'est un peu regardée honteuse en disant, finalement, l'encadrement technique, personne ne s'en occupe vraiment. Donc c'est vraiment, encore une fois, un symptôme qui monte derrière des problèmes un peu plus profonds.
Donc là je parlais d'une nouvelle personne et d'un stagiaire, mais il y a un collègue Chocto que je respecte énormément, qui est très bon, mais qui m'a parlé de ce pattern-là, le moins de codeurs, et lui-même l'a fait. C'est-à-dire qu'il a mis en place sa petite équipe, il y avait 5-6 personnes, ils avaient des standards assez forts, des code reviews, du TDD, etc. Et à un moment, lui s'est dit, tiens, il y a cette fonctionnalité-là, celle-là elle est compliquée, ça va être mon sacerdoce, et puis je vais gravir ma montagne, et puis je vais l'attaquer tout seul de front. Comme je n'ai pas envie de ralentir tout le monde, j'y vais tout seul. Donc il a fait ça, il a fait ça pendant, je crois, deux semaines, c'est pas très long, mais au bout de deux semaines, il est revenu, il est redescendu de sa montagne en disant« Ouais, c'est bon, j'ai tout compris, ça marche, youpi! » Et le reste de l'équipe, pendant la code review, fait« Bah oui, mais là, écoute, on comprend pas grand-chose, en plus j'ai l'impression que ce test-là, il marche pas, et en plus ça respecte pas les standards que toi t'as écrits. » Donc là, il fait« Ah ouais, ok, ça marche pas». Et donc, le mode codeur, c'est une autre incarnation d'une branche qui dérive, c'est que lui, il a fait tout ce qu'il fallait, il a commité quand il fallait, mais il est resté tout seul dans son coin pendant un certain temps, donc c'est une autre forme de branche.
En termes de communication, il y a deux ou trois trucs qui peuvent quand même vous aider avec l'idée d'un mode de codeur, c'est au stand-up, globalement, ça fait longtemps qu'il raconte la même chose ou qu'il ne parle pas. Alors soit il dit toujours« oui, j'en suis toujours là, j'en suis toujours là» ou au contraire, il ne dit rien du tout, il se plante dans son coin. Si ça, ça arrive, a priori, il faut essayer de le rattraper parce que le moment du merde va devenir complexe.
C'est ça. Et on parlait du futur flipping, c'est pareil en fait. Même si on pousse notre code tous les jours, plusieurs fois par jour, et même qu'il est en production, mais qu'il est désactivé, et que personne ne l'a revu, personne ne l'a relu, personne ne l'a validé,
on reste dans ce pattern d'une branche qui dérive, même si elle ne se voit pas. Et là, encore une fois, ça se voit plutôt au stand-up ou sur le cambon, il y a toujours ce post-it qui ne bouge pas.
Donc, branche qui dérive, symptôme d'un malaise de l'organisation.
Moi aussi, heureusement, on commence à le voir de moins en moins souvent, c'est l'équipe d'intégration. Et l'équipe d'intégration, c'est souvent un remède aux branches qui dérivent. Et souvent, quand on a fait des team branches avec deux équipes qui ne se parlent pas, personne ne veut prendre la responsabilité du merge, parce que c'est compliqué. Et donc, on se dit, bah oui, mais comme le merge, c'est quelque chose de technique, ça, c'est souvent l'organisation d'en haut qui dit ça, le merge, c'est technique, donc, Faites-le à la fin. Mais finalement, comme ce n'est pas si technique que ça, on se dit qu'il faut une équipe d'intégration. Et comme ce n'est vraiment pas si simple que ça, on met souvent les meilleurs parce que c'est les seuls qui arrivent à tout comprendre de ce qui se passe. Donc au final, on a mis une équipe souvent de seniors et d'experts qui sont là uniquement pour faire un tâche qu'on considérait technique à la base. Donc c'est vraiment un anti-pattern et c'est surtout pas une résolution des problèmes. Et ça c'est vrai qu'à chaque fois qu'on a vu, sans une équipe mais des fois c'est une personne, une personne qui est chargée de l'intégration, ça à chaque fois ça marche pas. Donc ça aussi c'est un autre symptôme que si vous regardez, vous commencez à mettre ça en place ou vous voyez mettre en place, vous pouvez tout de suite arrêter et creuser.
Bon, on va terminer.
Deux conclusions, deux messages qu'on a à l'issue de nos rencontres, discussions diverses et variées. La première, c'est qu'on n'a pas vu une solution unique. Ce n'est pas comme si on sortait de la salle, on mettait GitFlow, ça va bien se passer. En fait, ce n'est pas ça. Globalement, les stratégies, il y en a pas mal. Souvent, on en change et on voit qu'elles sont adaptées au contexte. Donc en gros, dans la plupart des cas, notre conclusion c'est prenez des modèles qui ont l'air assez intéressants à votre prémématique à un instant T et adaptez-les à votre contexte. Il n'y a pas de solution ultime. Par contre, on voit qu'il y a des trucs qui ne marchent quand même régulièrement pas bien, ou il y a des choses qui marchent bien au début et qui ne marchent plus après. Et donc, de la même manière qu'une organisation va évoluer, les stratégies de versionning, il faut les faire évoluer aussi. Par contre, il faut monitorer la façon dont vous allez communiquer. Et sur ce dernier point, finalement on s'est rendu compte, c'est assez bête, mais merger c'est discuter. En fait, à partir du moment où il y a un merge, c'est l'élément de communication atomique entre les développeurs. On peut jouer longtemps tout seul, mais le moment du merge, c'est le moment qui provoque une communication. Donc tout l'enjeu, c'est de provoquer cette communication au bon moment. Ce n'est pas qu'il n'y en ait plus, parce que là, ça veut dire que vous avez trouvé l'ultime zen organisation sans conflit, mais on sait que ça existe. Donc peut-être que je vais se souvenir maintenant de l'organisation, mais je pense qu'on ne l'a pas vu. Et donc du coup, c'est plutôt savoir à quel moment il faut lever cette communication et provoquer ce merge-là. Et dans tous les cas, plus le merge est poussé tard, plus la résolution va être complexe.
Prenez votre process actuel, cherchez les points de merge, regardez s'ils sont trop fréquents, si c'est problématique et que vous auriez pu vous en dispenser. Peut-être qu'il y a des facteurs de changement organisationnel ou de process qui peuvent vous aider. Mais globalement, c'est en observant quand arrive les merges, le volume et la difficulté de résolution de conflits, que vous allez trouver les enseignements pour adapter un modèle qui pourra vous aider.
C'est à peu près tout ce qu'on a constaté. On n'a pas de formule magique, on a essayé de faire cette petite bibliothèque de patterns.