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

Introduction : Pourquoi le CI/CD est la norme du développement .NET moderne

Le développement moderne en C# et sur la plateforme .NET est impensable sans automatisation. Le lancement manuel des compilations, des tests et des déploiements est une voie vers les erreurs, la perte de temps et les retards de publication. CI/CD (Intégration Continue / Déploiement Continu) résout ces problèmes, rendant le processus de livraison du code prévisible et rapide.

GitHub Actions est un outil d'automatisation intégré à GitHub, parfaitement adapté aux projets C#. Il permet de configurer un pipeline directement dans le dépôt en utilisant des fichiers YAML. Dans cet article, nous allons détailler le cycle complet : de la compilation de base à la publication d'un package NuGet et au déploiement d'une application web.

1. Bases de GitHub Actions pour .NET

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

Un workflow est un processus automatisé qui se déclenche sur un événement (push, pull request, planification). Un workflow est composé d'un ou plusieurs jobs (tâches) qui s'exécutent sur des runners (machine virtuelle avec Ubuntu, Windows ou macOS).

Chaque job est composé d'étapes (steps) qui peuvent exécuter des commandes shell ou utiliser des actions prêtes à l'emploi depuis le marketplace.

Premier workflow : compilation d'un projet .NET

Créez à la racine du dépôt un dossier .github/workflows et un fichier build.yml :

name: Build .NET Project

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

jobs:  build:    runs-on: ubuntu-latest

    steps:    - uses: actions/checkout@v4        - name: Setup .NET      uses: actions/setup-dotnet@v4      with:        dotnet-version: '8.0.x'        - name: Restore dependencies      run: dotnet restore        - name: Build      run: dotnet build --no-restore --configuration Release        - name: Run tests      run: dotnet test --no-build --configuration Release --verbosity normal

Ce workflow se déclenche à chaque push ou pull request sur main. Il restaure les dépendances, compile le projet en mode Release et exécute les tests. Si une étape échoue, le workflow s'arrête et vous verrez un statut rouge dans la PR.

2. Configuration avancée : matrice de compilation et mise en cache

Matrice des versions .NET

Pour vérifier la compatibilité avec différentes versions de .NET, utilisez une matrice (matrix) :

jobs:  build:    strategy:      matrix:        dotnet-version: ['6.0.x', '7.0.x', '8.0.x']        os: [ubuntu-latest, windows-latest]    runs-on: ${{ matrix.os }}

    steps:    - uses: actions/checkout@v4    - name: Setup .NET ${{ matrix.dotnet-version }}      uses: actions/setup-dotnet@v4      with:        dotnet-version: ${{ matrix.dotnet-version }}    - run: dotnet build --configuration Release    - run: dotnet test

Le runner exécutera la compilation pour chaque combinaison de système d'exploitation et de version .NET en parallèle. Cela fait gagner du temps et garantit la compatibilité multiplateforme.

Mise en cache des dépendances

La restauration des packages NuGet à chaque fois prend du temps. Activez la mise en cache :

- name: Cache NuGet packages  uses: actions/cache@v4  with:    path: ~/.nuget/packages    key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }}    restore-keys: |      ${{ runner.os }}-nuget-

- name: Restore dependencies  run: dotnet restore

Désormais, lors d'une exécution ultérieure, les packages seront restaurés à partir du cache si les fichiers .csproj n'ont pas changé.

3. Publication d'un package NuGet dans GitHub Packages

Si vous développez une bibliothèque en C#, vous pouvez la publier automatiquement dans GitHub Packages lors de la création d'une release.

Workflow de publication

name: Publish NuGet Package

on:  release:    types: [published]

jobs:  publish:    runs-on: ubuntu-latest        steps:    - uses: actions/checkout@v4        - name: Setup .NET      uses: actions/setup-dotnet@v4