GitHub Actions Tutorial: CI/CD-Workflows einfach erklärt (2026)

Wenn dein Pull Request automatisch testet, baut und deployed, dann steckt heute meistens GitHub Actions dahinter. Die Plattform hat sich in fünf Jahren vom Jenkins-Herausforderer zur Default-Wahl in der DACH-Region entwickelt. 2026 sind 80 Prozent aller Open-Source-CI-Pipelines auf Actions umgezogen.

Der Trick: Actions lebt direkt im Repository. Du schreibst YAML in .github/workflows/ und committest es zusammen mit dem Code. Kein externes Tool, kein Webhook-Wirrwarr. Trigger, Jobs, Runner, Artifacts - alles versionsverfolgt im selben Branch wie dein Test-Code.

In diesem Tutorial baue ich mit dir eine erste CI/CD-Pipeline in unter 10 Minuten. Du erfährst, wie Trigger funktionieren, was Runner kosten, wie du Secrets schützt und wie du Playwright-, Cypress- und k6-Workflows ans Repo hängst.

Was ist GitHub Actions?

GitHub Actions ist die CI/CD-Plattform von GitHub. Du definierst Workflows als YAML-Dateien im Ordner .github/workflows/. Ein Workflow reagiert auf Events (Push, Pull Request, Schedule, Manuel-Trigger), führt Jobs aus und kann Artifacts wie Logs, Reports oder Build-Outputs speichern.

Verglichen mit Jenkins ist die Einstiegshürde dramatisch niedriger. Kein Server-Setup, kein Plugin-Hell, keine Master-Agent-Konfiguration. Du committest die YAML, GitHub kümmert sich um den Rest. Wer schon mal eine Jenkinsfile geschrieben hat, fühlt sich in Actions sofort zu Hause - nur ohne den Konfigurations-Overhead.

Für CI/CD-Konzepte und Pipeline-Patterns lies unseren Jenkins-Praxis-Guide. Die Konzepte aus DORA-Metriken und Deployment-Frequenz gelten plattformübergreifend.

Erste Workflow-Datei in 5 Minuten

Lege im Repo den Ordner .github/workflows/ an und darin ci.yml:

name: CI

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Code auschecken
        uses: actions/checkout@v4

      - name: Node.js einrichten
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Dependencies installieren
        run: npm ci

      - name: Tests ausführen
        run: npm test

      - name: Build erstellen
        run: npm run build

Commit, Push, fertig. Beim nächsten Pull Request siehst du unter dem Tab "Actions" den grünen Haken oder das rote Kreuz. Genau so einfach baut man heute eine CI ein.

Trigger-Events: push, pull_request, schedule, workflow_dispatch

Workflows starten auf vielfältige Events. Die wichtigsten:

• push: Bei jedem Push in einen Branch (filterbar mit branches: oder paths:)
• pull_request: Beim Öffnen, Updaten oder Mergen eines PR
• schedule: Per Cron-Ausdruck (z.B. '0 6 * * *' für täglich 6 Uhr UTC)
• workflow_dispatch: Manueller Trigger über die UI mit Input-Parametern
• repository_dispatch: Externer Trigger via REST-API (für Cross-Repo-Workflows)
• workflow_run: Reaktion auf den Abschluss eines anderen Workflows

Mit Path-Filtern triggerst du gezielt: paths: ['src/**', 'tests/**'] ignoriert reine README-Änderungen. Das spart Actions-Minuten und beschleunigt das Feedback.

Jobs, Steps und Runners

Jeder Workflow besteht aus einem oder mehreren Jobs. Jobs laufen parallel (außer du setzt needs:). Jeder Job läuft auf einem Runner und besteht aus Steps. Steps sind die einzelnen Befehle.

Job-Dependencies mit needs: erlauben Sequencing: deploy: needs: [test, build] wartet, bis Test und Build grün sind. Mit if: definierst du Conditions: if: github.event_name == 'push' lässt einen Job nur bei Push laufen.

Der Actions Marketplace

Der Marketplace umfasst 2026 über 30.000 Actions. Statt eigene Scripts zu schreiben, nutzt du fertige Bausteine. Die wichtigsten Maintainer:

• actions/* - Offizielle GitHub-Actions (checkout, setup-node, cache, upload-artifact)
• docker/* - Docker-Build, Buildx, Login (z.B. docker/build-push-action@v6)
• aws-actions/* - AWS-Authentifizierung und Deployment
• microsoft/setup-msbuild - .NET-Builds auf Windows-Runner
• peaceiris/actions-gh-pages - Static-Site-Deployment

Custom Actions schreibst du in JavaScript, Docker oder als Composite-Action. Beispiel-Workflow mit Docker-Build:

- name: Docker Build & Push
  uses: docker/build-push-action@v6
  with:
    context: .
    push: true
    tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
    cache-from: type=gha
    cache-to: type=gha,mode=max

Wichtig: Actions immer mit Versions-Tag oder Commit-SHA pinnen. Niemals @main nutzen - Supply-Chain-Risiko.

Secrets, Variablen und Environment-Schutz

API-Keys, Deploy-Token und Service-Account-JSONs gehören nicht ins Repo. GitHub bietet drei Ebenen:

• Repository Secrets: Pro Repo, für alle Workflows verfügbar
• Environment Secrets: Pro Deploy-Environment (staging, prod), mit Required-Reviewers für sensible Deployments
• Organization Secrets: Cross-Repo (z.B. zentraler Docker-Registry-Token)

Im Workflow nutzt du sie als ${{ secrets.NAME }}. GitHub maskiert Secret-Werte in Logs automatisch. Beispiel mit Environment-Protection:

jobs:
  deploy-prod:
    needs: test
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://app.example.com
    steps:
      - run: ./deploy.sh
        env:
          AWS_KEY: ${{ secrets.AWS_PROD_KEY }}

Der Job pausiert, bis ein Required-Reviewer die Deployment approved. Genau dieses Pattern nutze ich, um menschliche Quality-Gates vor kritische Prod-Deploys zu schalten.

Self-hosted vs. GitHub-hosted Runner (2026-Preise)

2026 wurde es interessanter. Drei Updates verändern die Wirtschaftlichkeit:

• Preisreduktion: Seit 1. Januar 2026 sind GitHub-hosted Runner um bis zu 39 Prozent günstiger. Linux-Standard kostet jetzt 0,005 USD/Min, Windows 0,01 USD/Min, macOS 0,06 USD/Min.
• Custom Runner Images (GA April 2026): Eigene Base-Images mit vorinstallierten Tools hinterlegen. Spart pro Job-Start 30 bis 90 Sekunden Setup-Zeit.
• Runner Scale Set Client (Public Preview Feb 2026): Plattform-agnostisches Auto-Scaling für Self-hosted Runner via Kubernetes-Operator.

Faustregel: Starte mit GitHub-hosted. Wechsel zu Self-hosted erst, wenn du klare Trigger hast (GPU-Tests, EU-Data-Residency, Repos mit Hunderten Workflows pro Tag).

Praxis: Playwright, Cypress und k6 im Workflow

Für Test Automation Engineers sind drei Workflow-Patterns Pflicht. Hier eine kompakte Playwright-Pipeline:

- name: Playwright installieren
  run: npx playwright install --with-deps chromium

- name: Tests ausführen
  run: npx playwright test --reporter=html,junit

- name: Trace + Report hochladen
  if: always()
  uses: actions/upload-artifact@v4
  with:
    name: playwright-report
    path: |
      playwright-report/
      test-results/
    retention-days: 14

Der if: always()-Trick lädt Artifacts auch bei rotem Test hoch - genau dann brauchst du den Trace. Für Cypress, k6 und Selenium-Grid gelten ähnliche Patterns. Vertiefung im k6-BDD-Artikel und in unserer Locust-Tutorial-Reihe. Für KI-gestützte Tests siehe KI im Software Testing.

Best Practices und Cost Control

Aus zwei Jahren Actions-Praxis in Kundenprojekten:

• Concurrency-Group setzen: concurrency: group: ci-${{ github.ref }}, cancel-in-progress: true killt redundante Runs beim Force-Push
• Caching aggressiv nutzen: actions/cache@v4 für node_modules, ~/.gradle, ~/.m2 spart oft 2-3 Minuten pro Job
• Matrix nur wenn nötig: Eine 3x3-Matrix (3 OS x 3 Node-Versionen) braucht 9 Job-Slots, kostet 9x
• Path-Filter setzen: Doku-Änderungen sollten die Test-Suite nicht triggern
• Reusable Workflows: Cross-Repo-Duplikate via uses: org/.github/.github/workflows/ci.yml@main eliminieren

Linting als Pipeline-Stage gehört zum Best-Practice-Stack: Linting & Quality-Gate: Code-Qualität in der CI/CD-Pipeline.

Stolperfallen

Vier Fallen, die ich regelmäßig in Reviews sehe:

• Secrets in echo: echo $SECRET in Logs ist Daten-Leak, auch wenn Maskierung greift. Lösung: niemals printen
• Default-Token-Permissions: GITHUB_TOKEN hat 2026 standardmäßig Read-only-Rechte. Für Schreib-Operationen explizit permissions: setzen
• Long-running Jobs: Standard-Timeout ist 6 Stunden. Wenn dein Job hängt, brennen alle Minuten. Setze timeout-minutes: 30
• Self-hosted Runner ohne Cleanup: Workspace-Reste sammeln sich an, irgendwann ist die Disk voll. Cleanup-Step am Job-Ende oder ephemerale Runner

Fazit

GitHub Actions hat die Einstiegshürde für CI/CD massiv gesenkt. In 10 Minuten steht eine Pipeline, die bei jedem Pull Request testet, baut und (mit Environment-Schutz) auch deployed. Die 2026-Updates - Preisreduktion, Custom Images, Runner Scale Set - machen die Plattform auch für größere Setups attraktiv.

Tests sind kein Add-on. Tests sind der Vertrag, den Code und CI miteinander schließen. Wenn dein Pull Request rot ist, hat das System gemacht, was es soll. Brauchst du Unterstützung beim Aufbau einer robusten Actions-Pipeline? Unser Continuous-Testing-Service kombiniert Pipeline-Setup, Test-Automation und Reporting.

FAQ: Häufige Fragen zu GitHub Actions

Was kostet GitHub Actions?

Public Repos: kostenlos. Private Repos: 2.000 Minuten/Monat im Free-Plan, danach 0,005 USD/Min für Linux-Standard-Runner (Stand 2026 nach Preisreduktion). Self-hosted Runner sind unbegrenzt kostenlos.

Wie debugge ich einen fehlgeschlagenen Workflow?

In der Workflow-Run-Ansicht expandierst du den fehlgeschlagenen Step. Mit ACTIONS_RUNNER_DEBUG: true als Secret oder Variable bekommst du Debug-Logs. Für Live-Debugging gibt es die Action mxschmitt/action-tmate, die einen SSH-Zugang in den Runner öffnet.

Kann ich GitHub Actions mit GitLab oder Bitbucket nutzen?

Nein, Actions läuft nur auf Repositories, die in GitHub gehostet sind. GitLab hat sein eigenes CI/CD (GitLab CI), Bitbucket nutzt Pipelines. Cross-Plattform-Tools sind Jenkins oder Drone.

Wie führe ich GitHub Actions lokal aus?

Mit dem Tool nektos/act. Es simuliert Runner mit Docker-Containern. Nicht 100% identisch zur Cloud-Umgebung, aber für 90 Prozent der Debug-Zwecke ausreichend.

Sind GitHub Actions DSGVO-konform?

GitHub-hosted Runner laufen in US-Rechenzentren. Für DSGVO-strikte Setups nutzt du Self-hosted Runner in der EU oder GitHub Enterprise Cloud mit Data Residency. Logs und Artifacts liegen ebenfalls auf den Plattformservern.

Wie binde ich GitHub Actions an Slack oder Teams?

Über Webhook-Actions wie slackapi/slack-github-action oder actions/notify-via-webhook. Failure-Notifications schickst du via if: failure()-Condition. Für komplexe Eskalationen kann eine externe Notification-Plattform sinnvoller sein.