Le fameux dilemme du repo.

Ce sujet provoque des débats animés dans des équipes défendant le Mono ou le Mutirepo comme le choix à faire.

Ce type d’échanges peut paraître sans fin, et qui plus est, loin du besoin métier.

Le choix du modèle de repo impacte directement la capacité des acteurs à itérer rapidement sur la chaîne logicielle.

Cet article partage comment aligner votre repository en fonction de votre contexte pour délivrer du Quality at Speed.

Suivez la QE Unit pour plus de contenu exclusif de Quality Engineering.

Comprenez les implications des alternatives

Avoir de la perspective sur un problème et ses possibles solutions donne une meilleure vision des implications propres à chaque alternative.

Dans le cas du repo, cela nous permet d’identifier les avantages et les inconvénients tout en restant factuel.

Quality, Speed, Complexity sont les axes d’évaluation en Quality Engineering.

Sans débattre des heures, le Multirepo à un cran de complexité supérieur au Monorepo par la distribution inhérente au modèle.

Les architectures distribuées – bien que compatibles dans les 2 modèles – ont largement contribué à populariser le multirepo pour de mauvaises raisons. 

Voici comment décider.

Si vous démarrez, utiliser un Monorepo

Utilisez un Monorepo si vous démarrez ou migrez un projet avec la gestion de version.

Le Monorepo est une solution simple et rapidement opérable permettant la collaboration d’une petite équipe.

Un Multirepo viendrait juste tout ralentir.

Votre priorité est la réalisation d’itération rapides de bout-en-bout ; n’allez donc pas complexifier avec des systèmes de branches multiples et inefficaces.

Le point d’architecture à sécuriser est de modulariser votre code pour faciliter l’évolutivité et la la possible isolation en service par la suite.

Gardez le Monorepo en période de croissance

Dans l’hypothèse où la start-up trouve son marché, vous entrerez dans une période de croissance nécessitant d’améliorer votre produit.

Vous aurez le challenge de délivrer plus de fonctionnalités avec plus de code et plus de développeurs.

Dans le lot, au moins une personne poussera le Multirepo.

Les arguments de séparation, découplage et scalabilité entreront en jeu, sans forcément être très explicites quant aux objectifs métier.

Vous devez tenir le cap pour éviter de créer vos propres problèmes avec plus de technologie.

Faîtes déjá en sorte de déployer facilement en Monorepo

Peu importe le modèle, le but est de maintenir une capacité de livraison de valeur en flux tendu, avec vitesse et stabilité.

Avant d’évaluer n’importe quel changement de modèle, assurez-vous de pouvoir déployer plusieurs fois par jour avec confiance.

Comme pour les enfants, c’est déjà compliqué avec un, et encore plus avec plusieurs.

Votre repository doit être supporté par des processus et outils alignés avec vos enjeux et modèles d’organisation.

Ce sont d’ailleurs uniquement ces critères qui pourraient vous faire changer de modèle.

Considérez un Multirepo avec maturité et alignement

La bascule vers un Multirepo doit être motivée par une volonté business ensuite cascadée dans la culture et la structure de l’organisation.

Une fois les étapes précédentes de croissance et de flux tendu de livraison, un Multi repo peut supporter la décentralisation d’une organisation.

Encore faut-il que ce soit un choix d’entreprise.

Les grandes entreprises réalisent une séparation de eleur Monorepo historique en deux grands repo pour isoler la complexité entre son front et son back-office.

Google est au contraire connu pour avoir maintenu le modèle de repo pour la majeure partie de son patrimoine de code.

Choisir entre Mono et Multirepo pour le Quality at Speed

La technologie reste le moyen de résoudre les problèmes pour vos utilisateurs, sans vouloir leur complexifier la vie.

Maintenir une chaîne de livraison logicielle en flux tendu se complexifie dans un environnement en continuelle réinvention.

Le choix le plus simple diminue la complexité et la possibilité d’induire de la dette additionnelle, un facteur différenciant d’accélération.

Vous n’avez pas de temps à perdre entre différents repository tant que la dimension et le modèle organisationnel ne le justifie.

Un bon nombre d’entreprises font marche arrière du Multi vers le Monorepo quand elles n’arrivent plus à livrer des changements en temps et en heure.

C’est d’ailleurs le cas de Theodo.