CI/CD para proyectos C# en GitHub Actions: guía completa

Introducción: por qué CI/CD es importante para un desarrollador de C#

En el desarrollo de software moderno, las pruebas manuales y el despliegue son ineficientes y riesgosos. Cada vez que un desarrollador hace push de código al repositorio, surge la necesidad de asegurarse de que la compilación no se haya roto, que las pruebas pasen y que la aplicación esté lista para el despliegue. Aquí es donde entra en juego CI/CD (Integración Continua / Despliegue Continuo).

GitHub Actions es una herramienta de automatización integrada en GitHub que permite crear flujos de trabajo (workflows) directamente en tu repositorio. Es ideal para proyectos de C# (.NET), ya que admite runners tanto de Windows como de Linux, y también cuenta con un rico ecosistema de acciones (actions) predefinidas.

En este artículo, analizaremos cómo configurar un pipeline completo de CI/CD para un proyecto de C# usando GitHub Actions: desde la compilación y las pruebas hasta la publicación de un paquete NuGet o el despliegue de una aplicación web.

Fundamentos de GitHub Actions: YAML y estructura de un workflow

Cada workflow en GitHub Actions se describe en un archivo YAML, que se almacena en el directorio .github/workflows/ de tu repositorio. Veamos la estructura básica:

name: .NET CI/CD

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

jobs:  build:    runs-on: ubuntu-latest

    steps:    - name: Checkout code      uses: actions/checkout@v4

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

    - name: Restore dependencies      run: dotnet restore

    - name: Build      run: dotnet build --configuration Release --no-restore

    - name: Run tests      run: dotnet test --configuration Release --no-build --verbosity normal

Elementos clave:

• on — disparadores de ejecución (push, pull_request, schedule, etc.)
• jobs — conjunto de tareas que se ejecutan en paralelo o secuencialmente
• runs-on — sistema operativo para la ejecución (ubuntu-latest, windows-latest, macos-latest)
• steps — secuencia de comandos o actions predefinidas

Importante: para proyectos .NET, usa la action actions/setup-dotnet especificando la versión del SDK. Esto garantiza que el entorno contendrá la versión necesaria de .NET.

Configuración de pruebas y linting de código C#

Un CI/CD de calidad no puede prescindir de pruebas automáticas y verificación del estilo del código. Agreguemos a nuestro workflow las etapas de pruebas unitarias y análisis estático.

Pruebas unitarias con xUnit y cobertura de código

Supongamos que tienes un proyecto con pruebas en xUnit. Añadamos un paso para generar un informe de cobertura usando Coverlet:

- name: Run tests with coverage  run: |    dotnet test --configuration Release \      --no-build \      --verbosity normal \      /p:CollectCoverage=true \      /p:CoverletOutputFormat=opencover \      /p:CoverletOutput=./coverage.xml

- name: Upload coverage to Codecov  uses: codecov/codecov-action@v3  with:    files: ./coverage.xml    flags: unittests    fail_ci_if_error: false

Para esto, es necesario agregar el paquete coverlet.collector al proyecto de pruebas. Ejemplo de comando:

dotnet add package coverlet.collector

Análisis estático con Roslyn Analyzers

Agreguemos una verificación de código usando los analizadores integrados de .NET:

- name: Run Roslyn analyzers  run: dotnet build --configuration Release --warnaserror -p:RunAnalyzersDuringBuild=true

También se pueden usar herramientas de terceros, por ejemplo, SonarCloud:

- name: SonarCloud Scan  uses: SonarSource/sonarcloud-github-action@master  env:    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}    SONAR_TOKEN: ${{ secrets.SON