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

Einleitung: Warum CI/CD der Standard moderner .NET-Entwicklung ist

Moderne Entwicklung mit C# und der .NET-Plattform ist ohne Automatisierung undenkbar. Manuelles Starten von Builds, Tests und Deployments führt zu Fehlern, Zeitverlust und Verzögerungen bei Releases. CI/CD (Continuous Integration / Continuous Deployment) löst diese Probleme, indem es den Codebereitstellungsprozess vorhersagbar und schnell macht.

GitHub Actions ist ein integriertes Automatisierungstool auf GitHub, das sich ideal für C#-Projekte eignet. Es ermöglicht die Einrichtung einer Pipeline direkt im Repository mithilfe von YAML-Dateien. In diesem Artikel behandeln wir den gesamten Zyklus: vom grundlegenden Build bis zur Veröffentlichung eines NuGet-Pakets und dem Deployment einer Webanwendung.

1. Grundlagen von GitHub Actions für .NET

Was sind Workflow und Job?

Ein Workflow ist ein automatisierter Prozess, der durch ein Ereignis (Push, Pull Request, Zeitplan) ausgelöst wird. Ein Workflow besteht aus einem oder mehreren Jobs (Aufgaben), die auf Runnern (virtuelle Maschinen mit Ubuntu, Windows oder macOS) ausgeführt werden.

Jeder Job besteht aus Schritten (Steps), die Shell-Befehle ausführen oder vorgefertigte Actions aus dem Marketplace verwenden können.

Erster Workflow: .NET-Projekt bauen

Erstellen Sie im Repository-Stammverzeichnis den Ordner .github/workflows und die Datei 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

Dieser Workflow wird bei jedem Push oder Pull Request in main ausgelöst. Er stellt Abhängigkeiten wieder her, baut das Projekt im Release-Modus und führt Tests durch. Wenn ein Schritt fehlschlägt, wird der Workflow gestoppt und Sie sehen einen roten Status im PR.

2. Erweiterte Konfiguration: Build-Matrix und Caching

.NET-Versionsmatrix

Um die Kompatibilität mit verschiedenen .NET-Versionen zu überprüfen, verwenden Sie eine 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

Der Runner führt den Build für jede Kombination aus Betriebssystem und .NET-Version parallel aus. Das spart Zeit und gewährleistet plattformübergreifende Kompatibilität.

Abhängigkeiten zwischenspeichern

Das Wiederherstellen von NuGet-Paketen dauert jedes Mal Zeit. Aktivieren Sie Caching:

- 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

Bei erneuter Ausführung werden die Pakete nun aus dem Cache wiederhergestellt, sofern sich die .csproj-Dateien nicht geändert haben.

3. NuGet-Paket in GitHub Packages veröffentlichen

Wenn Sie eine Bibliothek in C# entwickeln, können Sie diese bei der Erstellung eines Releases automatisch in GitHub Packages veröffentlichen.

Workflow für die Veröffentlichung

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