Zum Inhalt springen
ad hoc AI Workbench

CI/CD und Migrationen

Status: Entwurf · Spec-Kandidat: ja

Anforderungen

  • CI/CD-fähige Bereitstellung (NFR-007).
  • Migrationswerkzeug Pflicht (Datenbankschema versioniert).
  • Lint- und Testpflicht vor Merge.
  • Reproduzierbare Builds (deterministische Container-Images).

Source-Hosting + Build-Pipeline (gesetzt)

  • Quellcode liegt auf GitHub. Pro Service ein eigenes Repository (oder ein gemeinsamer Mono-Repo-Pfad — Detail offen, abhängig von Stack-Wahl).
  • Image-Build erfolgt durch Coolify über die docker-compose.yaml des jeweiligen Repos. Coolify zieht den GitHub-Branch (typisch main für Prod, staging für Test), baut Multi-Stage-Image lokal auf der Coolify-Instanz und deployt rolling.
  • Kein externes Image-Registry nötig: Coolify hält gebaute Images lokal. Wer ein dediziertes Registry möchte (z. B. GHCR), kann in Coolify auf Pre-Build via GitHub Actions umstellen — derzeit nicht erforderlich.
  • Trigger: Push auf den deploy-Branch löst Build + Deploy aus (Webhook von GitHub auf Coolify).
  • Tests vor Merge laufen in GitHub Actions (kostenfrei für öffentliche und in den Free-Tier-Limits private Repos): Lint, Unit, Integration. Erst grüner Run → Merge → Coolify-Deploy.

Migrationen

  • Alle Änderungen am mdm-Schema sind versioniert.
  • Reine Metadaten-Änderungen (neuer Entitätstyp, neues Attribut) erfolgen nicht über Migrationen, sondern über die API. Damit bleibt NFR-004 erfüllt.
  • Datenbank-Funktionen, Trigger und Views sind ebenfalls Bestandteil der Migrationen.
  • Rollback-Strategie pro Migration definiert (dokumentierter Forward-Fix als Standard).
  • Migrations-Ausführung im Deploy: migrate-Service im docker-compose.yaml als One-Shot-Job (depends_on der App), oder command:-Override im App-Container vor Start.

Pipeline-Stufen (Skizze)

GitHub Actions (vor Merge auf deploy-Branch):

  1. Lint / Static Analysis
  2. Unit Tests
  3. Integrationstests gegen ephemere PostgreSQL (Service-Container)
  4. Sicherheits-Scan (Abhängigkeiten, optional Image)

Coolify (nach Push auf deploy-Branch):

  1. git pull → Build via docker-compose.yaml
  2. Run Migrations-Job
  3. Rolling-Deploy mit Health-Check
  4. Bei Fehler: vorheriger Container bleibt, kein Traffic-Switch

Manuelle Freigabe für Produktion über getrennten Branch / Environment in Coolify.

Offen

  • Wahl Migrationswerkzeug (Liquibase, Flyway, golang-migrate, Atlas, sqlx-migrate, …) — abhängig von Stack-Wahl (siehe Tech-Stack-Entscheidung).
  • Strategie für lange laufende Migrationen (Lock-Vermeidung, Online-Schemaänderungen).
  • Branch-Konvention: main/staging/production vs. trunk-based mit Tags. Abhängig von Team-Größe.
  • Mono-Repo vs. Multi-Repo (API + Worker + Frontend) — Stack-Wahl entscheidet das mit.

Verwandte Dokumente