Explorer monorepo par rapport à plusieurs dépôts
Un référentiel est l’emplacement où votre historique de travail est stocké, généralement dans un sous-répertoire Git.
Comment organiser votre référentiel de code ? Les équipes de développement visent à séparer les préoccupations dans leurs logiciels et référentiels. À mesure que le temps passe, il n’est pas rare que les référentiels de code deviennent encombrés de code et d’artefacts non pertinents.
Quand il s’agit d’organiser vos dépôts, il existe deux philosophies principales : l’utilisation d’un référentiel unique (Monorepo) ou de plusieurs référentiels.
- Monorepos est un modèle de contrôle de code source où tout le code source est conservé dans un référentiel. Il est facile de donner à tous les employés l’accès à tout en même temps. Clonez-le et vous avez terminé.
- L’organisation de vos projets dans des référentiels distincts est appelée plusieurs référentiels.
La différence fondamentale entre le référentiel mono et plusieurs philosophies de dépôt est ce qui permet aux équipes de travailler ensemble plus efficacement. Dans un scénario extrême, la vue de plusieurs dépôts suggère que chaque sous-équipe peut travailler dans son propre dépôt. Il leur permet de travailler dans leurs domaines respectifs à l’aide des bibliothèques, outils et workflows de développement qui optimisent leur productivité.
Le coût de consommation de tout ce qui n’est pas développé dans un référentiel donné équivaut à utiliser une bibliothèque ou un service tiers, même s’il a été écrit par quelqu’un assis à proximité.
Si vous rencontrez un bogue dans votre bibliothèque, vous devez l’adresser dans le référentiel correspondant. Une fois que vous avez publié un nouvel artefact, vous pouvez revenir à votre référentiel et apporter les modifications de code nécessaires. Toutefois, si le bogue se trouve dans une base de code différente ou implique différentes bibliothèques, outils ou flux de travail, vous devrez peut-être demander de l’aide auprès du propriétaire de ce système et attendre leur réponse.
Lorsque vous utilisez la vue monopo, la gestion des graphiques de dépendances complexes peut augmenter la difficulté d’utiliser un référentiel unique. Les avantages de permettre à différentes équipes de travailler indépendamment ne sont pas substantiels. Certaines équipes peuvent trouver un moyen efficace de travailler, mais cela peut ne pas être vrai pour tous les groupes. En outre, d’autres équipes peuvent choisir une approche non optimale, ce qui annule les avantages obtenus par d’autres personnes. La consolidation de tout votre travail dans un référentiel mono vous permet de vous concentrer sur la surveillance étroite de ce référentiel unique.
Le souci d’apporter des modifications dans d’autres dépôts ou d’attendre que les équipes apportent des modifications pour vous est évitée dans un référentiel mono où tout le monde peut modifier n’importe quoi.
Si vous découvrez un bogue dans une bibliothèque, il est aussi facile de trouver un bogue dans votre propre code.
Note
Dans Azure DevOps, il est courant d’utiliser un référentiel distinct pour chaque solution associée au sein d’un projet.