KI & Sicherheit

Deployment und CI/CD

Wie Merge, Review und automatische Deployments als Produktionsfreigabe behandelt werden können.

Stand: 2026-06-03

Kurzfassung

  • Merge in den Hauptbranch ist oft Produktionsfreigabe.
  • Direktes Pushen in den Hauptbranch bleibt verboten.
  • Deployment startet automatisch nach Merge durch CI.
  • Code-Rollback über Release-Folder ist gut abgesichert.
  • Datenbank- und Config-Änderungen brauchen eigene Rollback-Überlegung.
  • MRs brauchen sichtbare Deployment-Risiko-Markierung.
  • KI darf Deployment-Code vorbereiten, aber nicht direkt ändern, ausführen oder triggern.

Thema

Deployment und CI/CD bei Kundenprojekten, insbesondere bei automatischem Deployment nach Merge in den Hauptbranch.

Ausgangslage

Deployments laufen typischerweise so:

  • Merge Request in Hauptbranch,
  • direktes Pushen in den Hauptbranch ist nicht erlaubt,
  • nach Merge startet automatisches Deployment durch CI Action,
  • Deployment geht häufig direkt auf Produktion,
  • Mergen dürfen Projektleiter, Maintainer oder Lead.

Für Code-Deployments gibt es bereits ein starkes Muster:

  • neuer Release-Folder wird vorbereitet,
  • Tests laufen auf dem neuen Release-Folder,
  • Umschalten erfolgt erst, wenn Tests grün sind,
  • alter Release-Folder bleibt erhalten,
  • manueller Rollback auf alten Release-Folder ist möglich.

Die wichtigste praktische Erkenntnis:

Merge in den Hauptbranch ist Produktionsfreigabe.

Risiko in einem Satz

Wenn ein Merge automatisch Produktion deployt, können ungeprüfte CI/CD-Änderungen, Migrationen, Config-Änderungen oder KI-unterstützte Änderungen direkt produktive Systeme beeinflussen.

Empfehlung

Der Merge-Prozess muss als Produktionsfreigabe behandelt werden.

Das bedeutet:

  • Hauptbranch bleibt geschützt.
  • Merge in Hauptbranch braucht Review.
  • CI muss vor Merge grün sein.
  • Mergen bleibt auf Projektleiter, Maintainer oder Lead begrenzt.
  • Riskante Änderungen müssen im MR sichtbar markiert werden.
  • KI darf Deployment, CI/CD und Migrationen unterstützen, aber nicht autonom ändern, ausführen oder triggern.

MR-Risiko-Markierung

Wenn Merge direkt oder häufig Produktion auslöst, braucht jeder MR eine sichtbare Risiko-Markierung.

Empfohlenes MR-Template:

## Deployment-Risiko

- [ ] Datenbankmigration
- [ ] TYPO3 Extension-/Konfigurationsänderung
- [ ] CI/CD oder Deployment geändert
- [ ] Dependency-/Lockfile-Änderung
- [ ] Auth/Rechte/Security betroffen
- [ ] Config/Secrets/Environment betroffen
- [ ] Externe API/Integration betroffen
- [ ] Queues/Cronjobs/Worker betroffen
- [ ] Dateioperationen/Uploads betroffen
- [ ] KI-unterstützte Änderung
- [ ] Rollback bedacht

Ziel:

  • Reviewer sehen vor dem Merge, ob Deployment-Risiko vorhanden ist.
  • Maintainer/Lead können gezielt nachfragen.
  • Migrationen, Config und CI/CD laufen nicht nebenbei durch.

Migrationen und TYPO3-Konfiguration

Automatische Migrationen sind praktisch, aber kritisch.

Symfony:

  • Migrationsskripte können automatisch im Deployment laufen.

TYPO3:

  • Extension-Konfiguration, Schema, TCA, Upgrade Wizards, Scheduler oder Caches können produktives Verhalten verändern.

Kernregel:

Code-Rollback ersetzt keinen DB-Rollback.

P0-Regeln:

  • MRs mit Migrationen müssen markiert werden.
  • MRs mit TYPO3-Konfigurationsänderungen müssen markiert werden.
  • Migrationen brauchen Extra-Review.
  • Destruktive oder schwer rückgängig zu machende Migrationen brauchen separate Freigabe.
  • Backup/Snapshot- oder Wiederherstellungsweg muss bei riskanten Migrationen bedacht sein.
  • KI-generierte Migrationen dürfen nicht blind übernommen werden.

Review-Fragen:

  • Ist die Migration rückwärtskompatibel?
  • Gibt es Datenverlust?
  • Läuft sie mit vorhandenen Daten?
  • Kann sie robust mehrfach oder teilweise laufen?
  • Was passiert bei Fehler mitten in der Migration?
  • Gibt es Rollback, Backup oder Wiederherstellungsweg?
  • Muss erst Staging geprüft werden?

Staging und Testtiefe

Nicht jedes Deployment braucht Staging.

Aber Deployments mit erhöhtem Risiko sollen anders behandelt werden als normale Code-Deployments.

P0:

  • Migrationen und TYPO3-Konfigurationsänderungen markieren.
  • Destruktive DB-/Config-Änderungen extra freigeben.
  • KI-Migrationscode menschlich prüfen.

P1:

  • Für wichtige Projekte oder riskante Migrationen zuerst Staging.
  • Backup/Snapshot vor riskanten Migrationen prüfen.
  • Migrationen auf möglichst produktionsnahem Datenstand testen.
  • MR-Template mit Deployment-Risiko-Checkboxen einführen.

P2:

  • Automatische Hinweise prüfen, wenn migrations/, TYPO3 Config, CI/CD oder Lockfiles geändert sind.

Secrets und Deployment-Config

Secrets liegen nicht im Projekt. .env und Configs werden beim Deployment durch eigene Tools geschrieben.

Teilweise liegen Secrets serverseitig auf dem Deployment-Server, teilweise als GitHub/GitLab CI Secrets.

Das ist grundsätzlich besser als Secrets im Repository. Kritisch bleiben:

  • CI/CD Secret-Zugriffe,
  • Deployment-Tools,
  • .env-/Config-Schreiblogik,
  • Logs,
  • Änderungen an Deployment-Skripten.

P0-Regeln:

  • Keine Secrets im Repository.
  • Keine Secrets in KI-Kontext, Tickets, Logs oder MR-Beschreibungen.
  • Änderungen an Deployment-Tools und Config-Schreiblogik brauchen Extra-Review.
  • KI-Agenten dürfen keine Deploy-Secrets lesen, anzeigen oder verändern.
  • CI/CD darf Secrets nicht in Logs ausgeben.

Wandregel:

Deployment-Config ist Security-Code.

CI/CD und Deployment-Code

Eigene Deployment-Tools sind besser kontrollierbar als fremde Blackbox-Actions. Trotzdem sind Änderungen daran sicherheitsrelevant.

Deployment-Security-Dateien:

  • CI Workflow-Dateien,
  • Deploy-Skripte,
  • Config-Generierungslogik,
  • .env-Schreiblogik,
  • Docker-/Build-Konfiguration,
  • Migrationsausführung,
  • Release-Folder-/Symlink-Logik,
  • Smoke-Test-Konfiguration,
  • Rollback-Skripte.

P0-Regeln:

  • CI/CD- oder Deployment-Änderungen dürfen nicht ohne Review gemerged werden.
  • KI-generierte CI/CD-Änderungen brauchen menschliche Erklärung.
  • Merge in Hauptbranch bleibt Maintainer/Lead/Projektleiter-Freigabe.

P1-Regeln:

  • MR-Template einführen.
  • Risiko-Checkboxen verpflichtend machen.
  • Optional automatische Hinweise, wenn Deployment-Security-Dateien geändert sind.

Wandregel:

Deployment-Code ist Security-Code.

KI-Einsatz bei Deployment und Migrationen

KI darf helfen, aber nicht autonom handeln.

Erlaubt:

  • Deployment-/CI-/Migrationsänderungen vorschlagen,
  • Beispiele und Entwürfe liefern,
  • Migrationslogik erklären,
  • Risiken in MRs markieren,
  • Testideen liefern.

Nicht erlaubt:

  • CI/CD-Dateien direkt durch KI ändern lassen.
  • Deployment-Skripte direkt durch KI ändern lassen.
  • Release-/Rollback-Skripte direkt durch KI ändern lassen.
  • produktionsrelevante Migrationen blind übernehmen.
  • Deployments durch KI triggern.
  • produktive Migrationen autonom durch KI ausführen lassen.

Bedingung:

  • Ergebnis landet als normaler Code im MR.
  • Mensch prüft und versteht die Änderung.
  • MR markiert Deployment-/Migration-/Config-Risiko.
  • Tests laufen.
  • Staging, Backup oder Rollback werden je nach Risiko geprüft.

Wandregel:

KI darf Deployment-Code vorbereiten, aber nicht ausführen.

P0-No-Gos

  • Kein direkter Push in den Hauptbranch.
  • Kein Merge in Hauptbranch ohne Review.
  • Kein KI-Agent darf selbstständig mergen.
  • Kein KI-Agent darf Deployment auslösen.
  • Keine CI/CD- oder Deployment-Änderungen ohne Review.
  • Keine Migrationen ohne sichtbare MR-Markierung.
  • Keine destruktiven DB-/Config-Änderungen ohne Extra-Freigabe.
  • Keine Secrets in Repository, KI-Kontext, Tickets oder Logs.
  • Keine blind übernommenen KI-Migrationen.

Vorgeschlagene Wandregel

Merge in den Hauptbranch ist Produktionsfreigabe.

Alternative Kurzregeln:

Code-Rollback ersetzt keinen DB-Rollback.

Deployment-Code ist Security-Code.

KI darf Deployment-Code vorbereiten, aber nicht ausführen.

Teamfragen zur Entscheidung

  • Soll ein MR-Template mit Deployment-Risiko-Checkboxen eingeführt werden?
  • Welche Risikofelder sollen Pflicht im MR-Template sein?
  • Welche Änderungen brauchen Extra-Review durch Maintainer/Lead?
  • Wann ist Staging vor Produktion Pflicht?
  • Wann ist Backup/Snapshot vor Deployment Pflicht?
  • Wie werden destruktive Migrationen freigegeben?
  • Welche Dateien gelten als Deployment-Security-Dateien?
  • Wie wird verhindert, dass KI Deployment-Code direkt ändert?
  • Wer löst Rollback aus und wie wird das dokumentiert?