Sommaire
Sommaire- Nos contraintes
- L’onboarding sur un projet doit être simple
- Suivi des développements
- La documentation est versionnée
- Intégration continue / déploiement
- Les contres arguments
On entend souvent parler de monorepo et pourtant la force de l’habitude de séparer les repo (many repos) rend les gens frileux à utiliser ce principe.
Si vous vous intéressez au sujet, vous pourrez trouver de nombreux articles qui vantent les mérites du monorepo et sûrement tout autant sur ces problématiques.
Ils ont tous leur part de vérité.
Alors voici pourquoi, dans notre contexte d’agence digitale, et surtout pour notre entité – Clever Présence – nous y voyons de nombreux avantages.
Nos contraintes
- On a souvent dans un projet, plusieurs solutions qui doivent dialoguer entre elles, s’interfacer avec des briques communes,
- Les personnes peuvent changer fréquemment de projet,
- De nouvelles personnes qui arrivent sur le projet, parfois pour des interventions de seulement quelques jours.
L’onboarding sur un projet doit être simple
- Avec un monorepo, un nouveau dev arrive, il clone 1 seul repo et tout est là.
- Il est possible de faire l’installation de toutes les solutions en 1 seule commande.
- Le monorepo aide à uniformiser la façon de travailler des personnes / équipes.
- 1 seule façon de faire.
- Tout est centralisé.
Suivi des développements
Avec un seul repository tous les développements sont visibles de tous les développeurs. Cela simplifie donc :
- La revue de code,
- Le suivi des évolutions et des contrats entre les applications,
- En cas de soucis, il est simple pour toutes les équipes d’intervenir sur un des autres projets si nécessaires. On favorise ainsi la connaissance transverse de l’équipe. On casse les silos.
- Avec un monorepo, le process de CI est global. L’Intégration Continue est donc plus unifiée et il est ainsi possible de tester son architecture dans sa globalité, y compris les dépendances croisées. Cela peut être un inconvénient mais souvent c’est plus simple à gérer et faire évoluer.
La documentation est versionnée
Cette remarque est valable aussi dans le cas d’une utilisation de plusieurs repositories mais elle prend encore plus de valeurs avec le monorepo.
Documenter votre projet et versionner votre documentation dans le projet. Les devs/intégrateurs… ne devraient pas avoir à aller chercher dans un wiki (et attendre parfois x jours pour avoir un accès) les infos techniques du projet.
Les développeurs passent leur vie dans leur IDE et leur terminal, c’est tellement plus pratiques de lancer une recherche en local !
Intégration continue / déploiement
Il est simple de faire un script qui fait communiquer les 2, de gérer d’éventuelles problématiques de port…
Les contres arguments
- Le déploiement peut être plus compliqué / moins pratique quand on a des serveurs différents pour chaque application, si les applications ne sont pas conteneurisées. À noter qu’il est également tout à fait possible de splitter automatiquement un repo en plusieurs avec l’aide d’outils comme splitsh.
- Il faut prévoir les scripts de build et déploiement de façon maline dès le début du projet pour lever au maximum les dépendances entre les applications.
- Si l’on veut avoir des cycles de vie distincts entre les applications, il faut bien définir la stratégie de taggage du monorepo.
En conclusion, essayez de lancer votre prochain projet en mode monorepo et faites-vous votre propre avis.
Ressources :
Monorepo please don’t (en)
Monorepo please do (en)
Go monorepo (en)
Atlassian Monorepos tutorial (en)
Pourquoi votre entreprise devrait stocker son code dans un seul repo (fr) ↩︎
