CI/CD pour les projets C# sur GitHub Actions : guide complet

Introduction : pourquoi CI/CD est important pour un développeur C#

Dans le développement logiciel moderne, les tests manuels et le déploiement sont inefficaces et risqués. Chaque fois qu'un développeur pousse du code dans un dépôt, il est nécessaire de s'assurer que la build n'est pas cassée, que les tests passent et que l'application est prête à être déployée. C'est là que CI/CD (Continuous Integration / Continuous Deployment) vient à la rescousse.

GitHub Actions est un outil d'automatisation intégré à GitHub qui permet de créer des workflows directement dans votre dépôt. Il est parfaitement adapté aux projets C# (.NET) car il prend en charge les runners Windows et Linux, et dispose d'un riche écosystème d'actions prêtes à l'emploi.

Dans cet article, nous allons voir comment configurer un pipeline CI/CD complet pour un projet C# en utilisant GitHub Actions : de la build et des tests à la publication d'un package NuGet ou au déploiement d'une application web.

Les bases de GitHub Actions : YAML et structure d'un workflow

Chaque workflow dans GitHub Actions est décrit dans un fichier YAML, stocké dans le répertoire .github/workflows/ de votre dépôt. Examinons la structure de base :

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

Éléments clés :

• on — les déclencheurs d'exécution (push, pull_request, schedule, etc.)
• jobs — un ensemble de tâches qui s'exécutent en parallèle ou séquentiellement
• runs-on — le système d'exploitation pour l'exécution (ubuntu-latest, windows-latest, macos-latest)
• steps — une séquence de commandes ou d'actions prêtes à l'emploi

Important : pour les projets .NET, utilisez l'action actions/setup-dotnet en spécifiant la version du SDK. Cela garantit que l'environnement contiendra la version .NET requise.

Configuration des tests et du linting du code C#

Un CI/CD de qualité ne peut pas se passer de tests automatiques et de vérification du style de code. Ajoutons à notre workflow des étapes de tests unitaires et d'analyse statique.

Tests unitaires avec xUnit et couverture de code

Supposons que vous ayez un projet avec des tests xUnit. Ajoutons une étape pour générer un rapport de couverture avec 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

Pour cela, vous devez ajouter le package coverlet.collector au projet de test. Exemple de commande :

dotnet add package coverlet.collector

Analyse statique avec Roslyn Analyzers

Ajoutons une vérification du code à l'aide des analyseurs intégrés de .NET :

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

Vous pouvez également utiliser des outils tiers, par exemple SonarCloud :

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