Les débats de mono et de multi repos sont souvent focalisés sur le code des applications, mais qu’en est-il du repository des tests ?

C’est ce que nous partageons dans cet article, analysant les choix de possibles de repository et de stockage de nos tests, en lien avec nos applications.

Nous prenons ici l’hypothèse que vos fichiers de configuration de tests sont accessibles pour les stocker sur un repository.

Vous pouvez en préambule consulter cet article Les principaux modèles de Monorepo et Multirepo à connaître.

Rejoignez la QE Unit pour accéder à plus de contenu exclusif de la communauté.

Pourquoi garder nos tests dans un repository ?

Inversons la question, qu’arrive-t-il sans un repository de nos tests ?

Chaque membre de l’équipe va stocker ses fichiers de tests, pouvant créer plusieurs problématiques à court et moyen-terme :

• Duplication des cas de tests
• Inexistence de modules de tests
• Perte de fichiers dans les différents stockages
• Conflit sur changements de mêmes tests
• Incapacité à utiliser les tests en l’absence d’un collaborateur
• Perte de temps en recherche, partage et utilisation

Nous pouvons faire mieux pour nos tests, qui plus est sont de réels actifs de nos entreprises.

De manière générale, ils doivent être stockés dans un mécanisme durable, sécurisé, versionné, accessible et maintenable.

La nécessité de portabilité peut également être pertinente, pour garder un contrôle de votre référentiel de tests en dehors d’un outil spécifique, vous laissant plus de flexibilité de changement.

Une fois correctement centralisés, il devient possible de supporter le partage et la collaboration autour de vos tests, résolvant une partie des problématiques identifiées.

Les mécanismes de versioning logiciel sont également porteurs de processus améliorant la qualité de nos tests, tels que le peer review supportées par les merge request de Git.

Vous avez également un accès facilité à l’historique, capacité de rollback, gestion des conflits, sur une collaboration étendue.

Le choix du mono ou multi-repos s’applique-t-il également au test ?

Nos fichiers de tests sont stockés dans une arborescence définie, souvent regroupés dans le concept de projet.

Nous avons donc le même choix d’organisation en mono ou multi repos pour nos tests, avec les mêmes trade-offs.

Similairement, les différents fichiers peuvent être organisés à notre convenance au sein d’un repos, leur affectation à un repo étant à un autre niveau de granularité.

Pour les tests, nous ajoutons la variante du lien avec le code des applications : faut-il garder nos tests avec nos applications ?

Quelles alternatives entre repository de code et de tests ?

Nous avons deux choix possibles pour chaque situation rencontrée.

La première consiste à maintenir nos tests avec le code de notre application au sein d’un même projet, comme un single mono-repo.

La seconde alternative sera de garder nos tests dans un projet à part, qu’il soit d’ailleurs dans le même ou différent repo.

Au travers des avantages et inconvénients de chaque solution, on comprend l’importance du contexte et d’en accepter les limites.

Quels critères de décision utiliser ?

Le contexte actuel et ses possibles évolutions sont les premiers éléments à clarifier pour articuler votre prise de décision.

Nos objectifs vont mettre en lumière quels sont les points que nous valorisons le plus tout en acceptant les limitations d’un modèle.

Je vous rassure, nous n’avons normalement pas besoin d’une matrice de décision compliquée.

Comme dans la vie courante, nous avons normalement besoin de 3 arguments pour pencher vers une alternative spécifique.

Voici les choix auxquels nous nous trouvons confrontés :

• Faut-il garder nos tests au sein de notre application ?
• Faut-il utiliser un mono ou multi-repos pour nos tests ?

Deux choix sont nécessaires pour nos repos de tests : mono ou multi repos, mono ou multi projects.

Antoine Craske

Nous pouvons déjà procéder par élimination avec les tests unitaires qui doivent être stockés avec le projet pour être intégrés au cycle de build.

À l’inverse nous pouvons stocker séparément code et tests si nous souhaitons maintenir nos pipelines de build exempts d’exclusion de dossier de tests ou autres conflits.

Prendre en compte le contexte organisationnel est pour moi prioritaire à des considérations techniques.

Si l’équipe de QA n’est pas au fait des modèles de branching, versioning et de collaboration distribuées, la séparation du code et des tests est préférable pour ne impacter les flux de développements, en attendant de les former.

Nous devons considérer le modèle organisationnel actuel et futur que nous souhaitons incentiver, non limité à la seule QA.

Un mono repo unique de code et de tests pour une entreprise favorise une visibilité, collaboration et partage transverse, au coût de la gestion d’un mono repo.

Ce modèle peut être adéquat aux entreprises poursuivant ces objectifs, avec une culture plutôt centralisée que décentralisée, que ce soit une start-up ou un grand groupe comme Google.

Nous pouvons avoir l’objectif d’accélération des développements en parallèle par de petites unités ayant les différentes fonctions présentes. Dans ce cas, un modèle de multi-repos laissera la liberté à l’inclusion ou non des tests dans les projets applicatifs.

Nos critères de décisions sont fortement liés à la culture, aux comportements et modèles de livraisons que nous souhaitons atteindre, supportés par un niveau de couplage plus ou moins fort des cycles de livraisons.

Quelles bonnes pratiques appliquer ?

De bonnes pratiques restent valides peu importe le modèle retenu.

Une vision holistique des équipes, de l’organisation actuelle et future nous guidera dans le choix et évolutions des repository.

Limiter la complexité aux besoins initiaux permettra de rapidement itérer et de créer de la valeur. Garder la suite en tête nous aura permis de garder de la marge de manœuvre.

Par exemple, vouloir trop vite mettre en place un modèle complet de multi-repos de Dev et de QA s’avère risqué pour un organisation non alignée et manquant de maturité collaborative.

Les basiques de convention de nommage et de versioning sont structurants dans tous les modèles, permettant de facilement trouver les projets de tests liés aux projets de développement par exemple.

Avoir un cycle de vie, repository et modèle de branching similaire entre code et test est souhaitable pour faciliter la compréhension, alignement et maintenabilité.

Les repository de QA nécessitent un réelle organisation

Le choix du mono et multi-repos est donc également structurant pour les artifacts de QA.

On pourrait d’ailleurs se demander s’il existe une réelle différence de choix entre le code des applications et des tests.

D’un point de vue local, nous avons bien affaire à des fichiers textes dont nous devons organiser le cycle de vie.

Par contre, la performance, facilité et compréhension de l’intégration des projets de QA impactent le processus de développement et de déploiement, d’où la nécessité de garder cette perspective plus large.

C’est avec une vision holistique d’un système que nous pouvons aligner les choix locaux pour des bénéfices plus globaux.