CI/CD für C#-Projekte: GitHub Actions von A bis Z

Einleitung: Warum CI/CD für C#-Projekte?

Die Entwicklung moderner Anwendungen in C# und der .NET-Plattform erfordert nicht nur qualitativ hochwertigen Code, sondern auch einen zuverlässigen Prozess zur Auslieferung an den Benutzer. Manuelle Builds, Tests und Bereitstellungen sind nicht nur langsam, sondern auch fehleranfällig. Hier kommt CI/CD (Continuous Integration / Continuous Deployment) ins Spiel – eine Praxis, die alle Phasen des Software-Lebenszyklus automatisiert.

GitHub Actions ist ein integriertes Tool von GitHub, mit dem Sie leistungsstarke Pipelines direkt im Repository erstellen können. In diesem Artikel werden wir uns ansehen, wie Sie ein vollwertiges CI/CD für C#-Projekte mit GitHub Actions einrichten: vom einfachen Build bis zum automatischen Deployment. Sie erfahren, wie Sie YAML-Konfigurationen schreiben, Tests optimieren und typische Fehler vermeiden.

Grundlagen von GitHub Actions für .NET

Was sind Workflow und Job?

Ein Workflow (Arbeitsablauf) ist ein automatisierter Prozess, der durch ein bestimmtes Ereignis (Push, Pull Request, Release-Erstellung) ausgelöst wird. Er wird in einer Datei .github/workflows/*.yml beschrieben. Ein Workflow besteht aus einem oder mehreren Jobs (Aufgaben), die auf Runnern (virtuellen Maschinen) ausgeführt werden. Jeder Job kann eine Abfolge von Steps (Schritten) enthalten.

Für C#-Projekte sind die wichtigsten Schritte das Wiederherstellen von Abhängigkeiten (dotnet restore), der Build (dotnet build), das Ausführen von Tests (dotnet test) und die Veröffentlichung (dotnet publish).

Basis-Workflow-Vorlage für .NET

Nachfolgend sehen Sie einen minimalen Workflow zum Erstellen und Testen eines C#-Projekts. Speichern Sie diesen Code in der Datei .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

Erläuterung der wichtigsten Zeilen:

\n
• actions/checkout@v4 – klont das Repository in die Ausführungsumgebung.
\n
• actions/setup-dotnet@v4 – installiert die angegebene Version des .NET SDK.
\n
• dotnet restore – lädt NuGet-Pakete herunter.
\n
• dotnet build --configuration Release – erstellt das Projekt im Release-Modus.
\n
• dotnet test – führt alle Tests aus der Projektmappe aus.
\n

Erweiterte Konfiguration: Caching und Build-Matrix

Caching von NuGet-Paketen

Jeder Workflow-Lauf beginnt in einer sauberen Umgebung. Um den Prozess zu beschleunigen, kann der Ordner ~/.nuget/packages zwischengespeichert werden. Dies ist besonders bei großen Projekten mit Dutzenden von Abhängigkeiten nützlich.

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

Der Cache-Schlüssel basiert auf dem Hash der Projektdateien (.csproj). Wenn sich die Abhängigkeiten nicht geändert haben, wird der Cache in Sekundenschnelle wiederhergestellt.

Build-Matrix (Matrix Strategy)

Wenn Ihre Anwendung unter verschiedenen .NET-Versionen oder Betriebssystemen laufen soll, verwenden Sie eine Matrix. GitHub Actions erstellt automatisch einen separaten Job für jede Kombination.

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