polyrepo<\/b><\/a> est un r\u00e9f\u00e9rentiel qui contient plusieurs projets. <\/b>Nous avons utilis\u00e9 un style d’organisation polyrepo, ce qui signifie simplement que chaque projet front-end avait son propre r\u00e9f\u00e9rentiel, m\u00eame si plusieurs projets r\u00e9p\u00e9taient les m\u00eames t\u00e2ches et reproduisaient les m\u00eames fonctionnalit\u00e9s. En tant que hub central, les polyrepos peuvent devenir un d\u00e9fi \u00e0 maintenir \u00e0 mesure que le nombre de projets stock\u00e9s augmente. Dans de nombreux cas, nous devions d\u00e9ployer chaque polyrepo simultan\u00e9ment avec les m\u00eames mises \u00e0 jour pour garantir une exp\u00e9rience coh\u00e9rente sur l’ensemble de nos produits.<\/p>\n\n\n\n D’un point de vue de la maintenance, cela a rendu difficile pour les \u00e9quipes de localiser et de travailler avec le code dont elles ont besoin. G\u00e9rer plusieurs r\u00e9f\u00e9rentiels avec des fonctionnalit\u00e9s redondantes signifie g\u00e9n\u00e9ralement qu’ils sont plus lents \u00e0 r\u00e9pondre et<\/i> plus gourmands en ressources, ce qui est un gros probl\u00e8me si vous poussez et tirez fr\u00e9quemment du code. Parce que les fonctionnalit\u00e9s peuvent \u00eatre distribu\u00e9es sur plusieurs bases de code, les polyrepos peuvent rendre la recherche de bugs plus difficile que de trouver la proverbiale aiguille dans une botte de foin.<\/p>\n\n\n\n
Avec notre structure polyrepo d’avant la refonte, nous savions que l’avenir serait une r\u00e9alit\u00e9 o\u00f9 nous devrions fouiller dans les r\u00e9f\u00e9rentiels avec une lampe de poche pour chercher ce dont nous avions besoin, et qu’il serait difficile de collaborer, d’\u00e9voluer et de partager du code \u00e0 mesure de notre croissance.<\/p>\n\n\n\n
Voici nos principales pr\u00e9occupations :<\/b><\/p>\n\n\n\n\nCo-d\u00e9veloppement difficile<\/li>\n\n\n\n Couplage \u00e9troit<\/li>\n\n\n\n Gestion de l’\u00e9volutivit\u00e9, de la disponibilit\u00e9 et des performances<\/li>\n\n\n\n Difficult\u00e9 \u00e0 partager du code<\/li>\n\n\n\n Duplication<\/li>\n\n\n\n Outillage incoh\u00e9rent<\/li>\n<\/ul>\n\n\n\nEn ce qui concerne la gestion du code source, il existe de nombreuses solutions, mais nous avons d\u00e9cid\u00e9 qu’une structure modulaire et monorepo soulagerait la majorit\u00e9 de nos difficult\u00e9s de d\u00e9veloppement \u00e0 l’avenir.<\/p>\n\n\n\n
Projets pour un tout nouveau r\u00e9f\u00e9rentiel : une approche modulaire<\/h2>\n\n\n\n Une approche monorepo implique de stocker tout le code du projet dans un seul et grand r\u00e9f\u00e9rentiel<\/b>. Cela r\u00e9soudrait les probl\u00e8mes de partage de code et de duplication que nous avons rencontr\u00e9s avec notre organisation polyrepo, mais les monorepos ne sont pas une solution miracle. Si le code est \u00e9troitement coupl\u00e9, les monorepos doivent \u00e9galement \u00eatre con\u00e7us avec modularit\u00e9.<\/p>\n\n\n\n
Une approche modulaire consiste \u00e0 diviser un vaste projet en modules plus petits et ind\u00e9pendants qui peuvent \u00eatre d\u00e9velopp\u00e9s, test\u00e9s et maintenus s\u00e9par\u00e9ment<\/b>. Cela permet une plus grande flexibilit\u00e9 et r\u00e9utilisabilit\u00e9, ainsi que la capacit\u00e9 de mettre \u00e0 jour facilement des modules individuels sans affecter le reste du projet.<\/p>\n\n\n\n
Nous savions qu’une solution modulaire de type monorepo nous permettrait d’\u00eatre plus efficaces avec :<\/p>\n\n\n\n
\nG\u00e9n\u00e9ration de code<\/li>\n\n\n\n Partage de code<\/li>\n\n\n\n Ex\u00e9cution et orchestration de t\u00e2ches distribu\u00e9es<\/li>\n\n\n\n Mise en cache<\/li>\n\n\n\n TypeScript<\/li>\n<\/ul>\n\n\n \r\n\r\n
TypeScript est un surensemble de JavaScript typ\u00e9 qui permet aux d\u00e9veloppeurs de cr\u00e9er plus facilement des projets \u00e0 grande \u00e9chelle.<\/b> Il am\u00e9liore l’exp\u00e9rience d\u00e9veloppeur en fournissant des interfaces, des alias de type, une analyse statique de code au moment du d\u00e9veloppement et d’autres outils tout en permettant aux d\u00e9veloppeurs d’ajouter du typage \u00e0 leurs projets. Pour notre \u00e9quipe, TypeScript est une comp\u00e9tence que nous savions vouloir commencer \u00e0 rechercher lorsqu’il s’agissait d’ajouter des membres \u00e0 notre \u00e9quipe.<\/div>\r\n <\/div>\r\n\n\n\nSe marcher sur les pieds : La danse du d\u00e9ploiement<\/h2>\n\n\n\n Ind\u00e9niablement, le plus grand d\u00e9fi de vivre dans un monorepo (monolithique ou autre) est que plus il y a de contributeurs, plus le risque de se marcher sur les pieds est grand. \u00c0 quoi sert une exp\u00e9rience d\u00e9veloppeur remani\u00e9e si votre code est \u00e9cras\u00e9 lors d’une mauvaise fusion ? Si nous proc\u00e9dons vraiment \u00e0 une refonte holistique de notre pile, alors nous devons \u00e9galement examiner comment nous pouvons am\u00e9liorer notre processus de d\u00e9ploiement. Voici les d\u00e9fis les plus urgents :<\/p>\n\n\n\n
\n\u00c9volutivit\u00e9 : <\/b>Ce serait une mauvaise id\u00e9e de reconstruire TOUT le code du monorepo pour les plus petits changements, disons, corriger une faute de frappe dans un texte. C’est exactement ce que nous faisions dans notre ancien syst\u00e8me. Le nouveau processus tirerait parti des capacit\u00e9s int\u00e9gr\u00e9es de NX pour \u00e9valuer et reconstruire uniquement les fichiers affect\u00e9s par la modification, au niveau le plus granulaire.<\/li>\n\n\n\nD\u00e9ploiement : <\/b>Nous avons conserv\u00e9 la plupart des \u00e9l\u00e9ments de notre pipeline de d\u00e9ploiement. Une fois l’image construite, elle atterrit dans le r\u00e9f\u00e9rentiel de conteneurs GitHub. Notre \u00e9quipe SRE a peaufin\u00e9 notre syst\u00e8me de d\u00e9ploiement lors de la migration d’AWS vers GCP. Nous pouvons facilement d\u00e9ployer n’importe quelle branche depuis notre canal de d\u00e9ploiement Slack, avec de meilleurs rapports gr\u00e2ce \u00e0 un ajout r\u00e9cent que nous avons obtenu pendant la migration.<\/li>\n\n\n\nCI\/CD :<\/b> Notre ancien syst\u00e8me utilisait une tr\u00e8s ancienne version de Jenkins pour ex\u00e9cuter les tests et construire\/distribuer les images de notre application derri\u00e8re un VPN. Lorsque le build \u00e9chouait, nous avions besoin d’un d\u00e9veloppeur senior haut plac\u00e9, familiaris\u00e9 avec les anciennes m\u00e9thodes, pour le corriger. Dans notre nouveau syst\u00e8me, nous avons pr\u00e9vu de passer \u00e0 GitHub Actions, o\u00f9 les configurations sont accessibles, d\u00e9claratives et bien document\u00e9es.<\/li>\n<\/ul>\n\n\n\nD\u00e9fis absurdes et solutions excellentes<\/h2>\n\n\n\n Les projets de toutes sortes comportent des d\u00e9fis, certains attendus et d’autres surprenants. Nous savions que nous devions planifier pour surmonter certains probl\u00e8mes et que la nouvelle version de l’application devait se concentrer sur les performances sous de multiples angles.<\/p>\n\n\n\nProbl\u00e8mes identifi\u00e9s<\/th> Solutions propos\u00e9es<\/th><\/tr><\/thead> Conventions de code peu claires<\/strong>Guide de style de code<\/strong>\u00c9tat surcharg\u00e9<\/strong>S\u00e9parer le cache r\u00e9seau et l’\u00e9tat de l’application<\/strong>Architecture r\u00e9seau multicouche<\/strong>L’API publique d’abord<\/strong>Ne pas jeter le b\u00e9b\u00e9 avec l’eau du bain<\/h3>\n\n\n\n Nous avons \u00e9crit des centaines de milliers de lignes de code au cours de la derni\u00e8re d\u00e9cennie. Avec l’ampleur et la port\u00e9e de ce nouveau projet, il faudrait presque autant d’ann\u00e9es pour porter et r\u00e9\u00e9crire nos anciennes fonctionnalit\u00e9s dans le nouveau paradigme. Ce serait un \u00e9chec d’embl\u00e9e. Nous devions trouver un moyen de continuer \u00e0 int\u00e9grer ces fonctionnalit\u00e9s existantes sans compromettre nos objectifs pour la nouvelle pile. Nous avons trouv\u00e9 une solution dans une technologie appel\u00e9e f\u00e9d\u00e9ration de modules (module federation).<\/p>\n\n\n\n
Gr\u00e2ce au plugin de f\u00e9d\u00e9ration de modules de Webpack, nous avons pu cr\u00e9er un nouveau build de notre ancienne application avec des modifications minimes<\/b>, ce qui permettrait d’int\u00e9grer les fonctionnalit\u00e9s existantes dans la nouvelle pile Portail. Nous aurions toujours pour objectif \u00e0 long terme de porter le code d\u00e9sormais h\u00e9rit\u00e9 vers des normes plus r\u00e9centes, mais cela nous permettrait de commencer \u00e0 \u00e9crire imm\u00e9diatement de nouvelles fonctionnalit\u00e9s avec les nouveaux avantages.<\/p>\n\n\n\nNous avons un plan, mais pouvons-nous le concr\u00e9tiser ?<\/h2>\n\n\n\n
Nous savions que consolider nos plateformes tout en d\u00e9veloppant continuellement les fonctionnalit\u00e9s et les ensembles de produits n\u00e9cessiterait un effort massif, et notre planification a influenc\u00e9 ce que nous voulions pour notre nouvelle pile front-end, ainsi que la mani\u00e8re dont nous allions g\u00e9rer l’h\u00e9ritage persistant des syst\u00e8mes de style CSS obsol\u00e8tes, des mod\u00e8les de composants de classe d\u00e9pr\u00e9ci\u00e9s et d’une gestion maladroite de l’\u00e9tat de l’application.<\/p>\n\n\n\n
Parce que nous repartions de z\u00e9ro \u2013 en particulier avec le passage d’AWS \u00e0 Google Cloud \u2013 la meilleure solution \u00e9tait une rupture nette<\/b>. Un nouveau r\u00e9f\u00e9rentiel avec de meilleures normes plus \u00e9lev\u00e9es, une f\u00e9d\u00e9ration de modules, des biblioth\u00e8ques modulaires et partag\u00e9es, et une documentation interne et orient\u00e9e utilisateur plus compl\u00e8te.<\/p>\n\n\n\nCe fut une \u00e9tape de pr\u00e9paration et de planification intense. Comme pour tous les grands projets, la g\u00e9n\u00e9ration des id\u00e9es et de la preuve de concept a \u00e9t\u00e9 une entreprise technique et cr\u00e9ative qui n’a impliqu\u00e9 que quelques personnes s\u00e9lectionn\u00e9es.<\/p>\n\n\n\n
Phase 2 ? Transformer l’id\u00e9e en r\u00e9alit\u00e9 \u2013 et cela a impliqu\u00e9 beaucoup plus d’\u00e9quipes. D\u00e9veloppeurs, je crois que notre aventure est sur le point de prendre une tournure des plus int\u00e9ressantes. <\/p>\n\n\n\r\n