Explorer les différences entre monorepos et dépôts multiples
Un référentiel est l’emplacement où est stocké votre historique de travail, généralement dans un sous-répertoire git.
Comment devez-vous organiser votre référentiel de code ? Les équipes de développement souhaitent éviter de retrouver les problèmes présents dans leurs logiciels dans les référentiels. Au fil du temps, il n’est pas rare que les référentiels de code soient encombrés de code et d’artefacts sans intérêt.
En matière d’organisation de référentiels, deux philosophies principales s’affrontent : il y a celle qui penche pour l’utilisation d’un seul référentiel (monoréférentiel) et celle qui prône l’utilisation de plusieurs référentiels (multiréférentiel).
- Les monoréférentiels représentent un modèle de contrôle de code source dans lequel l’ensemble du code source est conservé dans un même référentiel. Il est facile d’accorder à tous les employés l’accès à tout en une seule opération. Clonez-le, et le tour est joué.
- Le fait d’organiser les projets dans des référentiels distincts est ce que l’on appelle le multiréférentiel.
La différence fondamentale qui existe entre la philosophie du monoréférentiel et celle du multiréférentiel est ce qui permet aux équipes de travailler ensemble le plus efficacement possible. Dans un scénario extrême, la vision du multiréférentiel suggère que chaque sous-équipe peut travailler dans son propre référentiel. Chacune d’elles peut travailler dans son domaine respectif en utilisant les bibliothèques, les outils et les workflows de développement qui optimisent sa productivité.
Le fait d’utiliser ce qui n’est pas développé dans un référentiel donné revient à utiliser une bibliothèque ou un service tiers, même si les éléments en question ont été écrits par une personne assise à côté de vous.
Si vous rencontrez un bogue dans votre bibliothèque, vous devez le corriger 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 nécessaires au code. En revanche, si le bogue se trouve dans une base de code différente ou si plusieurs outils, workflows ou bibliothèques ont été utilisés, vous devrez peut-être demander de l’aide au propriétaire de ce système et attendre sa réponse.
Dans le cas du monoréférentiel, la gestion des graphes de dépendances complexes peut accroître la difficulté à utiliser un seul référentiel. Le fait que les différentes équipes puissent travailler de manière indépendante ne présente pas des avantages substantiels. Si certaines équipes peuvent trouver un moyen efficace de travailler, cela n’est pas nécessairement le cas de tous les groupes. En outre, d’autres équipes peuvent suivre une approche perfectible, ce qui a pour effet de neutraliser les avantages acquis par les autres. Le fait de regrouper tout votre travail dans un monoréférentiel vous permet d’assurer une supervision rapprochée de ce référentiel unique.
Dans un monoréférentiel, où quiconque peut changer ce qu’il souhaite, vous échappez aux tracas liés à la nécessiter d’apporter des modifications dans d’autres référentiels ou d’attendre que les équipes apportent des modifications.
Si vous découvrez un bogue dans une bibliothèque, il est aussi facile de le corriger que de trouver un bogue dans votre propre code.
Remarque
Dans Azure DevOps, il est courant d’utiliser un référentiel distinct pour chaque solution associée au sein d’un projet.