CI/CD Pipeline mit GitHub Actions 2026 einrichten

GitHub Actions ist 2026 die meistgenutzte CI/CD-Plattform. Kostenlos für öffentliche Repos, großzügige Free-Tier-Kontingente für private, tiefe GitHub-Integration. Dieser Guide zeigt, wie Sie eine professionelle Pipeline aufbauen.

Was ist CI/CD?

CI (Continuous Integration): Code wird bei jedem Push automatisch getestet

CD (Continuous Deployment/Delivery): Erfolgreiche Builds werden automatisch deployed

Grundlagen: Workflow-Dateien

Workflows leben in .github/workflows/ als YAML-Dateien.

``yaml
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]

jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- run: npm test
`

Eine komplette Pipeline aufbauen

Stufe 1: Lint und Test

`yaml
name: CI
on: [push, pull_request]

jobs:
quality:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- run: npm run lint
- run: npm run type-check
- run: npm test -- --coverage
- name: Coverage Upload
uses: codecov/codecov-action@v4
`

Stufe 2: Build

`yaml
build:
needs: quality
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- run: npm run build
- name: Upload Artifact
uses: actions/upload-artifact@v4
with:
name: build
path: dist/
`

Stufe 3: Deploy

`yaml
deploy:
needs: build
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Deploy to Vercel
uses: amondnet/vercel-action@v25
with:
vercel-token: ${{ secrets.VERCEL_TOKEN }}
vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
vercel-args: '--prod'
`

Matrix-Builds

Testen Sie gegen mehrere Versionen parallel:

`yaml
jobs:
test:
strategy:
matrix:
node-version: [20, 22, 23]
os: [ubuntu-latest, windows-latest, macos-latest]
runs-on: ${{ matrix.os }}
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
- run: npm ci
- run: npm test
`

Secrets verwalten

Nie Secrets in Code hardcoden. Nutzen Sie GitHub Secrets:

Repo → Settings → Secrets and variables → Actions




Secret hinzufügen (z. B. DATABASE_URL)

Im Workflow referenzieren:

`yaml
env:
DATABASE_URL: ${{ secrets.DATABASE_URL }}
`

Für organisationweite Secrets nutzen Sie Environments:

`yaml
jobs:
deploy:
environment: production
steps:
# ...
`

Caching für schnellere Builds

Dependency-Cache

`yaml


uses: actions/setup-node@v4


with:
node-version: '22'
cache: 'npm'
`

Docker Layer Cache

`yaml


uses: docker/setup-buildx-action@v3

uses: docker/build-push-action@v5

with:
cache-from: type=gha
cache-to: type=gha,mode=max
`

Parallele Jobs und Dependencies

`yaml
jobs:
lint:
runs-on: ubuntu-latest
# ...
test-unit:
runs-on: ubuntu-latest
# ...
test-e2e:
runs-on: ubuntu-latest
# ...
build:
needs: [lint, test-unit, test-e2e]
runs-on: ubuntu-latest
# ...
`

needs definiert Abhängigkeiten. Jobs ohne needs laufen parallel.

Environment-Deploys

`yaml
deploy-staging:
needs: build
if: github.ref == 'refs/heads/develop'
environment: staging
runs-on: ubuntu-latest
steps:
- name: Deploy to Staging
run: ./scripts/deploy.sh staging

deploy-production:
needs: build
if: github.ref == 'refs/heads/main'
environment: production
runs-on: ubuntu-latest
steps:
- name: Deploy to Production
run: ./scripts/deploy.sh prod
`

Nützliche Actions 2026

| Action | Verwendung |
|--------|-----------|
| actions/checkout@v4 | Repository auschecken |
| actions/cache@v4 | Dateien cachen |
| actions/upload-artifact@v4 | Build-Artefakte speichern |
| actions/download-artifact@v4 | Artefakte herunterladen |
| docker/build-push-action@v5 | Docker Images bauen und pushen |
| softprops/action-gh-release@v2 | GitHub Releases erstellen |

Kosten optimieren

| Trigger | Free-Minuten | Tipp |
|---------|-------------|------|
| Public Repos | Unlimited | Kostenlos |
| Private Repos | 2.000 min/Monat (Free) | Nur bei PRs/Push triggern |
| Self-hosted Runner | Unlimited | Eigene Hardware |

FAQ

Wie lange sollte ein CI-Build dauern?

Unter 5 Minuten für PRs. Nutzen Sie Caching, parallelisieren Sie Jobs, und isolieren Sie langsame E2E-Tests.

Monorepo CI?

Nutzen Sie paths Filter oder Tools wie Turborepo/Nx, um nur geänderte Pakete zu bauen.

Brauche ich self-hosted Runner?

Meistens nein. GitHub-hosted Runner sind schnell und kostenlos für öffentliche Repos. Self-hosted lohnt sich für spezielle Hardware (GPUs) oder hohe Build-Volumen.

Wie teste ich Workflows lokal?

Mit act` (https://github.com/nektos/act) können Sie GitHub Actions lokal in Docker ausführen.

Fazit

GitHub Actions ist 2026 die beste CI/CD-Lösung für die meisten Teams. Kostenlos startbar, tief in GitHub integriert und extrem flexibel. Starten Sie mit einer einfachen Test-Pipeline und erweitern Sie schrittweise um Build, Deploy und Multi-Environment-Strategien.