Une conversation initialement de repository a vite tendance à basculer sur la gestion de branches ou de dépendances.
Quel est le vrai impact d’un mono ou multirepo sur l’architecture, l’organisation et les processus de développement?
C’est ce que nous allons partager autour du partage des mythes de nos fameux modèles de repository.
Vous pouvez consulter ces articles en guise d’introductions aux repos L’histoire épique du Mono vs Multi-Repo n’est pas nouvelle et Les principaux modèles de Monorepo et Multirepo à connaître.
Rejoignez la QE Unit pour accéder à plus de contenu exclusif de la communauté.
Le Repo n’est pas l’architecture applicative
Votre repository est le stockage du code source, en particulier des projets des diverses applications.
L’organisation interne de votre projet reflète en grande partie le style d’architecture retenu, qu’il soit en SOA ou microservices.
Vous pouvez bien stocker vos projets, leurs répertoires et sous-répertoires comme vous le désirez, que ce soit en mono ou multi-repos.
L’architecture de votre application est donc un thème bien plus large dont le repository est l’un des éléments en support.
Monorepo != monolith; Multirepo != microservices; continued;
Antoine Craske
Différents niveaux sont à considérer dans l’architecture de votre application :
- L’architecture globale de votre SI
- L’architecture localisée par contexte (e.g. Front-office, back-office, Data)
- L’architecture locale à une application
Le style d’architecture retenu peut être aligné entre différents contextes, même si sa tendance sera à la diversification par la croissance.
Certaines architectures sont plus adaptées à un modèle de repo particulier, dans un contexte organisationnel également aligné.
Par exemple, une architecture distribuée de microservices supportée par des équipes animées de façon décentralisée sera plus adaptée à un modèle de multi-repo.
C’est par exemple le cas de Spotify et Netflix.
Il faut retenir que :
- Le style d’architecture et le modèle de repository sont des choix différents
- Un style d’architecture doit s’analyser à différents grains, tout comme votre modèle de repository
- Il existe le besoin de coordonner votre décision de repository et d’architecture par leurs adhérences
Le Repo n’est pas la stratégie de branching
Continuons notre analyse dans le processus de développement.
Quel est l’impact du trunk-based development, gitflow et autres modèles de gestion de branches sur le sujet du repo?
Prenons des exemples.
Nous voulons mettre en place du trunk-based development à l’échelle à la Google et nous posons la question du mono vs multirepo.
Les deux modèles sont possibles.
Leur implémentation aura des implications différentes suivants les modèles :
- Le modèle de mono-repo nécessite un outillage et des processus de CI/CD plus spécifiques
- Le multirepo se résumera à une implémentation plus localisée et décentralisée de pipelines de builds de et releases par projets
La même logique s’applique aux autres modèles de branching et de repos.
À retenir sur ce thème :
- Votre branching strategy n’est pas votre modèle de repo
- L’implémentation de votre branching strategy a des implications différentes suivants votre modèle de repository
Le Repo n’est pas la gestion des dépendances
Ah les dépendances, le cauchemar du logiciel, on aimerait tant pouvoir s’en débarrasser.
Quelques exemples de dépendances :
- La version de Java utilisée par les projets
- Votre bibliothèque interne standard de logging
- Une librairie “core” avec un modèle objet métier
La réalité est que cette complexité existe et aura tendance à l’entropie, d’où le besoin de la contenir.
Le gestion des dépendances nécessaires peut être abordée comme pour les repos avec deux approches :
- Centralisée : les fameuses bibliothèques et libs communes
- Décentralisée : le fameux péché de la duplication de code
Chacun des modèles peut être mis en place peu importe votre modèle de repository.
Vous pouvez dupliquer du code, fonctionnel ou technique, dans différents répertoires de votre monorepo ou de votre multirepo.
Vous pouvez également choisir d’utiliser des librairies référencées entre projets sur les deux modèles.
Chacun des modèles a des implications différentes dans votre repository.
Un monorepo permettra d’avoir une vue globale plus facilement, par exemple sur la duplication, ou de mettre à jour les dépendances plus directement.
À l’inverse, visualiser du code dupliqué entre divers repository sera plus difficile à visualiser.
Ce qu’il faut retenir :
- Le modèle de repository n’est pas votre gestion de dépendances
- Vous pouvez combiner divers modes de gestion de dépendances
- Vos mécanismes de gestion des dépendances sont à adapter en fonction de votre modèle de repo
Le Repo n’est pas la gestion de configuration
La suite logique des dépendances et celle de la gestion de version.
Nous passerons le sujet du choix de Git, SVN ou autres technologies de gestion de version, qui a eu tendance à se standardiser par les apports du modèle Git (quand compris et utilisés à bon escient).
Focalisons nous ici sur la stratégie et les pratiques de versioning :
- Quelles règles de nommage pour nos artifacts ? (e.g. major.minor.fix)
- Quelle politique de mise à jour de bibliothèques internes ?
- Quelles pratiques de mise à jour des APIs publiques ?
Autant de questions auxquelles vous devez répondre et mettre en place indépendamment de votre choix de repository.
Comme pour les autres sujets, leur implémentation, visibilité et maintenance sera différente suivant le modèle de repo.
Je vous passe les deux points de conclusions qui commencent à se répéter.
Le Repo n’est pas la pipeline de déploiement
On pourrait presque penser travailler dans l’industrie pétrolière à tellement parler de pipelines.
Leur processus consiste en trois étapes principales :
- Build : Construire les artifacts
- Deploy : Déployer dans les différents environnements
- Release : Activer les services, plus ou moins graduellement
Le lien avec votre repo est assez structurant, à minima l’étape de Build contiendra le chemin de votre repository configuré.
Si votre projet a une dépendance core mise à jour, il devrait probablement être mis à jour également.
Si un projet à des répertoires désorganisés, mixant des technologies par répertoires, vous devrez probablement trier et organiser cela avant de pouvoir configurer vos pipelines.
Le lien le plus fort entre vos pipelines et votre modèle de repository est donc plutôt situé au niveau des projets et applications.
Le modèle de split-repo est par contre celui le plus structurant en lien avec vos pipelines, devant ajouter une étape additionnelle de séparation de répertoires avant de pouvoir construire votre application.
Même conclusion : différents sujets avec des adhérences plus ou moins fortes en fonction du modèle.
Le Repo n’est pas votre culture d’engineering
Un monorepo ne nous fera pas devenir Google.
Malheureusement, un multirepo ne nous transformera pas non plus en prochain Spotify ou Netflix.
Par contre, ces grands acteurs ont fortement pondéré leur décision de repo en fonction de la culture d’engineering qu’il souhaitait développer.
Gardez en tête les différentes notions de corrélation et de causalité.
Vous ne deviendrez pas Google uniquement par l’adoption d’un monorepo, désolé.
Antoine Craske
Google a largement investi dans son monorepo qui démontré sa capacité d’expansion et même d’accélération de commits au fur et à mesure des années.
Une culture de partage globale, de construction d’un produit commun et des pratiques comme le trunk-based development sont au cœur de leurs processus.
Spotify a également investi largement dans sa culture d’engineering sur un modèle plus décentralisé supporté par du multirepo.
Dans les deux cas, les modèles ont supporté la croissance et l’expansion de l’organisation.
Le point clef est qu’un alignement du modèle de repository avec l’architecture de l’entreprise, de l’organisation et des applications est structurante.
Le Repo est structurant mais n’est pas tout
Le partage de ces différents mythes reflète l’importance du choix de repository.
Le pattern saillant est les autres composantes de votre architecture de développement y sont intimement liées sans pour autant conditionner un choix particulier.
La compréhension des différents modèles reste fondamentale pour identifier et aligner les impacts dans les divers processus.
C’est d’ailleurs l’objet d’un futur article du guide du mono et multi-repos.
Références
https://hackernoon.com/mono-repo-vs-multi-repo-vs-hybrid-whats-the-right-approach-dv1a3ugn