CI Pipeline aufsetzen – GitHub Actions einfach erklärt

Du willst sicherstellen, dass dein Code beim Push automatisch geprüft wird und jeder Branch sauber bleibt. Mit GitHub Actions richtest du in wenigen Minuten eine CI Pipeline ein, die Tests, Linting und den Build automatisiert. Das spart Zeit, verhindert Fehler und macht dein Projekt verlässlicher. In diesem Leitfaden zeige ich dir, was eine Pipeline ausmacht, wie Workflows, Jobs und Runner zusammenarbeiten und wie du eine erste Pipeline Schritt für Schritt aufsetzt.

Was CI ist und wie GitHub Actions funktioniert

Continuous Integration (CI) bedeutet, dass Änderungen früh und häufig integriert und automatisch geprüft werden. In GitHub Actions beschreibst du das als Workflow in YAML. Ein Workflow besteht aus Jobs, die auf Runnern laufen. Trigger wie push oder pull_request starten den Ablauf, Schritte führen Befehle aus und Artefakte bewahren Ergebnisse auf. Das Ganze ist deklarativ, leicht nachzuvollziehen und direkt im Repository versioniert.

Voraussetzungen

Du brauchst ein GitHub Repository mit ein wenig Code, Schreibrechte im Repo und die Möglichkeit, Dateien zu erstellen. GitHub Actions ist proaktiv aktiviert, die Konfiguration liegt unter .github/workflows. Alles, was du dort speicherst, kann deine Pipeline starten.

Deine erste Pipeline in 10 Minuten

Repository vorbereiten

Lege im Repo den Ordner .github/workflows an. In diesem Ordner liegt jede Workflow-Datei. Der Dateiname ist frei wählbar, zum Beispiel ci.yml. Achte darauf, dass der Branch, in den du committest, im Trigger des Workflows enthalten ist.

Workflow erstellen

Das folgende Beispiel prüft eine Node.js App. Du bekommst Checkout, Node Setup, Caching, Install, Tests und einen Build. Du kannst die Befehle einfach auf Python, Java oder .NET anpassen.

name: CI

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

permissions:
  contents: read

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

jobs:
  build-and-test:
    runs-on: ubuntu-latest

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

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

      - name: Abhängigkeiten installieren
        run: npm ci

      - name: Lint ausführen
        run: npm run lint --if-present

      - name: Tests ausführen
        run: npm test -- --ci --reporters=default

      - name: Build erzeugen
        run: npm run build --if-present

      - name: Artefakte sichern
        if: success()
        uses: actions/upload-artifact@v4
        with:
          name: build
          path: |
            dist
            build

Dieser Workflow startet bei push und pull_request auf main, vermeidet Parallelkollisionen durch concurrency und nutzt Caching für schnelle Builds. Wenn dein Projekt ein anderes Ökosystem nutzt, ersetzt du den Setup-Schritt und die Befehle entsprechend.

Secrets sicher verwalten

Viele Pipelines brauchen Zugangsdaten, zum Beispiel Tokens für npm, Docker oder eine Cloud. Lege diese Werte unter Settings – Secrets and variables – Actions – New repository secret ab. Im Workflow greifst du mit ${{ secrets.MEIN_SECRET }} darauf zu. Schreibe niemals Secrets in den Code oder in Klartext in die YAML. Für Deployments in die Cloud kannst du zusätzlich OIDC nutzen, um ohne statische Schlüssel temporäre Anmeldeinformationen zu beziehen.

Caching und Geschwindigkeit

Schnelle Pipelines motivieren. Nutze integrierte Caches wie cache: npm oder setze gezielte Caches mit actions/cache ein. Cache nur deterministische Abhängigkeiten. Bauteile, die sich häufig ändern, bringen wenig. Halte die Anzahl der Schritte schlank und führe Lint und Tests vor dem Build aus, damit Fehler früh stoppen.

Lint, Tests und Build sinnvoll anordnen

Eine robuste Reihenfolge ist Install – Lint – Test – Build. So sparst du Ressourcen, wenn Linting oder Tests scheitern. Für größere Projekte lohnt eine Job-Aufteilung in parallele Schritte, zum Beispiel getrennte Jobs für Unit-Tests und E2E-Tests, die beide vor dem Build laufen. Ergebnisse kannst du als Artefakte sichern und später analysieren.

Pull Requests als Qualitätsgate

Aktiviere Branch Protection für main und verlange, dass der CI-Workflow erfolgreich ist, bevor ein Pull Request gemergt wird. Damit stellst du sicher, dass Standardchecks nie übersprungen werden. Für Teams ist das ein einfacher Weg, Qualität konstant zu halten.

Optional: Deployment mit Environments

Wenn die CI stabil läuft, ergänzt du ein Deployment als eigenen Job. Nutze environments mit Schutzregeln wie Required Reviewers oder Wartezeiten, damit nur geprüfte Builds live gehen. Im Deployment-Job verwendest du separate Secrets und führst zum Beispiel Docker Push, K8s Apply oder Cloud CLI Befehle aus.

Fehlersuche in der Praxis

Wenn ein Lauf fehlschlägt, öffne den Run, lies die Logausgabe von oben nach unten und prüfe, ob der Fehler schon beim Install oder erst im Build entsteht. Häufige Ursachen sind falsche Pfade, fehlende Node-Versionen, veraltete Lockfiles oder nicht gesetzte Secrets. Nutze Re-run jobs nach kleinen Fixes, beobachte die Dauer einzelner Schritte und entferne alles, was nicht notwendig ist.

Häufige Fehler vermeiden

Vermeide zu breite Trigger, die jeden Commit auf allen Branches bauen, wenn das nicht nötig ist. Halte permissions so minimal wie möglich und setze concurrency, um doppelte Läufe zu verhindern. Schreibe vollständige Pfade bei Artefakten und prüfe, dass Artefaktordner tatsächlich existieren. Dokumentiere in der README, wie die Pipeline funktioniert und wo Secrets gepflegt werden.

Fazit

Mit GitHub Actions richtest du in kurzer Zeit eine CI Pipeline ein, die Tests, Linting und Build zuverlässig automatisiert. Du hast gelernt, wie Workflows, Jobs, Runner, Caching, Secrets und Branch Protection zusammenspielen. Starte mit einem einfachen Workflow, halte ihn übersichtlich und erweitere ihn schrittweise um Deployment und Qualitätschecks. So bleibt dein Code stabil, dein Team schneller und Releases werden planbar.