CI/CD pour projets C# : GitHub Actions niveau avancé

Introduction : Pourquoi le CI/CD de base ne suffit-il pas ?

Le niveau de base du CI/CD pour les projets C# se limite généralement à une simple exécution de dotnet build et dotnet test. Cependant, lorsque le projet s'étend à une architecture de microservices, un monorepo ou nécessite la prise en charge de plusieurs versions de .NET, l'approche standard devient insuffisante. Le temps de compilation augmente, les tests sont dupliqués et le processus de déploiement des packages NuGet devient une routine.

Dans cet article, nous allons explorer les techniques avancées de configuration de GitHub Actions pour les projets C# (.NET). Vous apprendrez à accélérer les pipelines grâce à la mise en cache, à organiser des tests parallèles, à mettre en œuvre des compilations matricielles et à configurer la publication automatique sur NuGet. Tous les exemples de code sont prêts à être utilisés dans vos projets.

1. Compilation matricielle et test de plusieurs versions de .NET

La matrice (matrix) est un outil puissant de GitHub Actions qui permet d'exécuter un même workflow avec différents paramètres. Pour C#, c'est indispensable lorsqu'il faut vérifier la compatibilité du code avec .NET 6, .NET 8 et .NET 9.

Exemple de configuration matricielle

Créez le fichier .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  # Continuer la compilation même si une version échoue

    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

Points clés :

• fail-fast: false — permet de voir les résultats pour toutes les versions, même si l'une d'elles échoue.
• La matrice peut inclure non seulement les versions de .NET, mais aussi les OS (par exemple, os: [ubuntu-latest, windows-latest]).
• Pour un monorepo, vous pouvez ajouter le paramètre project-path et tester différents modules.

2. Mise en cache des dépendances : accélérer la compilation par 3

Chaque exécution de GitHub Actions démarre dans un environnement propre. Sans mise en cache, dotnet restore téléchargera à chaque fois tous les packages NuGet. Pour les grands projets, cela peut prendre 2 à 5 minutes. La solution est la mise en cache du dossier ~/.nuget/packages.

Configuration avancée du cache

Utilisez l'action actions/cache avec une clé appropriée qui prend en compte le fichier de verrouillage :

steps:  - uses: actions/checkout@v4

  - name: Cache NuGet packages    uses: actions/cache@v4    with:      path: ~/.nuget/packages      # Clé : hash du fichier de verrouillage + nom de l'OS      key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }}      # Fallback sur la clé précédente si le fichier de verrouillage n'a pas changé      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

Conseil : Si le projet contient plusieurs fichiers .csproj, utilisez hashFiles('**/*.csproj', '**/packages.lock.json') pour un hash plus précis.

3. Exécution parallèle des tests et génération de rapports

Lorsqu'un projet contient des centaines de tests, l'exécution séquentielle peut prendre des dizaines de minutes. GitHub Actions prend en charge le parallélisme au niveau des jobs. Mais pour