Bonjour à tous et à tous, bienvenue sur ce nouvel épisode de Double Slash, je suis Patrick
évidemment et comme d'habitude nous sommes avec Alex, salut Alex ! Salut Patrick, salut
tout le monde ! Donc un épisode un peu particulier, on va
parler de Mono Ripo, Mono Ripo, Alex ça te tient bien à cœur, ces derniers temps
tu as travaillé sur un gros projet sur lequel tu as travaillé avec un Mono Ripo, tu vas
nous faire un petit retour d'expérience là dessus, intéressant évidemment. La question
en fait du Mono Ripo elle est assez simple en fait c'est quand vous faites un projet
vous soyez seul ou en équipe en fait un moment donné vous avez forcément un bac, un front,
peut-être plusieurs applications aussi, une documentation etc. Et la question se pose
assez rapidement en fait de comment je vais structurer tout ça, est-ce que je fais plusieurs
ripos sur GitHub, est-ce que je n'en fais qu'un seul, est-ce que je regroupe tout etc.
Et voilà justement on va parler de tout ça avec Alex pour se poser les bonnes questions et
puis on va commencer peut-être par expliquer en gros ce que c'est un Mono Ripo et qu'est-ce que
ça apporte ? Oui carrément, carrément après il faut revenir aussi sur l'historique et comme tu
l'as très bien dit les projets deviennent de plus en plus complexes, il y a de plus en plus
en fait d'instances, voilà avant on avait un seul site internet ou une seule app et tout
était concentré, maintenant on a les sites marketing qui devient aussi de plus en plus
complexes, on a l'app, on a l'app front potentiellement pareil pour la partie back,
est-ce que on vient faire que du microservice, on fait du monolithique,
mais tout ça en fait comment on l'architecture en termes de code et où est-ce qu'on centralise
toutes ces informations là et surtout ce qu'il faut, ce qu'il faut, le gros avantage qu'on va
pouvoir mettre en avant sur un Mono Ripo c'est la centralisation, l'idée c'est on met tout dans
une seule code base, alors la légende dit que chez Google tout est centralisé sur un seul
ripo et que c'est du Mono Ripo donc si eux ils ont réussi à faire tourner tous leurs services
et tous leurs applicatifs sur un seul Mono Ripo, pourquoi en fait nous on pourrait pas le faire
alors qu'on a des projets qui sont vachement moins intéressants, beaucoup plus petits en
termes de scope, peut-être qu'ils étaient partis là dessus au début et puis ils n'arrivent plus en
sortir en fait, ce qui est sûr c'est que la plupart du temps et souvent mis à part s'utiliser
un truc la ravelle avec ou ta front elle back, un monolithique comme je dis, t'as souvent un back
déjà et un front séparé la plupart du temps sur le projet donc comment voilà et des fois des
personnes différentes en fait qui travaillent sur le back et des personnes sur le front,
exactement et un des premiers problèmes que tu vas avoir aussi c'est quand tu vas vouloir avoir une
équipe en remote et que tu vas bilder en fait potentiellement en fait t'en as un qui va qui
va faire, qui va bilder son applicatif sauf qu'il va pas être dans la même version et donc il y
va y avoir un qui va bosser d'un côté, ça va pas synchroniser avec les autres et donc en
termes de build déjà on va avoir un gros problème et aussi maintenant toutes les features en fait
vont être souvent back et front donc comment tu fais quand tu as deux applicatifs mais ta
feature elle vient prendre du back et du front il faut que ta code base tu vas jouer entre deux
codes base et il faut que ta feature elle match sur tes deux branches de guide pour que en fait
quand ton front et ton back elles se synchronisent et qu'elles soient mis en production à partir de
la même au même moment parce que sinon en fait ta tom back et ton front qui va pas être synchronisé
donc ça amène une autre complexité qui n'est pas insurmontable tu peux le faire.
Ouais ouais c'est intéressant ce que tu dis parce que là tu parles déjà de travailler en équipe
c'est vrai que comme tu dis en fait tu peux avoir des mecs en front qui vont devoir avoir,
ils vont demander des data au back donc le dev back va travailler sur le back et c'est vrai que si
tu as deux systèmes séparés donc il faut que tu mettes à jour le back, il faut que tu sortes de
enfin change d'engleter dans la console tout ça alors que si tu as un monoripo c'est vrai que tu
peux faire juste un guide pool et ça te met tout à jour tu relance etc tu récupères les comites
et tout de ce côté là c'est déjà plus simple pour synchroniser le back et le front quand on a
que ça. Après le gros truc c'est ça c'est juste une histoire d'organisation c'est un parti pris
mais en tout cas c'est des problèmes que le monoripo peut amener ça amène aussi autre chose mais
le gros gros gros la grosse idée sous-jacente c'est la centralisation de toutes les infos on a
toutes les infos au même endroit ça impose aussi à bien structurer à bien structurer tout ça on
va avoir justement des des des applicatifs des packages donc on va avoir pour mettre un vrai
exemple notre applicatif c'est notre site internet notre front notre back voilà ça c'est 3 applis
donc c'est 3 app mais on va avoir des packages parce que aujourd'hui si on fait si on fait du
type script ou un langage tipee potentiellement on va utiliser des fichiers type dans le front
et dans le back donc ce qui veut dire qu'il va falloir qu'on récupère ces types où on les construit
ou qu'importe mais sur le front et sur le back donc ça crée potentiellement en fait une source
d'erreur parce que le front et le back n'ont pas la même source et donc avec un monoripo on
centralise tout sur un package qu'on va appeler type comme ça en fait tout le type page va se
faire sur cette base et en fait la source de données c'est le package spécifique alors avant on
pouvait faire ça et ça a été le business model pendant très longtemps de de npm d'ailleurs de
faire des des packages privés et en fait on avait nos dépendances en fait vu que on avait plusieurs
applis toutes les dépendances en fait passées par un tiers qui était en fait npm et donc on
publiait nos packages privés et on les récupérait dans l'appli dans laquelle on en avait besoin mais
là maintenant avec un monoripo en fait on vient bilder nous même notre applicatif notre petit
package qu'on va utiliser dans la partie front dans la partie back ou sur le site internet et
et comme ça en fait bah ce package là il n'a pas besoin d'être bildé et publié sur npm il est
bildé une fois et il est au coeur du du du monoripo du projet et comme ça en fait si on a une si on
ici a une évolution on n'a pas besoin d'attendre de bilder ce package de le publier et en fait
bah toutes les applicatifs en nom directe hérite en fait directement de cette nouvelle de ce nouveau
package mis à jour après avoir des packages à publier en privé machin c'est complexif y
vachement quoi ça veut dire qu'il faut aller mettre à jour npm install machin update et tout
enfin les tomber quoi c'est beaucoup plus simple comme tu dis quoi et bien après c'est à partir
le moment où t'as qu'un seul projet qui est enfin où tous les projets sont réunis dans le
monoripo après si t'as plusieurs projets plusieurs monoripo là ça devient complexe complexe mais
oui c'est plus simple comme tu dis c'est clair que tu publier à chaque fois et puis tu tu vas
aussi avoir une centralisation au niveau de tes tests en fait quand tu lances tes tests bah il va
falloir que tu test ton front ton bac si tu veux faire du end-to-end bah en fait il faut que tu
test aussi tes packages et donc bah tu vas tester ton front ton bac ok et les la la feature globale
donc ça veut dire qu'il faut que tu buildes toutes tes applicatifs il faut que tu sois sur les mêmes
versions ainsi de suite ça amène d'autant plus de de problèmes et là en fait tout est centralisé
donc c'est plus facile en fait à être sûr qu'on est qu'on est les mêmes versions surtout quand
tu fais des nouvelles features sur lesquelles bah t'as un impact front et et bac ok ça c'est sur la
ça c'est sur la partie on va dire on va dire applicatif par contre tu vas avoir une autre
partie qui va être aussi juste de la config en fait tu vas tu vas pouvoir aussi partager l'un
par mutualiser et synchroniser toutes tes variables d'environnement en fait tes variables d'environnement
sur ton bac ton front parfois en fait elles sont un peu les mêmes mais bah là tu vas pouvoir les
mettre à un seul même endroit et elles vont être ventilées sur toutes les appliquées sur n'importe
quelle applicatif ou ou package qui a besoin en fait de cette de ces variables d'environnement mais
surtout tu vas aussi partager toutes tes linters par exemple ta ta ta config de us lint bah sur ton
site et sur ton application front potentiellement elle tu veux que ça soit la même ou de ton
linter de toutes tes règles de linter bah soit tu la tu les publie quelque part et tu les récupères
soit bah en fait elles sont au coeur du projet et bah tout tout tout tes applicatifs ont le même
règle on la même règle et donc tous tes développeurs qui ont accès qu'un seul ripot ont les mêmes
règles pour pour ce projet là et ce projet n'est plus un simple site mais un un package de sites
qui hérite de la même règle et donc tu écris une seule fois cette règle et elle est partagée sur
sur sur tout tout l'applicatif donc une règle pour les pour les linters ça va être super aussi
intéressant parce que tu vas tu vas pouvoir aussi partager bah ta config de ts donc de
typescript par exemple si tes sites ont projet et en full gs tu vas pouvoir partager toute ta
config de typescript qui potentiellement en fait peut être un peu compliqué ou touchy bah pour être
sûr en fait qu'on est sur les mêmes types de version bah pareil tu vas pouvoir mutualiser
en fait cette cette configuration mais ça c'est alors ce que tu dis c'est pour l'instant tu dis
ça simplifie beaucoup de choses c'est clair quand tout ce que tu racontes c'est c'est évident ça
simplifie beaucoup les choses par contre dans le cas où tu as les mêmes techno parce que faut
enfin on peut rappeler qu'on peut avoir un monoripo avec différents techno ça c'est aussi possible
dans ce cas c'est bah ça simplifie un peu moins les choses parce que si tu as un bac en PHP
la ravelle et puis le front en next ou des choses comme ça évidemment c'est moins synchronisé mais
on peut aussi faire avec différentes techno c'est c'est tout à fait possible oui les fins
ça va être beaucoup plus facile quand tu vas avoir qu'une seule un 15 langage par contre
aujourd'hui tu as des outils qui te permettent de faire du monoripo sur du multilangage c'est possible
ça existe alors personnellement je connais moins j'ai moins d'expérience là dessus par
compte je me dis que ça serait quand même possible de mutualiser plein de choses par exemple
ta ta tes types de ton API qui qui sont en PHP dernière génération ta ta toutes tes types
bah tu veux récupérer tes types côté en gs parce que tu t'as fait une applicatif front en ts
en type script donc tout est type et bah je pense que tu peux largement écrire un script qui va
prendre en fait tes types de PHP et qui va générer à la volée tes types de tes types côté en
type script et donc au final tu gardes cette même mentalité de synchronisation enfin de
nombre de centralisation de la source et après en fait tu vas pouvoir exécuter des scripts pour
bah pour faire ton passe d'un langage à l'autre voilà ça implique une gymnastique qui est un
petit peu plus complexe soit mais dans l'idée en fait on a ton script il peut faire la transition
d'un type à un autre d'un langage type et à un autre voilà c'est juste j'ai bâché marrant
que tu parles de ça parce que j'ai vu passer un outil il y a même pas une semaine justement
qui transformait je sais plus si ça transformait les la description des tables en type script
en fait je crois que c'est sur la ravelle que j'ai vu passer ça mais d'ailleurs il faut je
le retrouve t'es en pour apparaître dans les news mais comme quoi c'est possible mais après est-ce
que le monoripo tu vois ne force pas un petit peu à choisir tu vois à t'orienter plus sur des mêmes
langages je pense ça pousse un peu aussi là dessus si tu pars sur un monoripo non tu penses pas ou tu
t'en fous je sais pas tu vois parce que je te j'ai je me dis si de toute façon t'as déjà
t'as déjà un applicatif qui tourne sur piton bah de toute façon tu ne vas pas dégager tu ne vas
pas dégager pitton enfin tu vois donc en fait c'est tu vas plutôt essayer de de de si t'es dans
une logique de monoripo de centraliser et ok bah de voir comment tu peux en fait construire autour
de ça et l'idée en fait avant de se lancer dans un projet de monoripo c'est de dire ok
qu'est ce qui est mutualisable et surtout qui est ce qui est redondant qu'est ce que je fais à
chaque fois sur mon front et sur mon bac qu'est ce que je pourrais mutualiser pour gagner du temps
mais toute cette phase de test en fait elle est elle est assez assez puissante et assez énergivore
cette toute cette phase de build qui en amont de la phase de test elle est elle est assez redondante
et donc t'as plein plein d'outils aujourd'hui qui vont te permettre de d'exécuter des tâches
et toutes ces tâches là en fait vont être fait de manière en parallèle en fait on va on va lancer
différents différents types worker on va dire et tu vas pouvoir l'inité tu peux tu vas pouvoir
exécuter tes tests tu vas pouvoir builder tu vas builder ton ton package et il y a aussi une notion
de cache qui va être super intéressante c'est à dire que une fois que tu as buildé ton package par
exemple toi tu bosses et tu fais une petite librairie qui te permet de faire la synchronisation
de du type PHP au type type script et bah ce script là c'est un petit package qui est
vous tu vas exécuter ton bout de code sauf que quand toi tu vas le publier tu vas le comité tu vas
le build en fait moi je vais pouvoir récupérer ce build là parce que en fait tu vas pouvoir
mutualiser et synchroniser ton cache en fait de ton build ce qui t'évite en fait de rebuilder à chaque
fois à chaque fois à chaque fois donc en fait tu viens si tu as une équipe de 10 20 50 personnes
en fait chacun va builder son son applicatif ou son package qu'il est sur lequel il est en train de
bosser ça va être synchronisé sur sur un cdn classique et les autres en fait vont hérité de
ce build là ce qui fait que quand ils vont lancer leur applicatif ils vont pas être obligés de
rebuilder le nouveau package qui est utilisé sous le capot mais en fait ils vont hérité tout de
suite de du package déjà buildé et donc en termes de de puissance et de rapidité bah ça
va être beaucoup beaucoup beaucoup plus rapide ouais alors ouais tu parles du cache alors tu es
déjà un petit peu dans les outils on en parlera après mais ouais tu es déjà en avance mais ouais
mais oui il y a des outils justement qui permettent justement qui sont spécifiques à ces monoripaux
on en parlera dans la section outils est ce que tu penses alors moi ça me fait penser à des
expériences que j'ai déjà vu chez des clients tout ça est ce que tu penses qu'on peut à un moment
donné est ce que tu penses qu'il faut dès le début partir en monoripaux ou est ce qu'on peut
je sais pas au bout d'un an après tu vois tu as déjà lancé tes projets tout ça c'est
dire bah on a fait une connerie on aurait dû partir sur le même monoripaux et migrer au monoripaux
parce que en fait par expérience j'ai vu des choses assez hallucinantes sur des gens qui
justement regrettaient de pas avoir fait des monoripaux c'était le serverless ils avaient des
fonctions symphonies voilà et ce qu'ils avaient fait en fait c'était qu'ils avaient huit ou neuf
projets symphonies pour chaque fonction à ce serverless en fait ce qui fait qu'ils se retrouvaient à
devoir mettre à jour des versions de symphonie tout ça php et huit ou neuf fois à chaque fois
donc c'est assez fou tu vois et je me pose la question en fait est-ce que le monoripaux finalement
est ce qu'il faut partir dès le début ou alors finalement on peut y venir un an deux ans après
quand on se rend compte qu'on a fait la connerie et que alors moi je pense que ouais non c'est une
super bonne question je pense que plutôt tu pars sur une archi monoripaux plus ça va être facile
après après c'est jamais perdu par exemple là sur le cas que tu me donnes ouais ils ont huit ils
ont huit hippo guide avec huit c'est faux ouais ouais ça va c'est fou et là tu te dis putain
mec pourquoi tu peux pas mutualiser tu vois donc là là en fait sur ton exemple la l'utilisation
d'un monoripaux viendrait solutionner beaucoup beaucoup beaucoup de problèmes et la migration
elle va peut-être être compliquée souhaite mais elle va amener une réelle plus-value parce que
il y a quelque chose qu'on n'a pas encore évoqué mais c'est toutes les dépendances parce que là
tu as tu abordes le fait qu'ils ont huit instances avec huit c'est faux avec la synchronisation des
versions de symphonie qui doit être la même alors dans l'écosystème javascript on connaît déjà
en fait les workspace donc voilà on va qui en fait est-ce que c'est le monoripaux qui a développé
les workspace où c'est les workspaces qu'ont développé les monoripaux c'est le fou la poulre
ça je pourrais pas dire j'en sais strictement rien mais ce qui est sûr c'est que en fait tous ces
gestionnaires de de package en fait gère déjà les monoripaux de manière assez facile et tu peux
en fait synchroniser tes versions maintenant alors moi pour ceux qui le savent pas mais je suis plutôt
adeptes de pnpm et en fait aujourd'hui tu as une possibilité d'avoir un catalogue où tu dis
bah moi dans toutes les versions de je veux utiliser nukst ou redis machin client je vais prendre
telle version et tout mon être toutes mes applicatifs en fait vont être synchronisés sur
cette version là ce qui te facilite la vie mais de ma boule pour éviter d'avoir à faire la mise
à jour et de l'enfer que tu viens d'évoquer en disant ouais 8 instances de de de de de de de
de s'infos à mettre à jour il tu vas complètement mais te tirer une balle quoi donc ça ça marche
pour les dépendances mais ça va marcher pour les types ça va marcher pour les linters ça va
marcher pour les helpers tels et les petites fonctions en fait qui que tu vas utiliser un peu
partout je pense par exemple un formatage des dates un truc mais c'est basique basique mais tu
veux toujours formater les dates de la même manière et sur ton site internet et sur ton
application fronte bah tu veux que la date de la publication de ton blog elle soit formatée comme
ça bon et bah ce format ce formatage des dates au lieu de le mettre deux fois à deux endroits tu
vas le mettre à un seul endroit et tu vas pouvoir le synchroniser automatiquement donc si tu veux
tu vas tu vas pouvoir en fait utiliser cette mutualisation et cette cette ouais tu vas tu
vas centraliser tous les pouvoirs quoi donc pour ton histoire de s'infos ça serait tellement plus
facile c'est clair c'est clair un seul un seul compositeur en seul symphonie et puis après il faut
gérer un peu les routes quoi en fonction de la pays mais tu fais bien de partie parce qu'en fait on
est d'accord que quand tu fais un name space avec une pnpm n'importe quoi tes dépendances sont
chargées qu'une fois c'est à dire que si t'as plusieurs projets enfin si t'as plusieurs choses
qui utilisent vu ça sera chargé centralement vu et partagé entre les projets il va pas charger un
vu à chaque projet on est d'accord c'est ça le concept du name space ouais après en fait ton ton
ton ton workspace ton work et en fait tu vas dans ton paix ton pnpm c'est juste au moment de ton dev en
fait après au niveau de ton build bah de toute façon tu vas construire ton applicatif et ton
applicatif il va être il va être isolé après est ce que tu veux dockeriser le truc ou pas ça c'est
pas le problème mais c'est juste au niveau de ton dev tu vas centraliser toutes les informations donc
de toute façon on est bien d'accord que les monoripos c'est que dans l'univers du dev parce
qu'une fois qu'on est en prod bah c'est l'instance c'est l'intense l'intense l'instance de l'applicatif
qui vit sa vie toute seule par contre c'est toute l'expérience et la dix la développeur expérience
de comment je récupère les infos comment je récupère les configs comment je récupère les
les variables d'environnement comment j'exécute mes tests est ce que je suis sûr que tous mes tests
ont récupéré les bonnes versions pour être sûr que que que que que que que ça soit bon tu vois
il y a toute cette partie de de tests qui moi je trouve en fait ultra ultra importante et qui va
te faciliter en fait bah ton ton déploiement continue parce que en fait tout est centralisé au même
endroit quoi donc c'est beaucoup beaucoup beaucoup plus facile l'expérience développeur ce qui
est plus important de façon on est des devs un peu de casse pour les devs et comme je te vois pour
revenir au truc symphonie quand tu as huit ou neuf ripos à mettre à jour t'as l'impression de bah c'est
déjà pour le dev c'est super enfin ça n'a pas aucune valeur en fait comme travail parce que tu
fais une neuf fois la même chose en fait donc c'est clair que l'expérience développeur est
plus important après donc pour répondre de manière un peu plus catégorique plutôt tu peux
partir sur un monorepo mieux c'est mais ça veut dire que t'as une vision très claire de
quelles sont toutes les techno tu vas utiliser quels sont quels sont aussi l'évolution du projet
ok là je vais faire du mono du mono techno mono langage pardon plusieurs frameworks mais
mais je vais rester sur un seul même langage il n'y a pas beaucoup d'évolution voilà c'est pas bon
bah tu pars sur un monorepo qu'est ce que ça m'amène qu'est ce quels sont les les contraintes tu vois
là on a plutôt et je suis plutôt emballé par l'idée du monorepo je vais pas je vais pas mentir
par contre il faut pas oublier qu'il ya une centralisation des pouvoirs et donc il y a une
concentration d'information tout au même endroit donc ça veut dire aussi qu'il faut super bien
structurer bah tous tes dossiers ton arborescence de dossier toutes tes structures il faut qu'elles
soient vraiment super clean sinon c'est un bordel monstre parce que pour le coup t'as tout à
l'intérieur donc ce qui veut dire que tu dois vraiment avoir une rigueur en disant bah ça il
faut que ça soit au bon endroit tout donc ça c'est c'est c'est c'est bien ça impose en fait ça
implique ça il ya aussi quelque chose qui est en termes de sécurité si tu fais monter quelqu'un
sur le projet potentiellement il a accès à tout tout tout toute la code base donc ça veut dire
aussi que alors c'est un avantage parce que pour lancer un environnement de dev pour faire un
enbording et bah il a il a qu'un seul ripot il récupère tous monorepo il lance les les bonnes
commandes tu peux largement synchroniser ton instance de bac ton instance de front qui se
en même temps et donc ça communique ensemble donc tout ça en fait toutes tes tâches tu vas
pouvoir les les automatiser c'est super tu peux tout synchroniser parfait par contre la personne qui
arrive qui est là pour trois mois il a accès à toute la code base est-ce qu'en termes de sécurité
voilà ça c'est c'est un élément à prendre en compte on va pas parler des variables dans
l'environnement mais c'est un sujet aussi là pour le coup je pense qu'on pourra faire un épisode
dédié sur les sur les variables d'environnement ou comment on peut en fait sécuriser un peu
tout l'applicatif et pour éviter d'avoir des leaks de de variables dans d'environnement mais
mais voilà c'est ça c'est un autre sujet mais par contre ça veut dire aussi que quand tu vas
coder tu vas être obligé en fait de dire ok ça potentiellement je vais avoir en avoir besoin
sur tel tel tel tel appli bon bah je vais pas le coder en dur une seule fois dans une seule
appli je vais le mettre dans un dossier à part et je vais pouvoir le comme ça je vais pouvoir le
mutualiser et alors ça c'est mon process et ça vaut ce que ça vaut c'est pas c'est pas la messe
on est bien d'accord mais moi je le code une fois dans l'applicatif et quand j'en ai besoin dans un
deuxième c'est à ce moment là que je j'extraie ce code je le refacto et je le mutualise pour le
donner accessible à deux trois quatre cinq six applicatif et comme ça ce bout de code en fait
il est codé une fois en dur après je le mutualise je le rend accessible à tout le monde ce qui t
évite en fait de faire de l'over optimisation parce que c'est le danger en fait quand t'arrives
sur du monoripo c'est tu dirais bah ça potentiellement fait je pourrais en avoir besoin donc je vais
le rendre totalement générique et et comme ça n'importe quel applicatif pourra l'appeler ouais
sauf que tu sais pas si tu vas en avoir besoin donc tu le fait en fait tu le mutualises et tu le rend
accessible à tous et tu le rends générique au moment où t'en as besoin pour la deuxième fois
la première fois tu le fais normal et la deuxième fois tu le code et tu le rends de manière franchement
un def qui refactorise pas son code c'est c'est pas possible en fait t'es obligé de repasser une
fois deux fois dmt fois trois fois dessus si tu refactoris jamais ton code c'est qu'il y a un
problème de faire sur les variables d'environnement généralement t'as plutôt des variables d'environnement
de dev ou de staging des trucs comme ça donc des variables de prod tu n'aimes pas trop public
ou elles sont souvent sur le truc qui déploie à tout ça donc à ce niveau là normalement ou alors
si vraiment t'as que des variables d'environnement de production c'est qu'il y a un problème donc
généralement ça pose pas trop de soucis et des variables vraiment de test et tout ça et puis
ouais tu sais ouais c'est vrai que sur le site instagram qui vient qui a accès aux tout le
repos tout ça c'est à ce qu'il y a des risques après bon voilà faire confiance aussi par contre
ce qui est hyper primordial à mettre en place en fait c'est la revue de code en fait c'est
rien n'est poussé en prod ou quoi que ce soit sans revue de code rien n'est comité enfin qui
est né némergé sans revue de code pour vérifier qu'il travaille bien sur sa base qui doit faire et
pas partir sur le bac parce qu'alors qu'il doit pas y travailler enfin etc etc quoi tu vois après
la rigueur au niveau de l'équipe tu vois bien sûr et mais comment tu fais quand tu as un dev qui
fait une feature et il est sur deux ripos différents un sur le bac un sur le front tu vois et parce que
ok si tu as deux équipes il va falloir synchroniser tout ça mais si tu as une petite équipe bah tu
as un mec qui va faire du front et tu as un mec qui est c'est le mec qui va faire du front qui va
faire aussi du bac et bah comment tu fais pour faire ta revue de ton code sur deux codes base
différentes ça complique ouais c'est pour ça que tu vois pour le coup le monoripo est plus simple
tu as une seule et ou à faire sur un seul ripo oui c'est clair simplifie mais souvent ouais c'est le
même c'est si c'est du gs les deux des deux côtés back front tu as souvent les gars qui font le
bac elles prendent puisque pas c'est le même engage puis les petites équipes quoi mais ouais mais
ça c'est la complication des structures et les revues de code tout ça ça prend des fois plus
de temps à dev c'est sûr qu'on pousse on va on va déployer moins vite mais en même temps on
déploie c'est propre carrément carrément et pour le coup tous les tous les outils on va peut-être
orienter multi langage et ça ça c'est déjà avant de partir putain il faut faire du monoripo
parce que c'est la hype on peut peut-être parler de la hype mais c'est quelque chose que je regrette
dans notre métier où en fait on est vachement influencé par le marketing par par par les
podcasts par les podcasts par les deux bléros dans leur chambre qui sont en train de prendre le
micro mais mais pour le coup c'est c'est vachement c'est vachement une hype et et malheureusement
en fait toutes les techno ne sont pas intéressantes et est ce que ça fit avec mon projet c'est voilà
c'est prendre prendre le temps de dire ok qu'est ce que j'y gagne qu'est ce que j'y perd quels
sont les les inconvénients à faire ça et c'est sûr que quand tu es sur du mono langage c'est
oui ça sera plus facile en faire du gs parce que avec ton gs pour le potentiellement tu vas
faire ton front tu vas faire ton bac tu voilà tout tout va être poussé et mais tu peux mettre
aussi tes docker compose directement si tu utilises une techno voilà bah tu vas tout centraliser
dessus et t'as ta petite commande qui va popé tout et bah t'as ton environnement de de dev
donc c'est vrai quand on parle dans je te coupe mais ça qu'on n'a pas parlé mais si tu
tu fais ça ça permet aussi de centraliser tout ce qui est d'occur en fait tout fichier d'occur
en fait mais après ouais tu vas avoir plusieurs t'as qu'un seul fichier enfin un seul truc d'occur
et tu lances ton docker ça va gérer les deux même si tu es multi langage ça va gérer un php
un gs même d'occur etc à ce niveau là t'as aussi un gros avantage bah ouais carrément et
on parle et en et sans parler de la question du poids au niveau de ta machine de dev parce que d'avoir
un seul docker une seule image c'est beaucoup plus light que d'avoir plusieurs de toi tu as
plusieurs hippos avec plusieurs docker etc en plus vous les lancez etc tu vois ça complique beaucoup
les choses à ce niveau là bah ouais il y a que des avantages en fait depuis tout à l'heure non
non après je pense que c'est là aussi où on va tomber dans peut-être le dogme et la philosophie
en fait il ya il ya voilà chez les devs tu vas avoir différentes philosophies qui vont aborder
le problème différemment moi j'ai moi j'y vois un intérêt sur sur des gros projets pour les faire
évoluer dans le temps pour éviter tu vois des sortes de de 5 ouais de centralisation des pouvoirs
moi ça me plaît assez par contre il ya il ya des gens qui sont omnibulés par la sécurité
où ils sont ils veulent découper toute leur applicatif pour éviter qu'une équipe de dev ou
un dev à tous les pouvoirs voilà parce que c'est leur prisme à eux et c'est leur dogma
c'est leur philosophie et donc bah à ce moment là ça pourra pas affiter tu vois et c'est clair et
je vois il ya eu vachement de haters contre les monoripaux pendant une une période parce que
peut-être la techno n'était pas prête et il y avait plus d'inconvénients que de solutions tu vois
et et aujourd'hui ça s'est évolué moi par pendant très longtemps je te dis je ne voyais pas l'intérêt
je ne voyais pas je dis mais je comprends pas pourquoi je sais pourquoi et et au final en fait
bah plus tu évolues et plus tu en bien ou en mal c'est pas c'est pas là c'est en fait tu changes
ta vision et tu dis ok peut-être qu'est ce que ça va bien c'est parce que tant que tu n'as pas été
confronté à une problématique de gros projets en fait avec plusieurs voilà plusieurs trucs le
bac le front la doc etc ou peut-être même plusieurs applications tant que t'as pas été confronté à
poser la question comment je vais structurer ça bah tu tu ne vois pas l'intérêt en fait c'est
après pour revenir tu vois ce que tu disais ceux qui sont sécurité machin tout ça après c'est ça
c'est encore autre chose parce que ça va être c'est plus une politique de la boîte je pense
déjà travailler avec des mecs qui font des appays tout ça machin des fois moi j'ai des clients
qui utilisent des appays à d'autres entreprises et tu demandes de rajouter un truc sur la pays les
mecs peuvent mettre jusqu'à un mois pour déployer tu vois pour dire donc eux déjà ils ont déjà
d'autres problèmes à gérer tu vois ils sont tellement lent dans le déploiement etc la c'est
validé les données machin avant de pouvoir déployer un truc en prod c'est que c'est sûr que le
monoripo ils sont encore loin après c'est leur process c'est le process hyper complexe et tout
après la flexibilité et en tout cas il ya il ya un truc qu'on n'a pas aussi abordé mais pour toute
la partie design en fait si t'as si t'as des des composantes type story block c'est ça que tu
utilises story black story book story book story book story book story book en fait ton monoripo
en fait il a il a un dossier design et en fait dedans t'as toutes les guidelines t'as toutes
t'as toutes tes codes couleurs tout donc ton appli et ton site internet utilise le même branding et
donc si ça change et bah en fait ça sera automatiquement mis à jour sur le site et sur l'applicatif et
sur si t'as un package qui génère tes tes tes emails tout bah en fait tout sera tout sera mis
à jour automatiquement donc il ya aussi un intérêt pour les designers d'utiliser en tout cas pour
pour le site et on va dire chef de projet de tout centraliser parce que le designer va pouvoir
aussi mettre à jour tout et toutes les toutes les applicatifs vont hériter du même du même
design oui oui pour partager ça peut être pas mal pour partager c'est tout ça quand tu fais un story
book ou t'as css dedans et puis après tu vas le partager t'intégrer tes compenites c'est pas mal
il y avait on avait aussi je sais pas si tu te souviens on avait un invité sur une techno qui
permettait de partager des compenites comme ça plaît ça je me souviens plus mais ouais c'est ça
c'est un peu bah ça ouais c'est pratique ça c'est pour le coup justement c'était à l'époque
où on parlait pas trop de monoripaux et ça permettait justement de partager des compénites entre
différents ripos c'était synchroniser un endroit chez habite et puis après ça partageait entre
différents projets tu vois comme quoi tu peux te passer de bits en monoripaux éventuellement ouais
et mais c'est exactement ça après je pense qu'il ya une certaine maturité sur cet écosystème
peut-être que avant c'était hyper compliqué à mettre en oeuvre aujourd'hui c'est devenu pas
un standard mais quasiment beaucoup de projets utilisent de plus en plus de de monoripaux parce
que tout le monde y voit le bénéfice quoi clairement enfin moi pour le coup là sur sur ma
toute petite expérience j'ai cinq applicatifs totalement différents et bah elle chacun hérite
en fait des mêmes dépendances quasiment par contre c'est dans deux unis vraiment dans des
univers différents tout est fait en next bon bah voilà je n'ai pas je vais pas mettre cinq fois
vas-y il faut que je bump la version de next je le fais une seule fois tout est hérité automatiquement
et le code branding identique les typages pareil et donc c'est c'est vachement vachement plus
confort mais moi ça fait gagner un temps ça me fait gagner un temps de ma boule et surtout bah
demain quelqu'un arrive sur le projet il a tout quoi il a tout ouais moi c'est pareil sur les
tous les projets où j'ai fait un monoripaux je reviendrai pas en arrière clairement et même sur
des projets on a fait on avait deux techno comme le php lgs je reviendrai pas en arrière du tout
parce que c'est tellement plus simple à gérer tu tu tu poutes et puis voilà ça part en prod et
puis derrière on avait quand même mis un système tu vois quand ça déployait le php d'un côté le
gs de l'autre en fait on avait mis un système qui faisait que s'il n'y avait pas de modif sur le php
ça déployait pas le php ou inversement ça déployait pas le gs ça détectait si il y avait
vraiment du changement ou pas pour éviter des déploiements inutiles après voilà il y a plein
d'outils on va unir de façon mais non je reviendrai pas en arrière sur tous les projets
monoripaux qu'on a fait parce que ça simplifie beaucoup les choses entre les devs en fait entre
plusieurs devs qui sont ensemble c'est vraiment c'est c'est vraiment c'est un confort c'est un
confort c'est ça nécessite un petit shift en termes d'organisation et de voilà de structure
mais au final tu tu tu y gagnes quand même pas mal juste avant de partir sur sur les tools
j'ai on a trouvé en fait un site assez pétagogique qui en fait qui s'appelle monoripaux point tools
évidemment on mettra les liens dans la description qui est qui est en fait hyper didactique et qui
explique pourquoi les monoripaux les bénéfices pourquoi c'est c'est intéressant pour le coup
c'est ça se lit super bien c'est pas du tout verbeux c'est beaucoup imagé avec des des des images
des schémas où on comprend juste justement cette idée de modularité de package ou d'apples qu'on
réutilise remonte un peu là tu vois il ya un truc qui est intéressant c'est monoripaux n'est pas
égal à monolithique c'est marqué juste là c'est vraiment deux choses ouais c'est là pour le coup
c'est vraiment deux choses totalement différentes sur une approche monolithique et monoripaux c'est
deux deux deux choses totalement différents une qui est sur la la code base et l'autre c'est sur les
instances donc c'est vraiment deux choses différentes mais pour le coup voilà ça se lit hyper
rapidement hyper facilement c'est vraiment optimisé et on comprend beaucoup beaucoup beaucoup de
choses et justement en fait il note en fait les différences entre les outils et ok bah cet outil
fait de l'apparalisation de tâches ok cet outil va pouvoir bider va pouvoir exécuter des tâches
bien bien bien bien bien bien spécifique et donc pour le coup c'est assez facile en fait de faire
son choix à l'issue en fait de cette lecture là parce qu'on voit de quoi on a besoin si est ce qu'on
a besoin en fait de de détecter en fait le changement des dans les packages est ce qu'on a besoin de
cette fonctionnalité là bah ok quel outil le gère bah ok l'outil que je pensais ne le gère pas est ce
que j'ai besoin de cette fonctionnalité là oui non voilà c'est pas et donc c'est assez didactique et
c'est hyper hyper bien fait c'est facile à lire et on comprend vraiment bien en fait l'importance
de tous ces outils là monoripo.tools super super sympa alors un des outils les plus anciens et qui est le
plus utilisé enfin utilisé bah on en a parlé tout à l'heure c'est basel parce qu'il est utilisé
par une petite boîte qui s'appelle google et apparemment c'est ce qu'ils utilisent pour
builder en fait toute leur applicatif et tout leur tout leur système donc ça gère du multilangue et
c'est là du multilangage donc avec les différents environnements tout là pour le coup c'est c'est
quand même super solide parce qu'il faut gérer différents différents univers et différents
environnements quoi. Ouais puis ça doit être énorme code base google. Je pense que ça va être
un des principaux contributeurs peut-être google sur ce tout petit open source basel. Je sais même
pas il faudrait regarder sur le github si c'est open source mais oui je pense qu'il y a des
mecs qui sont dédiés à ça et qui ne font que ça quoi. Les mecs faut que ça tienne nos coups
en l'utilise. Tout le faire durer. Clairement tout est basé là dessus. Dans l'écosystème
GIS il y a Turbo repo qui est poussé par Vercel qui est très connu et très mis en avant après on
connaît tous le marketing de Vercel où ils sont très très bons sur le marketing donc ils ont
réussi à pousser ça. Pour le coup sur l'écosystème GIS ça fait vraiment le taf. La doc est
super bien faite une fois de plus en fait si vous avez pour projet de passer sur des monoripaux prenez
le temps de lire la doc. Là pour le coup c'est que de la config donc c'est primordial. Sans ça
vous allez perdre beaucoup de bénéfices et surtout vous allez rien réinventer la roue
potentiellement alors que si vous utilisez bien ces solutions ou tous ces outils de monoripaux
en fait ça va vous enlever de la charge de travail donc c'est vraiment intéressant d'où l'intérêt
en fait de vraiment vraiment bien utiliser et de bien respecter les conventions sinon ça va
beaucoup moins marcher avec les deux possibilités sur ce tourbouripaux de soit
partir de scratch c'est à dire on instantie un nouveau projet ou en fait de rajouter
tourbouripaux sur un déjà sur un projet existant. Il y a les deux approches avec tout ce que ça
implique en termes de migration de code quoi. Toi tu l'utilises celui là. L'avantage principal
c'est je sais que c'est la vitesse donc il parle de cache donc c'est ça c'est ce que tu disais
d'ailleurs ça met en cache en fait au niveau d'un serveur externe et après quand quelqu'un récupère
le projet et va rebuilder en dev machin tout ça ça utilise ce cache donc une vitesse de
compilation ultra rapide c'est ça un peu le principe enfin le avantage principal de
tourbouripaux. Alors c'est l'avantage principal non c'est déjà que c'est que tout est centralisé
donc on va pouvoir en fait tu vois configurer toutes tes taches enfin ouais toutes tes applicatives
vont être vont être splitées tes apps tes tes packages tes types tes lineteurs tout ça vont être
centralisé et effectivement tu vas pouvoir en fait déployer et recompiler uniquement ce que
tu as besoin ce qui t'évite en fait de faire tourner ta machine de build ou de stage pour pas
grand chose quoi. Donc après versel c'est bien mais tu n'es pas obligé d'utiliser le cache de chez
versel pour ton applicatif tu peux alors pardon tu peux utiliser leur cache même si tu ne buildes pas
chez eux donc c'est là où c'est intéressant c'est que tu peux t'as un espace en fait où tu vas
stocker tous tes artefacts d'instance et en fait tu peux les utiliser si par exemple tu as ton build
qui est sur ton ta github action par exemple tu veux récupérer ton cache ton build de cache de
tous tes packages qui n'ont pas évolué mais tu as juste fait des modifications sur ton applicatif
et cet applicatif hérite de trois ou quatre packages si tes packages sont déjà buildé et
sont uploadés sur ton cache au moment de ton build de ton applicatif tu vas hériter de tous
ces builds ce qui va te faire gagner du temps en termes de build et en fait c'est le gros gros
avantage qui est mis en valeur c'est justement cette optimisation du cache parce que tu vas
économiser de la ressource machine après faut pas se lurer si versel a poussé ça c'est pour eux aussi
parce que ta machine elle tourne elle tourne moi ouais dis moi le cache le cache que tu qui vont
stocker chez eux en fait il te faut quand même un compte versel j'imagine oui oui oui bien sûr
d'accord c'est le gratos enfin si c'est tu peux avoir un compte gratuit mais oui après tu peux
mettre un propre ton propre serveur pour stocker le cache ou non alors sage sage sage j'ai pas testé
si tu peux mettre ton propre cdn pour stocker le cache pour le coup il dit plutôt l'inverse c'est à
dire t'es pas obligé de builder chez nous t'es pas obligé de stocker enfin de builder et de hoster
ton site chez nous par contre tu peux utiliser notre cache ça c'est ça c'est possible donc il
faut juste des tokens ce qui fait que bah même sur ton github action ou sur ton ordi tu vas pouvoir
en fait builder et si il a déjà caché le truc bah tu vas tu vas le récupérer ton cache et pour le
coup ça ça marche vraiment bien quand tu build en local en fait bah s'il a déjà buildé il va
directement voilà il utilise le le le le comit et donc en fait il dit ok bah il n'y a pas eu de
modification sur ce package là ça déjà été buildé à tell heure depuis tel comit on peut
réutiliser c'est cette version là ça passe je crois que sous le capot c'est du rust je crois mais
je suis pas sûr pas sûr mais mais donc dans l'idée tu vois c'est intéressant même pour tu vois
quand tu si tu as des tests automatiques dès que tu déploies si ça utilise le cache tu gagnes encore
à ce niveau là au niveau de vitesse de la vitesse bien sûr bien sûr bien ouais parce que en fait
ouais toute ta phase de test est obligée de builder et ce build là si tu as des tests de builder
tu as deux ou trois quatre devs qui l'ont déjà buildé sur leur machine bah ça sert à rien de
le relancer il est déjà synchronisé donc tes tests vont plus vite donc ta cdca il va plus vite
donc tu peux voilà c'est c'est tout un écosystème qui va qui va beaucoup beaucoup beaucoup plus vite
quoi ok ça c'est pas mal ça donc et pour le coup toujours sur turbo repo tu vas avoir en fait des
guides qui vont te permettre en fait d'intégrer dans n'importe quel framework et pareil pour tout
tes pour tous tes outils en fait tu veux mettre ton type script ils vont vraiment t'expliquer comment
tu peux mutualiser comment tu peux synchroniser pareil pour tes tests vit test et tout ça donc
pour le coup la doc est plutôt bien faite même s'il ya allez je vais être un peu taché
mais cette toute cette optimisation de je builde pas si l'application excusez moi je builde pas
cette applicative si j'ai pas déployé ou en modifié quelque chose dans la codebase ça c'est un
touchy chez versel donc il faut vraiment poncer un peu le truc t'as des commandes qui sont un petit peu
un petit peu compliqués à que tu ne trouve pas tout de suite parce que eux par principe tu buildes
automatiquement voilà ça fait partie de leur bisef fin moi j'ai l'impression que ça fait partie
de leur business model et donc et donc voilà ils vont te croquer en fait des minutes de build et
surtout moi ça me prend un taquet taquet de temps et aujourd'hui j'en suis arrivé où je builde
tout en local si tu veux tu vois et bah c'est tellement plus rapide c'est tellement plus rapide
mais j'ai l'avantage aussi c'est que il n'y a pas grand monde sur mon ripot il y a que moi sur mon
ripot par contre j'ai structuré les choses de telle manière si demain on est plusieurs il y a
de bosser comme si j'étais en équipe et comme parce que demain en fait j'aurais pas à refacto
quoi ça sera déjà tout centralisé il y aura déjà accès à tout et tout sera prêt en fait à
gérer en mode équipe même si je suis tout seul et donc voilà ça c'est ok ok gestion vite fait
sur le gestionnaire de package on a parlé de ta l'heure de pnpm avec les catalogue là tout ça
les workspace je sais qui a géré les workspace npm normalement aussi oui bon il le gère tous en
fait oui oui oui il le gère tous et pour le coup c'est en fait ça va un peu de pair quoi tu
peux pas faire du monoripot si tu n'utilises pas un gestionnaire de package ou sur lequel tu
vas créer tes workspaces ça n'a pas de sens pour le coup si vous faites du front aujourd'hui tous
en fait le fond même npm en fait à rattraper son retard je crois que le premier qui l'a fait c'était
yarn après il y a eu pnpm et maintenant en fait c'est natif dans chez burn tout donc pour le coup
c'est c'est c'est la même chose un autre un autre outil de de monoripot s'appelle nx et ça va
faire exactement la même chose je ne sais pas si il est multi-langage ou pas où il est que sur
du javascript pour le coup j'ai pas j'ai pas fait mais en fait il y avoir un tout un écosystème
pareil de build et donc il y a une solution cloud qui va vous permettre en fait de de pouvoir
gérer tous ces monoripots et de toute cette phase de build et de pour optimiser en fait toute cette
base de build et donc de test et de tout ce qui va derrière et de mutualisation pareil c'est
toujours des systèmes qui sont assez complexes à mettre en place au départ mais une fois que
c'est mis en place il ya un réel bénéfice surtout si on est en équipe et surtout plus le
projet est gros bah plus c'est plus on va récupérer du le bénéfice et toute cette mutualisation
clairement mais carrément ouais ok ma cool nice et donc c'est les monoripots monoripot c'est la vie
est ce que est ce que c'est intéressant de passer sur des monoripots je pense qu'il faut se poser
la question dès le départ est ce que est ce que je vais avoir une la mutualisation est ce que je
vais avoir des grosses évolutions est ce que je suis sur du même langage est ce que je vais
mettre une cdci est ce que je vais avoir beaucoup de développeurs qui vont intervenir voilà toutes
ces questions là sont à prendre en compte pour pour décider si on passe sur un monoripot ou pas
clairement je pense que sur des projets un peu un peu conséquent ça peut très très vite
amener plus de solutions que de problèmes en clair ça résout plus de problèmes que ça
n'en m'amène et donc je à première vue comme ça ça me paraissrait intéressant de se pencher
et au moins d'étudier la question pour voir si on pourrait pas gagner en sérénité parce que
le but d'un développeur c'est de pousser sa feature de manière hyper serein parce qu'elle a
été revue elle a été testée elle a été bildée elle a été et on évite de faire 50 fois la même
chose et donc tout cet écosystème nous permet de faire ça donc c'est là où c'est intéressant donc
il faut se pencher là dessus est testé d'ici nous dites nous nos commentaires si vous êtes
monoripot ou pas si vous avez déjà fait les projets en monoripot si c'est bien si vous avez des
retours d'expérience tout ça toujours intéressant d'avoir les commentaires donc n'hésitez pas et
on vous remercie d'être resté jusqu'au bout de l'épisode et puis on vous dit à bientôt pour
d'autres épisodes ciao ciao ouais ça marche ciao à plus retrouver double slash sur la
forme de podcast préféré et sur le site internet du podcast www.slash-podcast.fr sur le site vous
allez retrouver tous les liens d'épisode les références évoquées durant l'émission