Leur nature diffère, mais lorsqu’il s’agit de plusieurs projets liés entre eux, comment préférez-vous les regrouper (ou ne pas les regrouper) ?
Par exemple, pour un même service, s’il y a un front-end, un back-end (API), du serverless, des batchs, des pipelines, etc.
-
Mono-repo
Si le service est le même, alors il n’y a qu’un seul dépôt ! Chaque projet est organisé sous forme de package/dossier.
-> Mais alors, comment gérer les commits… ? Les hooks comme le CI/CD ou le pre-commit vont devenir complexes… -
Sous-modules Git
Si leur nature est différente, il faut au moins gérer l’historique Git séparément ! Mais en essayant quand même de regrouper au maximum…
-> Il y a aussi la courbe d’apprentissage avec la synchronisation des sous-modules, les merges deviennent plus complexes… est-ce que les autres développeurs suivront ? -
Repo séparés
Simplement ! Si c’est un projet différent, alors le dépôt est différent aussi !
-> Si je veux voir le service A, je dois regarder quel repo ? Ah, celui-ci, celui-là… et puis quoi d’autre déjà…
J’ai l’impression qu’il n’y a pas de bonne réponse, mais je suis curieux de savoir ce que vous préférez et pourquoi !
16 commentaires
Je préfère les repos séparés...
Quand je me pose la question « si je veux voir l’historique de l’API liée à cette fonctionnalité, qu’est-ce que je dois regarder ? », je trouve plus pratique d’associer un repo à une fonctionnalité.
J’utilise généralement un monorepo dans la plupart des cas, mais il y a deux situations où j’utilise des submodules.
Quand on fait appel à un prestataire externe pour le publishing.
J’utilise des submodules quand je ne veux pas exposer au prestataire externe autre chose que les informations nécessaires au publishing.
Quand il faut personnaliser une solution externe.
J’utilise particulièrement des submodules lorsqu’il s’agit d’une solution qui fournit un système de plugins.
J’enregistre cette solution externe comme submodule, puis je travaille en plaçant mes plugins dans le répertoire des plugins via des symlinks, par exemple. Mes plugins sont gérés en versioning séparément, tandis que la solution externe peut conserver son propre contrôle de version tel quel, ce qui est un avantage.
On dirait que tout le monde a eu une mauvaise expérience avec les submodules... Ce serait bien s'il existait un outil pour améliorer ça.
Si vous êtes sûr de ne faire que des merge commits, mono-repo,
si vous allez rebase en permanence, multi-repo,
les submodules ? Utilisez simplement les liens de répertoire fournis par l’OS…
Avant, j’utilisais simplement des repos indépendants pour chacun, mais récemment j’ai complètement changé d’approche pour utiliser des submodules.
À l’époque, ma compréhension de git était limitée, donc je n’arrivais pas à exploiter correctement les submodules, mais aujourd’hui je pense qu’il vaut mieux les utiliser.
Cela dit, avec les submodules, il faut faire un commit dans le submodule concerné puis refaire un commit dans le repo parent ; du coup, un décalage temporel se crée entre les deux, ce qui semble entraîner un problème de cohérence du repo.
https://monorepo.tools/
Si vous ne connaissez pas encore ce site, je pense que ça vaut le coup d’y jeter un œil.
D’après mon expérience personnelle, je déconseille les submodules.
Si vous voulez partager le code d’un autre dépôt via des submodules, il vaut probablement mieux le distribuer sous forme de package.
Dans notre entreprise, il y a peu de membres par projet, et comme les langages et stacks techniques du frontend et du backend sont séparés, il n’y avait presque pas de contributions croisées entre métiers. Comme pour tous les systèmes IT, j’ai l’impression qu’au final cela suit surtout l’organisation de l’entreprise.
Oh... donc c’est une approche qui permet d’ajuster la visibilité du code des autres selon que l’alignement de l’interface est fait par les humains ou par l’outil.
Comme je n’ai pas d’expérience avec les mono-repos, j’ai une question. Quand on travaille en mono-repo, est-ce que les modules communs à plusieurs projets ou services (par ex. un design system) sont généralement intégrés dans ce même mono-repo ? Ou bien est-ce qu’ils finissent inévitablement dans un dépôt séparé, référencé ensuite par les autres ?
Pour le module commun, je crois qu’on y accédait sous forme de symlink à l’aide d’outils comme yarn workspace !
Dans mon entreprise comme sur mes projets personnels, je gère le frontend, le backend, les batchs, etc., dans un seul dépôt git, sans les séparer.
Dans certains cas, il est plus pratique de modifier les deux en même temps que de préserver la rétrocompatibilité. Et puis, comme les équipes sont petites dans les deux cas, je me dis qu’il n’y a pas vraiment d’avantage à les séparer pour le principe… Le travail nécessaire pour configurer GitHub Actions afin de n’exécuter que les parties modifiées restait tout à fait acceptable. Surtout, au-delà de la séparation backend/frontend, j’apprécie le fait que chacun puisse contribuer au travail de l’autre. (Par exemple, en travaillant sur le frontend, si quelque chose est nécessaire côté backend, on peut l’ajouter directement, ou corriger soi-même une erreur, etc.)
Hum, on dirait bien que vous préférez les monorepos quand l’organisation reste petite ou que les rôles ne sont pas très cloisonnés ! Le fait que l’historique Git se mélange un peu ne vous dérange pas tant que ça ? (Après tout, c’est du code que tout le monde consulte de toute façon ? )
Ce qui est intéressant, c’est que c’est aussi le cas dans mon side project. Jusqu’à présent, j’ai travaillé avec environ 12 personnes, et chacun prend en charge son travail d’un seul tenant, du front-end au back-end. On dirait aussi quelque chose de proche du vertical slice.
Je ne considère pas vraiment que ce soit quelque chose de mélangé. Il arrive souvent que le front-end et le back-end soient tous les deux modifiés dans une même PR. Chez nous, l’idée de base est que nous sommes quatre full-stack, donc indépendamment du back-end ou du front-end, on relit le travail des autres et on doit aussi connaître les changements.
Si les modules ne sont pas très gros, alors monorepo
si les modules sont volumineux, alors submodules.
Ou bien, si vous voulez que, lors de la publication en open source, on ne puisse contribuer qu’aux submodules et que le dépôt principal reste géré en interne,
il semble logique de les séparer en submodules.
Mais avec des submodules, j’ai l’impression que, lors d’une mise en open source, cela complique un peu la rédaction de la documentation pour que d’autres utilisateurs puissent contribuer, notamment sur les tests ou le build.
Donc, personnellement, sauf si les modes de contribution diffèrent entre les deux, je choisirais soit un monorepo,
soit des dépôts séparés sur GitHub, en gérant chaque élément via une distribution en package ou sous forme d’image Docker.
Je n’avais pas pensé à l’open source dans ce contexte, merci pour votre avis !