Pipeline CI/CD C# : configuration de zéro pour développeurs pressés

CI/CD pour C# : arrêtez de déployer manuellement et passez à l'automatisation

Si vous compilez encore votre projet C# en local, transférez vos builds par FTP et croisez les doigts pour que tout fonctionne — j'ai une bonne nouvelle pour vous. En 2025, cette méthode est tout simplement dépassée, même pour un petit projet personnel.

Le CI/CD n'est pas une magie réservée aux seniors à 300k, mais simplement un ensemble de scripts qui gèrent les tâches répétitives à votre place. Aujourd'hui, nous allons configurer un pipeline CI/CD complet pour C# à partir de zéro. Sans blabla, avec des exemples concrets et une analyse des erreurs courantes.

D'ailleurs, si vous codez en Python, nous avons aussi des guides d'automatisation sur pythonlib.ru. Mais aujourd'hui, on travaille avec C#.

Qu'est-ce que le CI/CD et pourquoi en avez-vous besoin en tant que développeur C#

CI (Continuous Integration) : chaque commit dans votre Git est automatiquement compilé et testé. Fini les « ça marche chez moi ».

CD (Continuous Delivery/Deployment) : après une compilation réussie, le code est automatiquement déployé sur le serveur (ou dans le cloud).

Pour C#, c'est particulièrement crucial : la compilation avec dotnet build peut varier d'une machine à l'autre, et les tests sont souvent oubliés. Le CI/CD résout ces deux problèmes.

Choisir son outil : GitHub Actions vs GitLab CI vs Jenkins

Pour commencer, je recommande GitHub Actions. Pourquoi ?

\n
• Gratuit pour les dépôts publics (même pour C#)
\n
• Pas besoin d'installer un serveur
\n
• Actions prêtes à l'emploi pour .NET
\n
• YAML — facile à lire
\n

Si vous utilisez GitLab, le principe est le même, la syntaxe est similaire. Jenkins, on le laisse pour l'enfer corporate.

Écrire son premier pipeline pour un projet C#

Créez à la racine du dépôt le fichier .github/workflows/dotnet.yml. Oui, le fichier doit être exactement dans ce dossier.

Voici un pipeline minimal qui compile le projet et exécute les tests :

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    - 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 étape par étape :

\n
• on: push — le pipeline se lance lors d'un push sur main ou develop
\n
• runs-on: ubuntu-latest — on compile sous Linux (C# avec .NET Core/8+ fonctionne partout)
\n
• setup-dotnet — installe la version requise du SDK .NET
\n
• dotnet restore — restaure les packages NuGet
\n
• dotnet build — compile la version Release
\n
• dotnet test — exécute tous les tests du projet
\n

Après le push, allez dans l'onglet Actions de votre dépôt — vous verrez le pipeline s'exécuter. Si les tests échouent, vous obtiendrez un statut rouge et un email de notification.

Ajouter la couverture de code (parce que des tests sans couverture, c'est du vent)

Un pipeline digne de ce nom doit montrer le pourcentage de code couvert par les tests. Pour C#, on utilise coverlet avec ReportGenerator.

Commencez par ajouter les packages NuGet à votre projet de test :

dotnet add YourTestProject.csproj package coverlet.collector\ndotnet add YourTestProject.csproj package coverlet.msbuild

Mettez ensuite à jour l'étape de test dans le pipeline :

    - name: Run tests with coverage\n      run: |\n        dotnet test --no-build --configuration Release \\\n          /p:CollectCoverage=true \\\n          /p:CoverletOutputFormat=opencover \\\n          /p:CoverletOutput=./TestResults/coverage.xml\n\n    - name: Install ReportGenerator\n      run: dotnet t