CI/CD für C#-Projekte mit GitHub Actions: Vollständige Anleitung

Einleitung: Warum CI/CD für C#-Entwickler wichtig ist

In der modernen Softwareentwicklung sind manuelles Testen und Deployment ineffizient und riskant. Jedes Mal, wenn ein Entwickler Code in ein Repository pusht, muss sichergestellt werden, dass der Build nicht kaputt geht, die Tests bestanden werden und die Anwendung bereit für die Bereitstellung ist. Genau hier kommt CI/CD (Continuous Integration / Continuous Deployment) ins Spiel.

GitHub Actions ist ein integriertes Automatisierungstool in GitHub, mit dem Sie Workflows direkt in Ihrem Repository erstellen können. Es ist ideal für C# (.NET)-Projekte, da es sowohl Windows- als auch Linux-Runner unterstützt und eine umfangreiche Ökosphäre an vorgefertigten Aktionen (actions) bietet.

In diesem Artikel werden wir durchgehen, wie man eine vollwertige CI/CD-Pipeline für ein C#-Projekt mit GitHub Actions einrichtet: vom Build und Testen bis zur Veröffentlichung eines NuGet-Pakets oder dem Deployment einer Webanwendung.

Grundlagen von GitHub Actions: YAML und Struktur eines Workflows

Jeder Workflow in GitHub Actions wird in einer YAML-Datei beschrieben, die im Verzeichnis .github/workflows/ Ihres Repositorys gespeichert ist. Betrachten wir die grundlegende Struktur:

name: .NET CI/CD

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

jobs:  build:    runs-on: ubuntu-latest

    steps:    - name: Checkout code      uses: actions/checkout@v4

    - name: Setup .NET      uses: actions/setup-dotnet@v4      with:        dotnet-version: '8.x'

    - name: Restore dependencies      run: dotnet restore

    - name: Build      run: dotnet build --configuration Release --no-restore

    - name: Run tests      run: dotnet test --configuration Release --no-build --verbosity normal

Schlüsselelemente:

• on — Auslöser für den Start (push, pull_request, schedule usw.)
• jobs — Eine Reihe von Aufgaben, die parallel oder sequentiell ausgeführt werden
• runs-on — Das Betriebssystem für die Ausführung (ubuntu-latest, windows-latest, macos-latest)
• steps — Eine Abfolge von Befehlen oder vorgefertigten Aktionen

Wichtig: Für .NET-Projekte verwenden Sie die Aktion actions/setup-dotnet mit Angabe der SDK-Version. Dies stellt sicher, dass die Umgebung die benötigte .NET-Version enthält.

Einrichtung von Tests und Linting für C#-Code

Ein qualitativ hochwertiges CI/CD kommt nicht ohne automatisierte Tests und Code-Stil-Prüfungen aus. Fügen wir unserem Workflow Phasen für Unit-Tests und statische Analyse hinzu.

Unit-Tests mit xUnit und Codeabdeckung

Angenommen, Sie haben ein Projekt mit Tests auf xUnit. Fügen wir einen Schritt zur Generierung eines Abdeckungsberichts mit Coverlet hinzu:

- name: Run tests with coverage  run: |    dotnet test --configuration Release \      --no-build \      --verbosity normal \      /p:CollectCoverage=true \      /p:CoverletOutputFormat=opencover \      /p:CoverletOutput=./coverage.xml

- name: Upload coverage to Codecov  uses: codecov/codecov-action@v3  with:    files: ./coverage.xml    flags: unittests    fail_ci_if_error: false

Dafür muss dem Testprojekt das Paket coverlet.collector hinzugefügt werden. Beispielbefehl:

dotnet add package coverlet.collector

Statische Analyse mit Roslyn Analyzers

Fügen wir eine Code-Überprüfung mit den integrierten .NET-Analysatoren hinzu:

- name: Run Roslyn analyzers  run: dotnet build --configuration Release --warnaserror -p:RunAnalyzersDuringBuild=true

Es können auch externe Tools wie SonarCloud verwendet werden:

- name: SonarCloud Scan  uses: SonarSource/sonarcloud-github-action@master  env:    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}    SONAR_TOKEN: ${{ secrets.SON