CI/CD-Pipelines mit GitHub Actions erklärt

DevOps2026-09-12TryQuickToolBox

Du hast gerade einen Commit gepusht und führst nun manuell Tests aus, baust die App und lädst Dateien auf einen Server hoch. Es funktioniert, aber es ist langsam, fehleranfällig und skaliert nicht. Hier kommen CI/CD-Pipelines ins Spiel.

In diesem Leitfaden erklären wir die CI/CD-Konzepte und zeigen dir, wie du eine echte Pipeline mit GitHub Actions erstellst. Am Ende wirst du verstehen, wie du Tests, Builds und Deployments für jedes Projekt automatisieren kannst.

Was ist CI/CD?

CI (Continuous Integration) ist die Praxis, Codeänderungen automatisch zu testen und in einen gemeinsamen Branch zu integrieren. Jeder Push löst einen Build- und Testlauf aus, wodurch Integrationsprobleme frühzeitig erkannt werden.

CD (Continuous Delivery/Deployment) erweitert CI, indem es deine Anwendung automatisch für die Produktion vorbereitet (und optional bereitstellt). Continuous Delivery bedeutet, dass der Code immer bereit für das Deployment ist; Continuous Deployment bedeutet, dass er automatisch bereitgestellt wird.

Zusammen bilden CI/CD eine Pipeline: eine Reihe automatisierter Schritte, die deinen Code vom Commit bis zur Produktion bringen.

Warum GitHub Actions für CI/CD verwenden?

GitHub Actions ist eine CI/CD-Plattform, die in GitHub integriert ist. Sie ist kostenlos für öffentliche Repositories und bietet großzügige Minuten für private. Die wichtigsten Vorteile:

Integriert: Kein externer Dienst nötig; Workflows leben in deinem Repository.
Ereignisgesteuert: Löse Workflows bei Push, Pull Request, Zeitplan oder manueller Auslösung aus.
Erweiterbar: Tausende vorgefertigte Actions im GitHub Marketplace.
Matrix-Builds: Teste einfach über mehrere Betriebssysteme und Sprachversionen hinweg.

Kernkonzepte von GitHub Actions

Bevor du deinen ersten Workflow schreibst, verstehe diese Begriffe:

Begriff	Beschreibung
Workflow	Ein automatisierter Prozess, der in einer YAML-Datei unter `.github/workflows/` definiert ist.
Event	Ein Auslöser, der einen Workflow startet (z. B. `push`, `pull_request`).
Job	Eine Reihe von Schritten, die auf demselben Runner ausgeführt werden. Jobs laufen standardmäßig parallel.
Step	Eine einzelne Aufgabe innerhalb eines Jobs. Kann einen Befehl ausführen oder eine Action verwenden.
Action	Eine wiederverwendbare Codeeinheit (z. B. `actions/checkout`), die du in einen Step einbinden kannst.
Runner	Eine virtuelle Maschine, die Jobs ausführt (Ubuntu, Windows, macOS).

Deine erste CI-Pipeline erstellen

Lass uns einen einfachen CI-Workflow für ein Node.js-Projekt erstellen. Er führt bei jedem Push und Pull Request auf den Main-Branch Tests aus.

Erstelle .github/workflows/ci.yml:

name: CI

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

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x, 20.x]

    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm test

Dieser Workflow:

Wird bei Pushes und PRs auf main ausgelöst.
Führt einen Job namens test auf dem neuesten Ubuntu-Runner aus.
Verwendet eine Matrix, um gegen Node.js 18 und 20 zu testen.
Checkt den Code aus, richtet Node ein, installiert Abhängigkeiten und führt Tests aus.

Pushe diese Datei und beobachte den Actions-Tab. Du wirst zwei parallele Jobs sehen (einer pro Node-Version). Wenn ein Test fehlschlägt, schlägt der Workflow fehl und GitHub benachrichtigt dich.

Continuous Deployment hinzufügen

CI ist großartig, aber CD ist der Bereich, in dem die Automatisierung glänzt. Erweitern wir den Workflow, um nach erfolgreichen Tests auf dem Main-Branch auf einen Server bereitzustellen.

Wir fügen einen deploy-Job hinzu, der von test abhängt und nur bei Pushes auf main ausgeführt wird.

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Deploy to server
      uses: appleboy/ssh-action@v1.0.0
      with:
        host: ${{ secrets.SSH_HOST }}
        username: ${{ secrets.SSH_USER }}
        key: ${{ secrets.SSH_KEY }}
        script: |
          cd /var/www/myapp
          git pull origin main
          npm ci --production
          pm2 restart myapp

Wichtige Punkte:

needs: test stellt sicher, dass das Deployment nur ausgeführt wird, wenn die Tests bestanden sind.
Die if-Bedingung beschränkt das Deployment auf Pushes auf main.
Secrets (SSH_HOST, SSH_USER, SSH_KEY) werden in den GitHub-Repository-Einstellungen gespeichert und sicher injiziert.

Dieses Muster funktioniert für viele Deployment-Ziele: SSH, Docker-Registries, Cloud-Plattformen (AWS, Vercel, Netlify) oder Kubernetes.

Best Practices für CI/CD mit GitHub Actions

Halte Workflows schnell: Cache Abhängigkeiten (z. B. actions/cache), um Build-Zeiten zu reduzieren.
Fail fast: Führe schnelle Checks (Linting) vor langsameren Tests aus.
Verwende Environments: Konfiguriere Schutzregeln für Produktions-Deployments.
Sichere Secrets: Speichere niemals Anmeldedaten im Klartext; verwende GitHub Secrets.
Überwachen und alarmieren: Richte Benachrichtigungen für fehlgeschlagene Workflows ein.

Fehlgeschlagene Workflows debuggen

Wenn ein Workflow fehlschlägt, zeigt GitHub Logs für jeden Schritt an. Häufige Probleme sind:

Fehlende Abhängigkeiten: Stelle sicher, dass npm ci oder ein Äquivalent vor den Tests ausgeführt wird.
Falsche Secrets: Überprüfe Namen und Werte.
Berechtigungsfehler: Überprüfe Runner-Berechtigungen und SSH-Schlüssel.

Du kannst auch Debug-Logging aktivieren, indem du das Repository-Secret ACTIONS_STEP_DEBUG auf true setzt.

FAQ

Was ist der Unterschied zwischen CI und CD?

CI automatisiert das Testen und die Integration von Codeänderungen. CD automatisiert die Bereitstellung oder das Deployment dieser Änderungen in einer Umgebung. CI stellt die Codequalität sicher; CD stellt sicher, dass der Code schnell und zuverlässig zu den Nutzern gelangt.

Ist GitHub Actions kostenlos?

GitHub Actions ist kostenlos für öffentliche Repositories. Für private Repositories erhältst du ein monatliches Kontingent an kostenlosen Minuten (z. B. 2.000 Minuten für Free-Konten) und zahlst für zusätzliche Nutzung. Self-hosted Runner sind ebenfalls eine Option.

Kann ich GitHub Actions für Nicht-GitHub-Projekte verwenden?

Ja, GitHub Actions kann jede Kommandozeilen-Tools ausführen. Du kannst es verwenden, um Projekte zu bauen und bereitzustellen, die anderswo gehostet werden, solange der Code auf GitHub liegt oder du Actions zum Abrufen verwendest.

Bereit, deine CI/CD zu optimieren? Beginne damit, deine Tests mit GitHub Actions zu automatisieren. Für eine schnelle Möglichkeit, Deployment-Logs zu analysieren, probiere unseren Nginx Log Analyzer, um Fehler und Performance-Probleme nach jedem Deployment zu erkennen.