GitHub Actions: CI/CD-Pipelines automatisch erstellen und deployen

Stell dir vor, jedes Mal wenn du Code in dein Repository pushst, werden automatisch Tests ausgeführt, der Code auf Fehler geprüft und bei Erfolg direkt in die Produktion deployed. Genau das ermöglicht GitHub Actions – die integrierte Automatisierungsplattform von GitHub. Seit ihrer Einführung 2019 hat sie sich zum De-facto-Standard für CI/CD (Continuous Integration / Continuous Deployment) in GitHub-Projekten entwickelt. Dieser Artikel erklärt die Grundkonzepte und zeigt an konkreten Beispielen, wie man eigene Pipelines aufbaut.

Was ist CI/CD und warum ist es wichtig?

Continuous Integration (CI) bedeutet, dass Codeänderungen regelmäßig in einen gemeinsamen Branch integriert werden und dabei automatisch Tests ausgeführt werden. Fehler werden so frühzeitig entdeckt, bevor sie sich in der Codebasis festsetzen. Continuous Deployment (CD) geht einen Schritt weiter: Wenn alle Tests grün sind, wird der Code automatisch in die Staging- oder Produktionsumgebung ausgerollt – ohne manuelle Eingriffe.

Der Vorteil liegt auf der Hand: Statt stundenlanger manueller Deployments und fehleranfälliger Checklisten übernimmt eine automatisierte Pipeline die Routinearbeit. Das Team kann sich auf das Wesentliche konzentrieren – das Schreiben von Code.

Die Grundbausteine von GitHub Actions

GitHub Actions ist um einige zentrale Konzepte aufgebaut, die man kennen muss, um eigene Automatisierungen zu schreiben:

Ein Workflow ist eine automatisierte Prozesssequenz, die in einer YAML-Datei im Verzeichnis .github/workflows/ des Repositories definiert wird. Ein Repository kann mehrere Workflows haben – zum Beispiel einen für Tests und einen für das Deployment. Workflows werden durch Trigger (Ereignisse) ausgelöst.

Ein Workflow besteht aus einem oder mehreren Jobs. Jobs laufen standardmäßig parallel, können aber mit needs sequenziell abhängig voneinander gemacht werden. Jeder Job läuft in einer eigenen virtuellen Maschine (Runner) – GitHub stellt Ubuntu, Windows und macOS zur Verfügung.

Jeder Job besteht aus einer Reihe von Steps (Schritten). Ein Step kann entweder ein Shell-Befehl (run) oder eine wiederverwendbare Action (uses) sein. Actions sind vorgefertigte Module aus dem GitHub Marketplace, die häufige Aufgaben kapseln – zum Beispiel das Auschecken des Codes, das Einrichten von Node.js oder das Deployment zu einem Cloud-Anbieter.

Trigger-Typen: Wann startet ein Workflow?

Praxisbeispiel: Node.js-Testpipeline

Das folgende YAML-Snippet zeigt eine vollständige CI-Pipeline für ein Node.js-Projekt. Sie wird bei jedem Push und bei jedem Pull Request auf den main-Branch ausgelöst, installiert die Abhängigkeiten, prüft den Code mit ESLint und führt die Tests aus:

name: Node.js CI

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

jobs:
  test:
    runs-on: ubuntu-latest

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

    steps:
      - name: Code auschecken
        uses: actions/checkout@v4

      - name: Node.js ${{ matrix.node-version }} einrichten
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'

      - name: Abhängigkeiten installieren
        run: npm ci

      - name: ESLint ausführen
        run: npm run lint

      - name: Tests ausführen
        run: npm test

Die matrix-Strategie führt den Job für mehrere Node.js-Versionen parallel aus – so stellt man sicher, dass der Code mit allen unterstützten Versionen kompatibel ist.

Automatisches Deployment zu Netlify bei Push auf main

Ein häufiges Szenario ist das automatische Deployment einer statischen Website zu Netlify, sobald Änderungen auf den main-Branch gepusht werden. Dazu benötigt man ein Netlify-Konto, eine Site-ID und einen API-Token, die als GitHub Secrets im Repository hinterlegt werden (unter Settings → Secrets and variables → Actions).

name: Deploy to Netlify

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

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

      - name: Abhängigkeiten installieren
        run: npm ci

      - name: Projekt bauen
        run: npm run build

      - name: Zu Netlify deployen
        uses: nwtgck/actions-netlify@v3
        with:
          publish-dir: './dist'
          production-branch: main
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
          NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}

Secrets sicher verwalten

API-Schlüssel, Tokens und Passwörter gehören niemals direkt in YAML-Dateien. GitHub bietet mit Secrets einen verschlüsselten Speicher für sensible Daten. Repository-Secrets sind unter Settings → Secrets and variables → Actions zu finden. In Workflows greift man über die Syntax ${{ secrets.MEIN_SECRET }} auf sie zu. Für organisationsweite Geheimnisse gibt es Organization Secrets, die an mehrere Repositories verteilt werden können.

Kosten und Free-Tier

GitHub Actions ist für öffentliche Repositories vollständig kostenlos – ohne Limit. Für private Repositories gibt es im kostenlosen Plan 2.000 Minuten pro Monat auf Linux-Runnern. Windows- und macOS-Runner verbrauchen mehr Minuten (Faktor 2 bzw. 10). Für die meisten kleinen bis mittelgroßen Projekte reicht das kostenlose Kontingent problemlos aus. Details zur Abrechnung finden sich in der GitHub-Dokumentation zu Actions-Billing.

Häufig gestellte Fragen

Kann ich GitHub Actions auch für Nicht-GitHub-Projekte nutzen?

GitHub Actions ist an GitHub-Repositories gebunden. Wer GitLab oder Bitbucket nutzt, findet dort ähnliche Dienste (GitLab CI/CD, Bitbucket Pipelines). Für reine Cloud-Deployments gibt es außerdem Plattformen wie CircleCI oder Jenkins, die auch mit anderen Git-Hosting-Diensten zusammenarbeiten.

Was ist der Unterschied zwischen einem Runner und einem Job?

Ein Job ist die logische Einheit in einem Workflow – eine Sammlung von Schritten, die nacheinander ausgeführt werden. Ein Runner ist die physische oder virtuelle Maschine, auf der der Job läuft. GitHub stellt gehostete Runner bereit (ubuntu-latest, windows-latest, macos-latest), aber man kann auch selbst gehostete Runner in der eigenen Infrastruktur betreiben.

Wie lange bleiben Workflow-Logs gespeichert?

GitHub speichert Workflow-Logs standardmäßig 90 Tage lang. Artefakte (also Dateien, die ein Workflow erzeugt und hochlädt) werden ebenfalls 90 Tage aufbewahrt. Beide Werte lassen sich in den Repository-Einstellungen anpassen. Bei kostenpflichtigen Plänen sind längere Aufbewahrungszeiten möglich.

Wie kann ich einen Workflow manuell auslösen?

Mit dem Trigger workflow_dispatch lässt sich ein Workflow manuell über die GitHub-Oberfläche starten. Man navigiert zu Actions → dem gewünschten Workflow → „Run workflow". Es können dabei auch Eingabeparameter definiert werden, die man beim manuellen Start angeben muss – nützlich für flexible Deployment-Targets.