Introduction : Pourquoi le CI/CD est essentiel pour les projets C# (.NET)
Le développement logiciel moderne est impossible sans automatisation. Les processus manuels de compilation, de test et de déploiement sont non seulement lents, mais aussi sujets aux erreurs. Pour les développeurs C# travaillant avec l'écosystème .NET, la mise en œuvre des pratiques CI/CD (Intégration Continue / Déploiement Continu) est devenue une norme industrielle.
GitHub Actions est un outil puissant et flexible pour automatiser les workflows, intégré directement dans GitHub. Il vous permet de créer des pipelines (workflows) qui répondent aux événements de votre dépôt : pushes, création de Pull Requests, releases, et bien plus encore. Dans cet article, nous allons voir comment configurer un pipeline CI/CD complet pour un projet C# basé sur .NET en utilisant GitHub Actions.
Vous apprendrez à :
- Configurer des compilations automatiques de projets.
- Exécuter des tests unitaires (par exemple, xUnit ou NUnit).
- Publier des artefacts de compilation.
- Déployer automatiquement l'application (par exemple, sur Azure, Docker Hub ou un serveur).
1. Bases de GitHub Actions : Workflow, Jobs et Steps
Avant d'écrire du code, comprenons les concepts de base de GitHub Actions.
- Workflow : Il s'agit d'un processus automatisé que vous définissez dans un fichier YAML à l'intérieur du dossier
.github/workflows. Un workflow est déclenché par un événement (par exemple, un push vers la branche principale). - Job : Un ensemble d'étapes qui s'exécutent sur un seul runner (machine virtuelle). Les jobs peuvent s'exécuter séquentiellement ou en parallèle.
- Step : Une commande ou action individuelle. Il peut s'agir d'exécuter un script, d'installer des dépendances ou d'utiliser une action préconstruite depuis la marketplace.
- Runner : Le serveur qui exécute votre workflow. GitHub fournit des runners gratuits (Ubuntu, Windows, macOS), ou vous pouvez héberger les vôtres.
Pour les projets .NET, nous utiliserons des actions prêtes à l'emploi telles que actions/checkout (pour cloner le dépôt) et actions/setup-dotnet (pour installer le SDK .NET).
2. Configuration d'un pipeline CI de base : Compilation et Test
Créons notre premier workflow. Pour ce faire, créez un dossier nommé .github/workflows à la racine de votre dépôt, et à l'intérieur, créez un fichier nommé dotnet-build.yml.
Voici un fichier YAML minimal pour compiler et tester un projet C# :
name: .NET Build and Test
on: push: branches: [ main, develop ] pull_request: branches: [ main ]
jobs: build-and-test: runs-on: ubuntu-latest
steps: - name: Checkout repository uses: actions/checkout@v4
- name: Setup .NET uses: actions/setup-dotnet@v4 with: dotnet-version: '8.0.x' # Specify your .NET version
- 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 normalAnalyse du code :
- name : Le nom du workflow, qui sera affiché dans GitHub.
- on : Définit les déclencheurs. Dans notre cas, il s'agit des pushes et des pull requests vers les branches main et develop.
- jobs : Contient un seul job appelé
build-and-test, qui s'exécute surubuntu-latest. - steps : Une séquence d'actions : cloner le code, installer .NET 8.0, restaurer les packages NuGet, compiler en configuration Release, et exécuter les tests.
Après avoir poussé ce fichier dans le dépôt, GitHub Actions exécutera automatiquement le workflow. Vous verrez une coche verte ou une croix rouge à côté de