Monorepositorio con C#: organización del código en proyectos .NET

Monorepositorio con C#: cómo organizar el código en proyectos .NET

El desarrollo moderno con C# y .NET se enfrenta cada vez más a una elección: almacenar todos los proyectos relacionados en un solo repositorio (monorepositorio) o dividirlos en repositorios separados (multirrepositorio). Un monorepositorio es un enfoque en el que el código de varias aplicaciones, bibliotecas, pruebas y configuraciones se almacena en un único repositorio de Git. Para grandes soluciones empresariales, microservicios o bibliotecas NuGet, este enfoque puede simplificar significativamente la gestión de dependencias, la refactorización y el despliegue.

En este artículo, analizaremos cómo organizar correctamente un monorepositorio con C# en el ecosistema .NET, revisaremos la estructura de carpetas, la configuración de proyectos, CI/CD y las mejores prácticas.

1. Ventajas y desventajas del monorepositorio en .NET

Antes de profundizar en los detalles técnicos, es importante entender cuándo un monorepositorio es realmente útil y cuándo puede convertirse en un problema.

Ventajas:

• Versión única de dependencias. Todos los proyectos dentro del repositorio utilizan las mismas versiones de paquetes, lo que elimina conflictos de versiones.
• Refactorización simplificada. El cambio de una interfaz común o API de una biblioteca se ve inmediatamente en todos los proyectos que la utilizan.
• Integridad de los commits. Los commits atómicos que modifican tanto la biblioteca como la aplicación funcionan sin brechas temporales.
• Configuraciones compartidas. Un único archivo Directory.Build.props establece las configuraciones de compilación, análisis de código y versiones para todos los proyectos.

Desventajas:

• Crecimiento del tamaño del repositorio. Con el tiempo, la clonación y el historial pueden volverse muy grandes.
• Complejidad de CI/CD. Se requiere un sistema de compilación inteligente para no reconstruir todo en cada commit.
• Permisos de acceso. En un solo repositorio es más difícil delimitar el acceso para diferentes equipos.

Para proyectos .NET, el monorepositorio es especialmente conveniente cuando tienes una biblioteca de clases común (por ejemplo, Domain o Common), varios microservicios o APIs web que dependen de ella.

2. Estructura del monorepositorio para C# (.NET)

Una estructura de carpetas correcta es la base de un monorepositorio exitoso. Consideremos una organización típica para una solución que incluye varios microservicios, una biblioteca y pruebas.

MyApp/├── .github/│   └── workflows/│       └── ci.yml├── src/│   ├── MyApp.Common/          # biblioteca común│   │   ├── MyApp.Common.csproj│   │   └── ...│   ├── MyApp.Api.Orders/      # microservicio para pedidos│   │   ├── MyApp.Api.Orders.csproj│   │   └── ...│   └── MyApp.Api.Users/       # microservicio para usuarios│       ├── MyApp.Api.Users.csproj│       └── ...├── tests/│   ├── MyApp.Common.Tests/│   │   ├── MyApp.Common.Tests.csproj│   │   └── ...│   └── MyApp.Api.Orders.Tests/│       ├── MyApp.Api.Orders.Tests.csproj│       └── ...├── Directory.Build.props       # configuraciones comunes para todos los proyectos├── MyApp.sln                   # solución para Visual Studio└── README.md

Puntos clave:

• Todos los proyectos se encuentran en la carpeta src/, las pruebas en tests/. Este es un estándar adoptado por la comunidad .NET.
• El archivo Directory.Build.props establece propiedades comunes: TargetFramework, Nullable, ImplicitUsings, versiones de paquetes, etc.
• Un único archivo SLN simplifica el trabajo en el IDE, pero con una gran cantidad de proyectos se puede dividir en varias soluciones.

Ejemplo de Directory.Build.props:

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