CI/CD para proyectos C#: GitHub Actions a nivel avanzado

Introducción: ¿Por qué el CI/CD básico no es suficiente?

El nivel inicial de CI/CD para proyectos C# generalmente se limita a ejecutar dotnet build y dotnet test. Sin embargo, cuando el proyecto crece hasta una arquitectura de microservicios, un monorepositorio o requiere soporte para múltiples versiones de .NET, el enfoque estándar se vuelve insuficiente. El tiempo de compilación aumenta, las pruebas se duplican y el proceso de despliegue de paquetes NuGet se vuelve una rutina.

En este artículo, analizaremos técnicas avanzadas de configuración de GitHub Actions para proyectos C# (.NET). Aprenderá cómo acelerar los pipelines con almacenamiento en caché, organizar pruebas paralelas, implementar compilaciones matriciales y configurar la publicación automática en NuGet. Todos los ejemplos de código están listos para usar en sus proyectos.

1. Compilación matricial y pruebas de múltiples versiones de .NET

La matriz (matrix) es una herramienta poderosa de GitHub Actions que permite ejecutar el mismo workflow con diferentes parámetros. Para C#, esto es indispensable cuando se necesita verificar la compatibilidad del código con .NET 6, .NET 8 y .NET 9.

Ejemplo de configuración matricial

Cree el archivo .github/workflows/ci-matrix.yml:

name: Matrix Build and Test

on:  push:    branches: [ main, develop ]  pull_request:    branches: [ main ]

jobs:  build:    runs-on: ubuntu-latest    strategy:      matrix:        dotnet-version: ['6.0.x', '8.0.x', '9.0.x']        configuration: ['Release', 'Debug']      fail-fast: false  # Continuar la compilación, incluso si una versión falla

    steps:    - uses: actions/checkout@v4        - name: Setup .NET ${{ matrix.dotnet-version }}      uses: actions/setup-dotnet@v4      with:        dotnet-version: ${{ matrix.dotnet-version }}        - name: Restore dependencies      run: dotnet restore        - name: Build      run: dotnet build --configuration ${{ matrix.configuration }} --no-restore        - name: Run tests      run: dotnet test --configuration ${{ matrix.configuration }} --no-build --verbosity normal

Puntos clave:

• fail-fast: false — permite ver los resultados de todas las versiones, incluso si una de ellas falla.
• La matriz puede incluir no solo versiones de .NET, sino también SO (por ejemplo, os: [ubuntu-latest, windows-latest]).
• Para un monorepositorio, se puede agregar el parámetro project-path y probar diferentes módulos.

2. Almacenamiento en caché de dependencias: acelera la compilación 3 veces

Cada ejecución de GitHub Actions comienza con un entorno limpio. Sin almacenamiento en caché, dotnet restore descargará todos los paquetes NuGet nuevamente cada vez. Para proyectos grandes, esto puede tomar de 2 a 5 minutos. La solución es almacenar en caché la carpeta ~/.nuget/packages.

Configuración avanzada de caché

Use la action actions/cache con una clave correcta que tenga en cuenta el archivo de bloqueo:

steps:  - uses: actions/checkout@v4

  - name: Cache NuGet packages    uses: actions/cache@v4    with:      path: ~/.nuget/packages      # Clave: hash del archivo de bloqueo + nombre del SO      key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }}      # Fallback a la clave anterior si el archivo de bloqueo no ha cambiado      restore-keys: |        ${{ runner.os }}-nuget-

  - name: Setup .NET    uses: actions/setup-dotnet@v4    with:      dotnet-version: '8.0.x'

  - name: Restore dependencies    run: dotnet restore

Consejo: Si el proyecto tiene varios archivos .csproj, use hashFiles('**/*.csproj', '**/packages.lock.json') para un hash más preciso.

3. Ejecución paralela de pruebas y generación de informes

Cuando el proyecto tiene cientos de pruebas, la ejecución secuencial puede llevar decenas de minutos. GitHub Actions admite la paralelización a nivel de jobs. Pero para