Synaplan ist eine Open-Source-KI-Plattform — Backend in PHP 8.3 / Symfony 7, Frontend in Vue 3 / TypeScript, dazu eingebettete Chat-Widgets, RAG mit Qdrant und einer ganzen Reihe von Plugins für unsere Kunden. Wer eine Plattform dieser Größe baut, schreibt heute nicht mehr jede Zeile selbst: Wir vibe-coden vieles davon — also: Prompt rein, Vorschlag raus, einbauen, weiter. Das ist schnell, das ist produktiv. Und genau deshalb brauchen wir ein Sicherheitsnetz, das jede Zeile gegen die Realität prüft, bevor sie auch nur in die Nähe eines Kunden kommt.

Das Sicherheitsnetz ist unsere CI-Pipeline. Sie läuft bei jedem Push, bei jedem Pull Request, in der Kern-Plattform genauso wie in jedem Plugin. Wenn ein Check rot wird, geht nichts in Produktion — auch wenn die KI ganz überzeugt war, dass der Code passt.

Warum unit tests allein nicht reichen

KI-generierter Code sieht oft fast richtig aus. Eine Funktion, die Straßennamen normalisiert, ein Endpoint, der einen Webhook entgegennimmt, ein Vue-Component, das einen Verlauf rendert — alles syntaktisch sauber, alles compiliert, alle Unit-Tests grün. Und trotzdem: falsche Annahmen über die Datenbank, fehlende Migrations, kaputte Auth-Flows, ein Bundle, das 30 Prozent zu groß ist.

Deshalb haben wir die CI-Pipeline so gebaut, dass sie weit über Unit-Tests hinaus geht. Sie prüft Formatierung, Typen, Logik, Datenbankschema, Sicherheits-Audits, vollständige End-to-End-Flows in echten Browsern gegen eine echte Datenbank in einem echten Docker-Container — und am Ende baut sie das Production-Image, das eine Minute später auf unseren Servern landen kann.

Das Bild oben zeigt einen typischen grünen Lauf auf main: zwölf Minuten und 27 Sekunden, 58 Test-Files, 549 bestandene Frontend-Tests, dazu Backend, Docker-Build, vier Playwright-Matrizen und Deploy. Keine einzige Manuell-Klick-Erinnerung.

Was die Pipeline prüft (Schritt für Schritt)

Unsere ci.yml führt acht Jobs aus, die aufeinander aufbauen:

1. PHP Code Formatting. PSR-12 über composer lint. Wer einen geschweiften Klammer-Stil bricht, bekommt rot — auch die KI.

2. Backend (PHP / Symfony). Hier passiert die Hauptarbeit auf der Server-Seite:

PHPStan auf strenger Stufe — statische Analyse fängt Typfehler ab, die ESLint und Tests nie sehen würden.
Doctrine-Migrations werden gegen eine echte MariaDB 12.2 ausgeführt — kein schema:update --force, weil das in Produktion ein Albtraum wäre.
doctrine:schema:validate prüft, dass das ORM-Mapping und die migrierte Datenbank übereinstimmen. Wer ein Entity ändert, ohne eine Migration zu liefern, bricht die Pipeline.
PHPUnit läuft die komplette Test-Suite (Unit + Integration + Functional). Wir testen, was passiert, wenn ein User über WhatsApp eine PDF schickt — nicht nur, ob die Funktion mit einem fiktiven Mock-Objekt das richtige Tupel zurückgibt.
Bash-Tests gegen das Migrations-Bootstrap-Skript im Docker-Image — weil Migrations im Container etwas anderes sind als auf dem Laptop.
Generierung der OpenAPI-Spec, die wir gleich an das Frontend reichen.

3. Frontend (Vue / TypeScript). Die Zod-Schemas werden aus der gerade erzeugten OpenAPI-Spec generiert — so weiss das Frontend immer, wie das Backend gerade aussieht.

Prettier und ESLint für Formatierung und Code-Style.
vue-tsc -b — statische Typprüfung für Vue + TypeScript. Das fängt Klassen von Fehlern ab, die ESLint nicht sieht.
549 Vitest-Tests in 58 Test-Files — Komponenten, Composables, Stores, Utilities.
Production-Build der App und des einbettbaren Chat-Widgets.

4. Build Docker Image. Ein vollständiges FrankenPHP-Image wird gebaut, mit allen Frontend-Artefakten kombiniert und als Tar exportiert.

5. E2E-Tests mit Playwright. Hier wird es ernst. Wir starten die geschulte Docker-Compose-Konfiguration und fahren vier parallele Matrizen dagegen:

Chromium + Passwort-Login
Firefox + Passwort-Login
Chromium + OIDC (Keycloak)
Chromium + OIDC mit automatischem Redirect

Echt-Browser, echte Datenbank, echter Login-Flow, echte API-Calls. Wenn die Authentifizierung kaputt ist, wenn ein Webhook timeoutet, wenn das Frontend einen Endpoint anders aufruft als das Backend ihn anbietet — hier kommt das raus.

6. Push Docker Image. Nur auf main oder Release-Tags, und nur wenn alles drüber grün ist. Das Image wandert in die GitHub Container Registry.

7. Deploy Cloudflare Worker. Unser Edge-Worker (Routing, Geo-Headers) wird parallel ausgerollt.

8. All Checks Passed. Ein einziger Gate-Job, der in der Branch Protection als Pflicht-Check eingetragen ist. Ist er rot, wird nicht gemerged. Punkt.

Die Pipeline gilt auch für Plugins

Das Wichtige: Diese Disziplin ist nicht auf die Kern-Plattform beschränkt. Jedes offiziell unterstützte Plugin bringt seine eigene CI mit denselben Prinzipien:

Synamail (Outlook-Add-in, Vue 3 + Office.js): Linting, vue-tsc, Vitest, Manifest-Validierung gegen die Microsoft-Schemas, Bundle-Size-Budget, Playwright-Sideload-Tests.
SortX (lokaler Dokumenten-Klassifizierer in Go + PHP-Plugin): go vet, go build, PHP-Lint für den Plugin-Teil, docker compose config zur Validierung der Compose-Datei, Struktur-Checks.

Das heißt: Wenn du Synaplan mit Plugins betreibst, gilt für jeden einzelnen Baustein der gleiche Qualitätsstandard. Das bekommst du bei einer geschlossenen SaaS nie — dort vertraust du dem Anbieter blind. Bei uns kannst du jeden CI-Run lesen, jedes Test-Result anschauen, jeden grünen Haken überprüfen.

Von grünem Haken zu Produktion

Ist die Pipeline auf main grün, passiert der Rest automatisch:

Das Image wird mit den Tags latest, vX.Y.Z, vX.Y, vX in GHCR gepublisht.
Auf den Produktions-Servern läuft ein Watchguard, der GHCR pollt.
Sobald ein neues latest da ist, zieht er das Image und tauscht den Container.
Cloudflare Worker werden parallel deployt.

Kein manuelles SSH. Kein scp. Kein „ich pushe schnell vor dem Wochenende“. Wenn die Pipeline grün ist, ist der Code reif für Produktion — wenn sie es nicht ist, bleibt er draußen.

Was das für Sie als Kunde heißt

Wenn Sie Synaplan einsetzen — als gehosteten Service oder als Self-Hosted-Plattform auf Ihrer eigenen Infrastruktur — bekommen Sie eine Plattform, die nachprüfbar unter Kontrolle ist:

Open Source, jeder CI-Lauf ist öffentlich.
549 automatisierte Tests im Frontend, dazu Backend-Suite, dazu vier Playwright-Matrizen.
Kein Stealth-Deployment: Jede Version, die in Produktion läuft, hat erst eine grüne Pipeline gesehen.
Gleicher Standard für Plugins — auch Drittanbieter-Funktionalität wird geprüft, nicht durchgewunken.

Vibe Coding ohne Sicherheitsnetz ist ein Risiko. Vibe Coding mit der richtigen CI-Pipeline ist einfach: schnell entwickeln, ruhig schlafen.

Lust, selbst einen Blick auf unsere Pipeline zu werfen? Die komplette ci.yml liegt offen auf github.com/metadist/synaplan. Pull Requests willkommen.