GitHub Actions CI/CD Pipeline einrichten – Anleitung 2025

Was ist GitHub Actions?

GitHub Actions ist die integrierte CI/CD-Plattform von GitHub. Mit Workflow-Dateien im YAML-Format automatisieren Sie:

• Continuous Integration (CI): Tests und Builds bei jedem Push oder Pull Request ausführen
• Continuous Deployment (CD): Automatisches Deployment auf Server, Cloud oder Container-Registry
• Automatisierungen: Codeformatierung, Security-Scans, Release-Notes generieren

Kostenmodell

• Public Repositories: Kostenlos unbegrenzt
• Private Repositories: 2.000 Minuten/Monat kostenlos (Free-Plan), 3.000 Min. (Pro), unbegrenzt für GitHub Enterprise

Grundbegriffe

Erster Workflow: Hello World

Erstellen Sie .github/workflows/hello.yml in Ihrem Repository:

name: Hello World

on:
  push:
    branches: [ main ]

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

      - name: Sag Hallo
        run: echo "Hallo aus GitHub Actions!"

Committen und pushen → In GitHub unter Actions sehen Sie den Workflow laufen.

CI-Pipeline für Node.js

name: Node.js CI

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

jobs:
  test:
    runs-on: ubuntu-latest

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

    steps:
      - 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: Lint prüfen
        run: npm run lint

      - name: Tests ausführen
        run: npm test

      - name: Build prüfen
        run: npm run build

Strategy Matrix

Das matrix-Keyword führt den Job für jede Kombination aus – hier werden 3 Node.js-Versionen parallel getestet. Ideal um sicherzustellen dass Ihr Code auf mehreren Versionen funktioniert.

Docker Image bauen und zu Registry pushen

name: Docker Build & Push

on:
  push:
    branches: [ main ]
    tags: [ 'v*' ]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
      - uses: actions/checkout@v4

      - name: Docker Buildx einrichten
        uses: docker/setup-buildx-action@v3

      - name: Bei GitHub Container Registry anmelden
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Metadaten extrahieren
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}

      - name: Docker Image bauen und pushen
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

Das Image wird zu ghcr.io (GitHub Container Registry) gepusht – kostenlos für öffentliche Repos, kostenloser Speicher für private Repos im Rahmen des Plans.

Deployment auf eigenem Server (SSH)

name: Deploy to Server

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    needs: build   # wartet auf erfolgreichen Build-Job

    steps:
      - name: Deploy via SSH
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /opt/meine-app
            git pull origin main
            docker compose pull
            docker compose up -d --remove-orphans
            docker system prune -f

Secrets konfigurieren

In GitHub: Repository → Settings → Secrets and variables → Actions → New repository secret

• SERVER_HOST: IP oder Domain des Servers
• SERVER_USER: SSH-Benutzer (z. B. deploy)
• SSH_PRIVATE_KEY: Privater SSH-Schlüssel (via cat ~/.ssh/id_ed25519)

Environments und Approval-Workflows

Für Produktion können Sie manuelle Genehmigungen erzwingen:

Repository → Settings → Environments → New environment → production

• Required reviewers: Wählen Sie Personen die Deployments genehmigen müssen
• Im Workflow: environment: production beim Deploy-Job

Der Workflow pausiert und wartet auf Genehmigung bevor auf Produktion deployed wird.

Nützliche GitHub Actions

Workflow-Kosten optimieren

# Nur bei Änderungen an relevanten Dateien ausführen
on:
  push:
    paths:
      - 'src/**'
      - 'package.json'
      - '.github/workflows/**'

# Job überspringen wenn Commit-Message [skip ci] enthält
if: "!contains(github.event.head_commit.message, '[skip ci]')"

FAQ

Kann GitHub Actions private Server erreichen?
Ja, via Self-hosted Runner. Installieren Sie den Runner-Agent auf Ihrem Server – dieser verbindet sich ausgehend zu GitHub, keine eingehenden Ports nötig.

Was ist der Unterschied zu Jenkins?
Jenkins ist selbst gehostet und hochgradig konfigurierbar aber aufwendig zu betreiben. GitHub Actions ist cloud-gehostet, einfacher zu starten und für die meisten KMU-Projekte völlig ausreichend.

Können Workflows auf andere Repositories zugreifen?
Ja, via persönliche Access Tokens oder GitHub Apps. Für Monorepos kann ein Workflow mehrere Services deployen.

Fazit

GitHub Actions ist 2025 der Standard für CI/CD in neuen Projekten. Die Integration direkt in GitHub, kostenlose Runner und hunderte vorgefertigter Actions machen es zum einfachsten Einstieg in automatisierte Deployments.

Wir implementieren CI/CD-Pipelines für Entwicklungsteams und KMU in Heidelberg, Mannheim und der Rhein-Neckar-Region. DevOps-Beratung anfragen.