Monorepo mon Amour

Écrire sur les monorepo en 2024, c'est arriver un peu après la bataille. Ou pas, vu que je rencontre tous les jours des équipes développant des Single Page Applications dont le front-end et le back-end font l'objet de 2 repositories distincts. Dès lors, la moindre fonctionnalité qui touche et au front et au back se matérialise par 2 commits. Et ça, c'est un problème, parce qu'il n'est plus possible, dès lors, d'assurer la parfaite correspondance des versions déployées : la modification du back-end pourrait être déployée sans celle du front-end (souvent problématique), ou, inversement, la modification du front-end pourrait être déployée sans celle du back-end (nécessairement problématique).

Un monorepo pallie ce problème en versionnant de manière unique les différents packages constitutifs d'une même application – dans l'exemple précédent : front-end et back-end. Ainsi, ces packages deviennent solidaires, ce qui nous conduit à parler d'atomicité des commits : "atome" vient du grec ancien ἄτομος "insécable". Il s'ensuit que les différents déploiements, si on y procède de manière automatique, auront lieu à chaque fois sur base d'une même version de l'application (un même commit), augmentant les chances d'aboutir à un état du système cohérent en production. Cette cohérence n'est cependant pas garantie parce qu'un déploiement pourrait encore échouer.

Digression : on attribue souvent la notion d'atome à Lavoisier, mais l'intuition de "grains composant la matière" remonte à l'antiquité, tandis qu'il fallut attendre le XIXème siècle pour qu'en soit proposée une définition explicite. Lavoisier, quant à lui, contribua de manière significative à l'édifice en énonçant que "rien ne se perd, rien ne se crée, tout se transforme". Ce faisant, il ouvrait les portes d'un nouveau champ de savoir, la chimie, et disait de manière implicite la nécessaire décomposition de la matière en particules élémentaires. Ironiquement, Lavoisier mourut guillotiné, prouvant à cette occasion qu'il n'était pas un atome.

Mais revenons à notre sujet pour évoquer les principaux bénéfices d'une stratégie monorepo :

• Elle incite à la mutualisation et à l'harmonisation : mutualisation des différents utils et dev-utils, centralisation des configurations (transpileur, linter, formatter) et bien sûr constitution d'une librairie implémentant le design system, si votre organisation a entrepris une telle démarche en amont. Un monorepo facilite également le partage de code métier entre back-end et front-end (meilleure User eXperience) ainsi que le partage d'un shared kernel entre contextes au sens du Domain-driven design.

• Elle facilite la gestion des dépendances : en allant au bout de l'idée, et bien que les outils ne l'imposent pas toujours, vous pouvez mutualiser les dépendances à la racine du monorepo, vous obligeant à résoudre proprement les "peer dependency conflicts".

• Elle accélère fortement la CI : les dépendances entre packages dessinent un arbre des dépendances, dont la prise en compte permet de paralléliser les jobs (lint, build, test, deploy). Ajoutez à cela la détection des seuls packages concernés par un changement (affected chez Nx), ainsi que l'utilisation du cache, et les temps d'exécution de vos workflows de CI/CD seront drastiquement réduits (couramment plus de 50%).

En matière d'outillage, Nx et Turborepo tiennent le haut du pavé dans l'univers JavaScript/TypeScript. La DX (Developer eXperience) s'en trouve radicalement modifiée, au point de se rapprocher dangereusement de celle d'un framework 🥲 Cela peut dérouter initialement, puis vient le moment où l'on trouve ses marques et où l'on constate le gain en efficacité.

Enfin, si l'utilité d'une stratégie monorepo se conçoit bien à l'échelle d'un produit unique, sa mise en œuvre pose rapidement la question de sa généralisation à l'échelle de l'organisation elle-même : le design system, en particulier, est par définition relatif à l'entreprise entière. Il en va de même pour les différents utilitaires évoqués précédemment.

À vous de voir jusqu'où aller et où vous arrêter, sachant que le full monorepo à l'échelle de l'entreprise est possible mais demande de sérieuses adaptations. À ce sujet, le cas de Google ne finit pas de nous interpeller.