Bonjour à toi chers compagnons et bienvenue dans ce nouvel épisode dans Solo.
Si tu ne l'as pas vu sur Youtube j'ai publié pas mal de vidéos et notamment une qui est
une émission de bonne pratique sur Geet.
En l'occurrence celle dont je vais te parler aujourd'hui c'est quel flux de développement
Geet choisir.
Suite à cette vidéo j'ai eu pas mal de commentaires Youtube et notamment un qui a attiré mon attention
c'est celui de Thayer.
Thayer en fait il me dit qu'il a ici les trois flux que je présente, les trois flux
de développement et il a toujours les mêmes problèmes que ce soit le flux qui l'utilise.
Le plus important c'est que au moment de merger dans develop ou dans master il a des
conflits de fusion.
Il en a beaucoup.
En fait il me dit qu'il a des features un peu complexes et qu'il doit toujours avec
son équipe faire un choix entre deux choses.
Soit un faire une branche dans laquelle il va publier son code, à chaque fois une longue
branche dans laquelle il ne va pas pouvoir faire de code review et du coup il va diverger
le master.
Soit la deuxième solution c'est faire des petites branches en cascade sur lesquelles
on peut faire des revues mais qui il a du mal à merger dans le bon sens.
Donc j'ai des solutions puisqu'il y a eu pas mal de commentaires et puis j'en ai discuté
avec des amis développeurs et du coup je t'en parle juste après une petite chose
que je voudrais aborder avec toi c'est aujourd'hui on vient de dépasser les 1500 abonnés sur
Youtube donc la seule chose que j'ai à vous dire c'est merci.
Du coup merci de me suivre, merci d'être de plus en plus nombreux à suivre ce podcast
et puis à suivre Youtube puisque il y a plein de gens qui suivent ce podcast uniquement
sur Youtube donc merci à vous et puis si vous faites partie des personnes qui sont pas
abonnés et qui suivaient la chaîne abonnez-vous ça fera plaisir et puis surtout ça montrera
quel audience j'ai.
Du coup on va revenir sur cette question de Théhir qui a des fonctionnalités un peu
complexes.
Il le dit lui-même il a des fonctionnalités complexes donc ça ça veut dire une chose
c'est que quand on a des fonctionnalités complexes on a des longues temps de développement.
Le temps de développement il se compte en jour voire parfois en semaine c'est quelque
chose qu'on a beaucoup dans l'infrastructure on a beaucoup de features qui sont longues
mais pas parce qu'elles sont longues à développer mais parce qu'on a plein de choses à tester
plein de choses à découvrir et surtout par exemple quand on fait l'infrascode, quand
on déploie les machines ça prend un petit peu de temps mais une feature elle doit pas
être trop trop longue non plus et ça veut dire aussi une chose c'est que si la feature
elle est complexe il y a beaucoup de codes sur beaucoup de fichiers et du coup ça impacte
fortement la base de code et ça veut dire que évidemment tu vas avoir des conflits
de fusion à résoudre au moment où tu vas faire le demande de fusion ou un merge.
Donc ça c'est des vrais problèmes donc comment est-ce qu'on peut résoudre ces problèmes
là parce que ce qu'on veut c'est se faciliter la vie et résoudre ces problèmes.
La première chose que j'ai à dire c'est qu'en fait quand on fait une fonctionnalité on crée une
branche et la branche elle doit avoir une durée de vie de 2 à 3 jours vraiment maximum.
3 jours c'est même beaucoup on va dire 2 jours avec la journée de revue mais plus long déjà ça a plusieurs
impacts c'est que si c'est plus long que 2 jours notre cerveau il va avoir du mal à suivre on va
avoir du mal à se concentrer sur la fonctionnalité et du coup on va se perdre et comme on va se
perdre on va faire beaucoup de choses et on va avoir du mal à se replonger dans cette base de code
surtout ça fait 4 jours qu'on y est on va en avoir un peu marre.
Donc pour ça la meilleure chose à faire c'est simplifier les fonctionnalités qui sont complexes
il y a forcément un moyen de les simplifier. Si la fonctionnalité est trop complexe qu'elle
dure plusieurs journées il y a des choses qu'il faut qu'on sort de la fonctionnalité soit c'est
l'esthétique soit c'est je sais pas moi une fonctionnalité annexe dont on n'a pas besoin tout
de suite et qu'on peut traiter dans une deuxième carte ça c'est vraiment la première chose à
faire c'est changer l'état d'esprit et ne plus se dire que la fonctionnalité est trop complexe
mais penser à comment est-ce qu'on peut morceler cette fonctionnalité en plein de petites
fonctionnalités alors on me dit oui mais la fonctionnalité est vraiment complexe et des fois
on voit pas comment la morceler mais si en fait il y a forcément un moyen en fait il faut garder
à l'esprit un principe qui est hyper simple c'est le principe kiss le principe kiss je le rappelle
tout le temps à ceux avec qui il travaille avec moi c'est qui pide stupide simple donc garde-le
simplement stupide c'est à dire que la fonctionnalité doit être la plus simple possible et c'est pas
grave si elle fait pas beaucoup de choses on en rajoutera une puis une autre puis une autre et
à force on aura une vraie grosse évolution du code peut-être qu'en fait la fonctionnalité que
tu es imagine c'est peut-être un milestone ou une étape qui est faite de plein de petites
fonctionnalités je sais pas je connais pas le contexte mais c'est comme ça que j'aborderai que
j'aborderai la chose une autre manière de voir les choses c'est toujours en gardant cette idée
d'une branche doit être très courte deux jours maximum et toujours en gardant le principe kiss c'est de
faire le développement petit à petit ça veut dire qu'on prend le développement on analyse le cas
d'usage on analyse la story et en fait on code en code vraiment le coeur en fait avant la présentation
ça veut dire que on va les coder les dépendances on va les coder parce qu'il y a forcément des
modules à créer avant de pouvoir faire des actions avant avec l'utilisateur par exemple on
code toute la logique métier dans plein de petites cartes de fonctionnalité sans qu'elle puisse être
appelée c'est à dire qu'il n'y a pas de lien avec l'interface et une fois que tout a été mergé
correctement testé correctement on va coder la fonctionnalité dans une nouvelle carte et c'est elle
en fait qui va activer la fonctionnalité alors ça ça peut se faire de plusieurs manières soit en
effet en codant du code et en ne laissant pas l'utilisateur la possibilité de taper les codes
soit en utilisant des features toggle ou des features flag donc des drapeaux de fonctionnalité ça
veut dire qu'en fait on va coder la logique métier et en fait on va on ne va pas activer ce code c'est
à dire que le code il sera déployé il sera il sera fusionné dans la branche master mais il sera
jamais activable parce que le drapeau de fonctionnalité il est à faux et du coup jamais le code il
passera par là donc ça c'est une autre méthode qui permet de réduire vraiment les les fonctionnalités
vraiment trop complexe parce qu'il y a forcément des choses qu'on peut faire en une petite fonction une
petite méthode une petite librairie plein de petites librairies et après on balance on balance le tout
on balance la sauce donc pour ça je vais vous mettre un article sur les features toggle
n'hésitez pas à aller le lire et à expérimenter ça chez vous dites moi ce que vous en avez si
vous l'avez essayé si vous avez pensé à ça déjà si vous avez d'autres techniques pour justement
réduire la taille de vos fonctionnalités et du coup ne pas avoir des conflits de fusion à résoudre en
pagueil parce que si vous avez trop de conflits de fusion à résoudre vous allez vous perdre surtout
si quelqu'un d'autre a modifié la base de code et qui a impacté en fait ce sur quoi vous êtes
en train de travailler j'espère que vous allez pouvoir réjoudre votre problème de conflit de fusion
mais est ce que vous êtes déjà posé la question de la sécurité de votre code si vous n'êtes pas
encore posé la question de la sécurité de votre code je vous propose d'écouter un autre épisode
de podcast que j'ai fait pour vous qui est en solo numéro 2 ton code source est-il vraiment en
sécurité va l'écouter et puis tu m'en diras des nouvelles merci d'avoir écouté radio dévops
n'oublie pas de noter l'épisode plus la note sera élevée et plus sera mis en avant dans les
applications tu peux aussi le partager ça nous aidera à le diffuser et à rendre le mouvement
plus visible si tu as envie de discuter du mouvement alors rejoins nous dans la communauté des compagnons
du dévops à bientôt la baladeau diffusion des compagnons du dévops est produit par l'hydra