Devriez-vous utiliser un Monorepo ? –

Le modèle monorepo utilise un référentiel de contrôle de version unique pour tous vos projets et actifs. Vous regrouperez vos fichiers de configuration côté serveur, frontend et d’infrastructure dans un référentiel auquel tout le monde contribue. Faut-il l’utiliser ?

Le modèle est populaire auprès des grandes entreprises technologiques. Google, Microsoft et Facebook font partie des organisations qui utilisent les monorepos. Qu’est-ce qui rend un monorepo si attrayant ?

L’alternative

Monorepo s’oppose au multi-repo. Le modèle multi-dépôt vous permet de créer un nouveau référentiel pour chacun de vos projets. C’est généralement assez clair lorsqu’un projet mérite son propre référentiel.

Si vous créez une application, vous pouvez disposer de trois référentiels :

• Code côté serveur : Votre API (éventuellement avec des référentiels supplémentaires pour les schémas de base de données et la documentation).
• Projet Android : La version Android de votre application, en utilisant Java ou Kotlin.
• Projet iOS : Objective-C ou Swift pour votre application iOS.

Ici, tout ce qui compose votre entreprise est divisé en unités de fonctionnalité distinctes. Avec un monorepo, vous abandonnez ce regroupement et prenez toujours la vue agrégée. Tous vos actifs vont ensemble et sont versionnés en conséquence.

Collaboration

L’un des avantages du monorepo les plus souvent cités concerne la collaboration. Dans un monorepo, tout le monde voit tout. Cela contribue à la clarté, facilite l’ouverture et permet aux membres des différentes équipes d’accéder plus facilement au travail des autres.

Les gens peuvent plus facilement travailler ensemble sur une tâche, même si cela ne relève pas de leurs responsabilités habituelles. Dans un scénario multi-dépôt, vous devrez peut-être d’abord demander l’accès au référentiel approprié. Cela ajoute des frictions que l’approche monorepo évite entièrement.

Monorepos encourage tout le monde à s’approprier l’objectif final plutôt que les éléments individuels qui le composent. Cela peut amener les gens à se sentir plus impliqués et mieux informés de ce qui se passe. Un développeur d’applications peut ne jamais toucher aux composants du serveur, mais il peut les « sentir » évoluer parallèlement à son propre travail.

Facilité d’abstraction

Monorepos simplifie également l’abstraction de code. Il est courant de se retrouver avec des fonctionnalités similaires dans vos composants backend et frontend. Il est logique de faire abstraction de cela dans une bibliothèque partagée.

Dans le paradigme multi-dépôt, vous auriez besoin de créer un nouveau référentiel, puis de le référencer dans les autres. Cela peut être en créant un package ou en utilisant des sous-modules Git. Dans tous les cas, beaucoup de travail est nécessaire avant que votre code abstrait puisse être réinjecté dans les projets dont il provient.

Le processus est plus simple si vous avez un monorepo. Vous pouvez déplacer le code vers un répertoire qui a du sens, puis l’importer là où vous en avez besoin. Une « abstraction » prend quelques secondes. Il existe une commodité similaire lorsqu’il est temps de documenter le code : vous pouvez ajouter les documents dans votre système de documentation partagé.

Les multi-dépôts présentent également des obstacles pratiques lors de l’abstraction du code. Un membre de l’équipe de développement n’a souvent pas les autorisations GitLab, GitHub ou Bitbucket nécessaires pour créer un nouveau référentiel. Cela entraîne des frais généraux encore plus importants lorsqu’un chef d’équipe doit approuver la nouvelle bibliothèque et configurer un référentiel. Monorepos aide les développeurs individuels à créer du code réutilisable en éliminant les processus d’abstraction spéciaux.

Au-delà création l’abstraction, monorepos simplifie la maintenance des modules partagés. Vous n’avez pas besoin de mettre à jour chaque consommateur d’un package à chaque fois que vous le mettez à jour. Toutes les dépendances existent dans la même base de code, vous pouvez donc les référencer sans gestionnaire de packages ni versionnage dédié.

Vitesse de développement

L’utilisation d’un monorepo peut accélérer la vitesse de développement. Nous en avons parlé dans les sections précédentes, mais cela vaut la peine d’y prêter plus d’attention.

Monorepos réduit les actions en double. Si vous avez besoin de refactoriser, il s’agit d’une seule recherche et remplacement pour appliquer la modification à l’ensemble de la base de code. Il y a moins de basculement entre les projets et moins de demandes d’extraction à examiner.

Les contributeurs ont plus de possibilités de libre-service. Comme les informations ne sont pas cloisonnées dans des référentiels d’équipe, les gens sont mieux équipés pour rechercher les détails dont ils ont besoin. Cela peut réduire les allers-retours lors de la planification et de la révision du code.

Ces caractéristiques sont également utiles lorsque vous refactorisez un système existant. Essayer de diviser une application héritée en son « frontend » et son « backend » peut être une mauvaise approche. Les changements d’un côté auront inévitablement un impact sur l’autre, vous devrez donc continuellement réconcilier les deux référentiels. L’utilisation d’un monorepo vous aide à refactoriser rapidement de larges pans de la base de code, sachant que vous avez un impact sur l’ensemble du système plutôt que sur des composants fragmentaires.

A qui s’adresse Monorepos ?

Les monorepos conviennent parfaitement aux grandes équipes avec plusieurs projets. Les avantages ne sont pas nécessairement évidents avec une poignée de petits projets. Les monorepos fonctionnent mieux à une échelle où il y aurait une inefficacité perceptible avec une approche multi-repo.

Les monorepos ne sont pas les mêmes que les monolithes. Un monolithe décrit généralement une application où les données et les couches de présentation sont mélangées. L’ensemble du système est déployé à chaque fois qu’un changement est effectué.

Les monorepos encapsulent généralement plusieurs systèmes. Ils ont plusieurs artefacts de sortie, tels qu’une API, un site Web et une application mobile. Tous les artefacts n’ont pas besoin d’être produits pour chaque changement. Les monorepos sont destinés à faciliter le partage de code et la refactorisation. Ils ne sont pas destinés à créer un système étroitement couplé qui est artificiellement lié les uns aux autres.

Le modèle n’est pas pour toutes les équipes. Dans de nombreux cas, il sera plus facile de travailler avec plusieurs référentiels. Ils semblent souvent plus logiques et peuvent être plus faciles à maîtriser. Vous n’aurez pas besoin de résoudre les conflits de fusion dans des parties disparates du système et il est plus facile de gérer les versions. Les pipelines CI seront plus rapides, car vous ne testerez pas chaque projet dans chaque pipeline.

Les référentiels dédiés présentent également un historique de validation plus propre. Les historiques Monorepo sont pollués par les commits effectués sur chaque projet du repo. Cela rend plus difficile le suivi de l’évolution des composants individuels.

Il est plus facile d’intégrer plusieurs référentiels avec des logiciels de contrôle de version tels que GitHub et GitLab. Ces outils supposent une correspondance un à un entre les référentiels et les projets. Il peut être fastidieux de suivre les problèmes et les demandes d’extraction dans un monorepo. Vous devrez utiliser avec diligence les balises pour étendre chaque problème au projet approprié.

Enfin, notez que la plupart des organisations avec monorepos utilisent une infrastructure spécialisée pour les prendre en charge. Git n’est pas conçu pour les monorepos, et il peut avoir des difficultés si vous atteignez une échelle suffisante. Avoir des millions d’objets dans votre historique de validation peut entraîner des ralentissements lorsque Git doit parcourir le graphique.

Résumé

Le modèle monorepo simplifie le partage de code et améliore la visibilité de vos actifs. Cela se fait au prix d’un historique de validation propre, d’un risque accru de conflits de fusion et d’un support médiocre des outils populaires. Vous pourriez également souffrir de problèmes de performances à mesure que le monorepo grandit.

La transparence d’un monorepo ne sera pas appropriée dans tous les scénarios. Si vous êtes dans un environnement étroitement réglementé, vous devrez peut-être utiliser des référentiels individuels afin de pouvoir appliquer des contrôles d’accès appropriés. Monorepos augmente également le risque si l’appareil d’un employé est perdu ou volé. Les personnes ayant un accès physique pourraient voir tout votre code au lieu de simplement les projets pertinents pour cette personne.

La décision d’utiliser un monorepo doit être basée sur vos propres projets, leurs dépendances inter-projets et les membres de votre équipe. Ne vous tournez pas vers les grandes entreprises technologiques et attendez-vous à observer leurs succès dans vos propres projets. Une bonne culture de code ne se limite pas au type de référentiel que vous utilisez. Les monorepos ont le plus de sens là où les gens collaborent déjà librement à des projets croisés de leur propre gré.