Monorepo avec C# : organisation du code dans les projets .NET

Monorepository avec C# : comment organiser le code dans les projets .NET

Le développement moderne en C# et .NET est de plus en plus confronté à un choix : stocker tous les projets liés dans un seul dépôt (monorepository) ou les séparer dans des dépôts individuels (multirepository). Un monorepository est une approche où le code de plusieurs applications, bibliothèques, tests et configurations est stocké dans un seul dépôt Git. Pour les grandes solutions d'entreprise, les microservices ou les bibliothèques NuGet, cette approche peut considérablement simplifier la gestion des dépendances, le refactoring et le déploiement.

Dans cet article, nous allons voir comment organiser correctement un monorepository avec C# dans l'écosystème .NET, en examinant la structure des dossiers, la configuration des projets, le CI/CD et les meilleures pratiques.

1. Avantages et inconvénients du monorepository dans .NET

Avant d'entrer dans les détails techniques, il est important de comprendre quand un monorepository est vraiment utile et quand il peut devenir un problème.

Avantages :

• Version unique des dépendances. Tous les projets du dépôt utilisent les mêmes versions de packages, ce qui élimine les conflits de versions.
• Refactoring simplifié. La modification d'une interface commune ou d'une API de bibliothèque est immédiatement visible dans tous les projets qui l'utilisent.
• Intégrité des commits. Les commits atomiques qui modifient à la fois la bibliothèque et l'application fonctionnent sans décalage temporel.
• Paramètres communs. Un seul fichier Directory.Build.props définit les paramètres de compilation, d'analyse de code et les versions pour tous les projets.

Inconvénients :

• Augmentation de la taille du dépôt. Avec le temps, le clonage et l'historique peuvent devenir très volumineux.
• Complexité du CI/CD. Un système de build intelligent est nécessaire pour ne pas tout reconstruire à chaque commit.
• Droits d'accès. Dans un seul dépôt, il est plus difficile de différencier l'accès pour différentes équipes.

Pour les projets .NET, le monorepository est particulièrement pratique lorsque vous avez une bibliothèque de classes commune (par exemple, Domain ou Common), plusieurs microservices ou API web qui en dépendent.

2. Structure du monorepository pour C# (.NET)

Une structure de dossiers correcte est la base d'un monorepository réussi. Examinons une organisation typique pour une solution comprenant plusieurs microservices, une bibliothèque et des tests.

MyApp/├── .github/│   └── workflows/│       └── ci.yml├── src/│   ├── MyApp.Common/          # bibliothèque commune│   │   ├── MyApp.Common.csproj│   │   └── ...│   ├── MyApp.Api.Orders/      # microservice pour les commandes│   │   ├── MyApp.Api.Orders.csproj│   │   └── ...│   └── MyApp.Api.Users/       # microservice pour les utilisateurs│       ├── MyApp.Api.Users.csproj│       └── ...├── tests/│   ├── MyApp.Common.Tests/│   │   ├── MyApp.Common.Tests.csproj│   │   └── ...│   └── MyApp.Api.Orders.Tests/│       ├── MyApp.Api.Orders.Tests.csproj│       └── ...├── Directory.Build.props       # paramètres communs pour tous les projets├── MyApp.sln                   # solution pour Visual Studio└── README.md

Points clés :

• Tous les projets se trouvent dans le dossier src/, les tests dans tests/. C'est une norme adoptée par la communauté .NET.
• Le fichier Directory.Build.props définit les propriétés communes : TargetFramework, Nullable, ImplicitUsings, les versions de packages, etc.
• Un seul fichier SLN simplifie le travail dans l'IDE, mais avec un grand nombre de projets, il est possible de diviser en plusieurs solutions.

Exemple de Directory.Build.props :

<Project>  <PropertyGroup>    <TargetFramework>net8.0</TargetFramework>    <Nullable>enable</Nullable>    <ImplicitUsings>enable</ImplicitUsings>    <TreatW