🔄 · Automatisch deployen

CI/CD: Von Commit zu Deployment ohne Handarbeit

Continuous Integration und Continuous Deployment bedeuten: Code pushen, Tests laufen automatisch, bei Erfolg wird deployed. Kein manuelles SSH, kein vergessenes Deployment, keine „läuft bei mir"-Probleme.

GitHub ActionsGitea ActionsPipelineTestsDocker Build

CI/CD-Grundkonzepte: Was passiert wann?

Continuous Integration (CI) prüft automatisch bei jedem Push ob der Code funktioniert: Tests laufen, Linting, Build. Fehler werden sofort sichtbar – nicht erst nach dem Deployment.

Continuous Deployment (CD) deployt automatisch wenn CI grün ist. Bei selbst gehosteten Projekten oft als simpler Deploy-Schritt via SSH:

# GitHub Actions – einfacher Deploy via SSH
name: Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: deploy
          key: ${{ secrets.SSH_KEY }}
          script: |
            cd /opt/stacks/meinprojekt
            git pull
            docker compose pull
            docker compose up -d

GitHub Actions vs. Gitea Actions vs. selbst gehostet

Drei Optionen – mit unterschiedlichen Trade-offs:

GitHub Actions: 2000 Freiminuten/Monat auf kostenlosen Accounts. Riesiges Ökosystem an fertigen Actions. Für Open-Source und öffentliche Repos ideal.
Gitea Actions: Kompatibel mit GitHub-Actions-Syntax – einfache Migration. Auf selbst gehostetem Gitea laufend, volle Kontrolle über die Pipeline-Umgebung.
Selbst gehosteter Runner: Eigener Runner läuft auf dem Zielserver – kein SSH nötig, Runner hat direkt Zugriff. Sicherheitsüberlegungen wichtig (vertrauenswürdige Repos only).

Für Hobby-Projekte: GitHub Actions mit SSH-Deploy ist der einfachste Einstieg. Kein zusätzlicher Server nötig, Secrets sicher in GitHub gespeichert.

Docker Images bauen und in Registry pushen

Professionelle CI/CD-Pipelines bauen Docker Images und pushen sie in eine Registry:

GitHub Container Registry (ghcr.io): Kostenlos für öffentliche Images, eng integriert mit GitHub Actions
Selbst gehostete Registry: Gitea oder eigene Docker Registry – für private Images ohne Cloud-Dependency
Multi-Arch Builds: docker buildx baut Images für AMD64 und ARM64 gleichzeitig – wichtig wenn Raspberry Pi-Deployment geplant ist
Cache nutzen: Build-Cache in Actions mit `cache-from: type=gha` verkürzt Build-Zeit von Minuten auf Sekunden

Kompletter Flow: Push → Test → Build Image → Push to Registry → Server pulled neues Image → Compose Restart.

Häufige Fragen zu CI/CD

Was sollte eine minimale CI-Pipeline prüfen?

Minimum: Linting (Code-Formatierung/Stil), Unit Tests, Build-Schritt (kompiliert/startet es?). Für Docker-Projekte: Image bauen ohne Fehler. Mehr ist besser aber lieber eine einfache Pipeline die läuft als eine komplexe die niemand versteht.

Wie halte ich Secrets in der Pipeline sicher?

Secrets in den Repository-Einstellungen speichern (GitHub: Settings → Secrets), nie in YAML-Dateien einchecken. Als `${{ secrets.MEIN_SECRET }}` referenzieren. GitHub maskiert Secret-Werte automatisch in Logs. SSH-Keys für Server-Zugriff als Deployment-Key anlegen – nicht den persönlichen Key nutzen.

Pipeline schlägt fehl – wie debuggen?

GitHub Actions: Logs direkt in der UI, re-run mit Debug-Logging aktivieren. Lokal testen mit `act` (Docker-basiertes Tool das GitHub Actions lokal ausführt). Häufige Ursachen: fehlende Secrets im Fork, falsche Branch-Namen, abgelaufene SSH-Keys.

Wann ist CI/CD over-engineering?

Für Solo-Projekte oder Skripte die selten ändern: ein einfaches `git pull` auf dem Server per Cron oder Webhook reicht. CI/CD lohnt sich wenn: mehrere Personen am Code arbeiten, Tests existieren die automatisch laufen sollen, oder Deployments komplex und fehleranfällig sind.