CI/CD pour les projets C# : GitHub Actions de A à Z

Introduction : Pourquoi les projets C# ont-ils besoin de CI/CD ?

Le développement d'applications modernes en C# et sur la plateforme .NET nécessite non seulement un code de qualité, mais aussi un processus fiable pour le livrer à l'utilisateur. Les builds, tests et déploiements manuels sont non seulement lents, mais aussi sujets aux erreurs. C'est là qu'intervient le CI/CD (Continuous Integration / Continuous Deployment) — une pratique qui automatise toutes les étapes du cycle de vie du logiciel.

GitHub Actions est un outil intégré à GitHub qui permet de créer des pipelines puissants directement dans le dépôt. Dans cet article, nous allons voir comment configurer un CI/CD complet pour les projets C# avec GitHub Actions : du simple build au déploiement automatique. Vous apprendrez à écrire des configurations YAML, à optimiser les tests et à éviter les erreurs courantes.

Les bases de GitHub Actions pour .NET

Qu'est-ce qu'un workflow et un job ?

Un workflow (processus de travail) est un processus automatisé qui se déclenche sur un événement spécifique (push, pull request, création de release). Il est décrit dans un fichier .github/workflows/*.yml. Un workflow se compose d'un ou plusieurs jobs (tâches) qui s'exécutent sur des runners (machines virtuelles). Chaque job peut contenir une séquence de steps (étapes).

Pour les projets C#, les étapes clés sont la restauration des dépendances (dotnet restore), le build (dotnet build), l'exécution des tests (dotnet test) et la publication (dotnet publish).

Modèle de workflow de base pour .NET

Voici un workflow minimal pour le build et le test d'un projet C#. Enregistrez ce code dans le fichier .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

Analyse des lignes clés :

\n
• actions/checkout@v4 — clone le dépôt dans l'environnement d'exécution.
\n
• actions/setup-dotnet@v4 — installe la version spécifiée du SDK .NET.
\n
• dotnet restore — télécharge les packages NuGet.
\n
• dotnet build --configuration Release — compile le projet en mode Release.
\n
• dotnet test — exécute tous les tests de la solution.
\n

Configuration avancée : mise en cache et matrice de build

Mise en cache des packages NuGet

Chaque exécution de workflow démarre dans un environnement propre. Pour accélérer le processus, vous pouvez mettre en cache le dossier ~/.nuget/packages. Cela est particulièrement utile pour les grands projets avec des dizaines de dépendances.

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 clé de cache est basée sur le hachage des fichiers projet (.csproj). Si les dépendances n'ont pas changé, le cache sera restauré en quelques secondes.

Matrice de build (Matrix Strategy)

Si votre application doit fonctionner sous différentes versions de .NET ou systèmes d'exploitation, utilisez une matrice. GitHub Actions créera automatiquement un job séparé pour chaque combinaison.

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