CI/CD para proyectos C#: GitHub Actions de la A a la Z

Introducción: ¿Por qué CI/CD para proyectos C#?

El desarrollo de aplicaciones modernas en C# y la plataforma .NET requiere no solo código de calidad, sino también un proceso confiable para entregarlo al usuario. Las compilaciones, pruebas y despliegues manuales no solo son lentos, sino que también son propensos a errores. Aquí es donde entra en juego CI/CD (Integración Continua / Despliegue Continuo), una práctica que automatiza todas las etapas del ciclo de vida del software.

GitHub Actions es una herramienta integrada de GitHub que permite crear potentes pipelines directamente en el repositorio. En este artículo, analizaremos cómo configurar un CI/CD completo para proyectos C# con GitHub Actions: desde una compilación simple hasta el despliegue automático. Aprenderá a escribir configuraciones YAML, optimizar las pruebas y evitar errores típicos.

Fundamentos de GitHub Actions para .NET

¿Qué es un workflow y un job?

Un workflow (flujo de trabajo) es un proceso automatizado que se ejecuta ante un evento determinado (push, pull request, creación de release). Se describe en un archivo .github/workflows/*.yml. Un workflow consta de uno o varios jobs (tareas) que se ejecutan en runners (máquinas virtuales). Cada job puede contener una secuencia de steps (pasos).

Para proyectos C#, los pasos clave son la restauración de dependencias (dotnet restore), la compilación (dotnet build), la ejecución de pruebas (dotnet test) y la publicación (dotnet publish).

Plantilla básica de workflow para .NET

A continuación se muestra un workflow mínimo para compilar y probar un proyecto C#. Guarde este código en el archivo .github/workflows/dotnet-ci.yml.

name: .NET CI\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n\n    steps:\n    - name: Checkout repository\n      uses: actions/checkout@v4\n\n    - name: Setup .NET\n      uses: actions/setup-dotnet@v4\n      with:\n        dotnet-version: '8.0.x'\n\n    - name: Restore dependencies\n      run: dotnet restore\n\n    - name: Build\n      run: dotnet build --no-restore --configuration Release\n\n    - name: Run tests\n      run: dotnet test --no-build --configuration Release --verbosity normal

Análisis de las líneas clave:

\n
• actions/checkout@v4 — clona el repositorio en el entorno de ejecución.
\n
• actions/setup-dotnet@v4 — instala la versión especificada del SDK de .NET.
\n
• dotnet restore — descarga los paquetes NuGet.
\n
• dotnet build --configuration Release — compila el proyecto en modo Release.
\n
• dotnet test — ejecuta todas las pruebas de la solución.
\n

Configuración avanzada: almacenamiento en caché y matriz de compilación

Almacenamiento en caché de paquetes NuGet

Cada ejecución de workflow comienza con un entorno limpio. Para acelerar el proceso, se puede almacenar en caché la carpeta ~/.nuget/packages. Esto es especialmente útil para proyectos grandes con decenas de dependencias.

steps:\n  - uses: actions/cache@v4\n    with:\n      path: ~/.nuget/packages\n      key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }}\n      restore-keys: |\n        ${{ runner.os }}-nuget-\n  - run: dotnet restore

La clave de caché se basa en el hash de los archivos del proyecto (.csproj). Si las dependencias no cambian, la caché se restaurará en segundos.

Matriz de compilación (Matrix Strategy)

Si su aplicación debe funcionar con diferentes versiones de .NET o sistemas operativos, use una matriz. GitHub Actions creará automáticamente un job separado para cada combinación.

jobs:\n  build:\n    strategy:\n      matrix:\n        os: [ubuntu-latest, windows-latest]\n        dotnet: ['6.0.x', '8.0.x']\n    runs-on: ${{ matrix.os }}\n    steps:\n      - uses: actions/checkout@v4\n      - name: Setup .NET\n