GitHub Actions — Eine moderne CI/CD-Pipeline

GitHub Actions kam Ende 2019 aus der Beta, und 2020 werden sie eine echte Alternative zu Jenkins, GitLab CI und Azure DevOps. Wir haben sie in drei Projekten ausprobiert — hier sind unsere Erfahrungen.

Warum GitHub Actions in 2020¶

Jenkins ist mächtig, aber seine Wartung ist ein Vollzeitjob. Plugin-Hölle, Groovy-Skripte, die niemand debuggen will, und eine UI aus dem Jahr 2005. GitLab CI ist elegant, erfordert aber GitLab. Wenn Ihr Code auf GitHub lebt — und 2020 tut das der Code der meisten Teams — macht Actions perfekt Sinn.

Hauptvorteile:

• Native Integration: CI/CD lebt direkt im Repository, nicht auf einem separaten Server
• YAML-Konfiguration: Versioniert, reviewbar, mergebar — wie Code
• Marketplace: Tausende fertige Actions aus der Community — von Caching bis Deployment
• Matrix Builds: Auf mehreren OS/Versionen parallel testen ohne komplexe Konfiguration
• Free Tier: 2.000 Minuten/Monat für öffentliche Repos, 2.000 für private (Team-Plan)

Anatomie einer Workflow-Datei¶

Alles beginnt mit einer Datei in .github/workflows/. Grundstruktur für eine .NET Core-Anwendung:

name: CI Pipeline

on:

push:

branches: [ main, develop ]

pull_request:

branches: [ main ]

jobs:

build-and-test:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v2

- uses: actions/setup-dotnet@v1

  with:

    dotnet-version: '3.1.x'

- run: dotnet restore

- run: dotnet build --no-restore

- run: dotnet test --no-build

Klar, lesbar, versioniert. Kein Klick-Wizard, kein „wer hat diesen Jenkins-Job geändert?” Ein Pull Request auf die Workflow-Datei durchläuft dasselbe Review wie Anwendungscode.

Secrets Management¶

GitHub Secrets sind auf Repository- oder Organisationsebene verschlüsselt. In Workflows greift man über ${{ secrets.NAME }} darauf zu. Für Deployment-Credentials (Azure Service Principal, AWS Keys, Docker Registry) ist das eine saubere Lösung ohne externe Vault-Systeme.

Für komplexere Szenarien — Key-Rotation, dynamische Secrets — kombinieren wir GitHub Secrets mit Azure Key Vault. Die azure/login@v1 Action authentifiziert sich über Service Principal und holt aktuelle Secrets aus Key Vault. Zwei Sicherheitsebenen, automatische Rotation.

Eine reale Deployment-Pipeline¶

In einem Projekt für ein Logistikunternehmen deployten wir eine komplette Pipeline:

1. PR-Check: Build + Unit-Tests + Linting (ESLint, Prettier) — blockiert Merge bei Fehler
2. Build Artifact: Docker Image, Push zu Azure Container Registry
3. Deploy to Staging: automatisch nach Merge in develop — Azure Web App for Containers
4. Integrationstests: Postman/Newman-Collection läuft gegen die Staging-Umgebung
5. Deploy to Production: Manuelle Freigabe über GitHub Environments, dann Rolling Update

Die gesamte Pipeline von Push bis Production: ~12 Minuten. Mit Jenkins waren es 25+ Minuten und ein dedizierter Build-Server war nötig.

Matrix-Strategie für Cross-Platform¶

Eine Bibliothek, die wir Kunden für die Integration mit ihren Systemen liefern, muss auf .NET Core 3.1 und .NET Framework 4.8 laufen, auf Windows und Linux. Matrix Build löst das elegant:

strategy:

matrix:

os: [ubuntu-latest, windows-latest]

dotnet: ['3.1.x', '5.0.x']

fail-fast: false

Vier Kombinationen laufen parallel. Ergebnis in 4 Minuten statt 16 sequenziell. Und fail-fast: false bedeutet, dass auch wenn eine Kombination fehlschlägt, die anderen abschließen — man weiß genau, wo das Problem liegt.

Self-Hosted Runners — Wann und warum¶

GitHub-gehostete Runner sind bequem, haben aber Limits: 7 GB RAM, 14 GB Disk, kein Zugang zu internen Netzwerken. Für den Build großer .NET Solutions (50+ Projekte) oder Deployment in On-Premise-Umgebungen braucht man einen Self-Hosted Runner.

Wir deployten einen Runner als Docker-Container auf Azure Container Instance — ephemeral, skalierbar, mit Zugang zum VNet des Kunden über VNet-Integration. Der Runner startet, führt den Job aus und wird beendet. Sauberer Zustand für jeden Build, kein State Drift.

Vergleich mit Jenkins und GitLab CI¶

• Jenkins: Maximale Flexibilität, aber meiste Wartung. Geeignet für Enterprises mit dediziertem DevOps-Team und Legacy-Integrationen
• GitLab CI: Hervorragend wenn Sie GitLab nutzen. Engere Integration, integrierte Registry, Security Scanning. Aber Vendor Lock-in
• GitHub Actions: Beste Developer Experience, schneller Start, großartig für Teams auf GitHub. Weniger ausgereift für komplexe Enterprise-Szenarien (2020)

Actions als Standardwahl für neue Projekte¶

Für neue Projekte im Jahr 2020 empfehlen wir GitHub Actions als Standard-CI/CD-Plattform. Niedrigere Betriebskosten, bessere Developer Experience und ausreichende Flexibilität für die meisten Szenarien. Jenkins lassen wir dort, wo es bereits läuft und funktioniert — Migration muss sich lohnen.