Deployment und Freigabe

DiGeKo benötigt keine bestimmte Hostingplattform. App und CMS sind getrennte Node.js-Dienste und können auf einer VM, in Containern oder auf einer Application Platform betrieben werden.

Voraussetzungen für eine eigene Produktion

• zwei HTTPS-Adressen: eine für die öffentliche App und eine für das CMS
• Node.js 24 und pnpm für die App
• Node.js 20 bis 22 und npm für das CMS
• eine MySQL-Datenbank
• einen S3-kompatiblen Medienspeicher; lokaler Upload ist im NODE_ENV=production absichtlich gesperrt
• einen vollständig konfigurierten TTS-Anbieter
• persistente Backups von Datenbank und Medien

App bereitstellen

1. App-Repository klonen und den gewünschten Commit oder Tag auschecken.
2. mindestens NEXT_PUBLIC_CMS_URL und NEXT_PUBLIC_INFO_CATEGORY_DOCUMENT_ID setzen; Preview-Variablen nur bei Bedarf ergänzen. Bei aktivierter Vorschau muss APP_ORIGIN den öffentlichen Origin der App enthalten.
3. pnpm install --frozen-lockfile und pnpm build ausführen.
4. den Build mit pnpm start hinter einem HTTPS-Reverse-Proxy starten.

Öffentliche NEXT_PUBLIC_*-Werte werden in den Build eingebettet. Nach einer Änderung ist deshalb ein neuer App-Build erforderlich.

CMS bereitstellen

1. CMS-Repository klonen und den gewünschten Commit oder Tag auschecken.
2. Strapi-Secrets, MySQL, S3, Preview und TTS über Umgebungsvariablen konfigurieren.
3. npm ci, npm run build und anschließend npm run start ausführen.
4. optional den veröffentlichten Ausgangsdatenstand in eine frische Instanz importieren.
5. Healthcheck, CMS-Anmeldung, Preview, Medienupload, TTS und App-Abruf prüfen.

Docs bereitstellen

1. Docs-Repository klonen und den gewünschten Commit oder Tag auschecken.
2. NEXT_PUBLIC_DOCS_ENV und NEXT_PUBLIC_SITE_URL passend zur Zielumgebung setzen.
3. pnpm install --frozen-lockfile und pnpm build ausführen.
4. den Standalone-Build mit pnpm start hinter einem HTTPS-Reverse-Proxy starten.
5. direkten Seitenaufruf, Navigation, Suche und Robots-Metadaten prüfen.

Umgebungsvariablen nachschlagen →

Öffentlichen Datenexport importieren →

Versionen und Kompatibilität →

Projektbetrieb mit Coolify

Die offiziellen DiGeKo-Umgebungen werden derzeit durch Coolify aus den jeweiligen GitLab-Repositories gebaut. Die Docs-Ressourcen verwenden den Build Pack Nixpacks. Nixpacks erkennt die package.json-Scripts und erzeugt den Buildcontainer; ein Dockerfile im Repository ist dafür nicht erforderlich. Ein Wechsel zum Dockerfile-Build-Pack wäre eine bewusste, separate Betriebsentscheidung.

Konkrete Staging-Adressen, Deployment-Auslöser, Ressourcenkennungen, Konfigurationswerte und Eskalationskontakte stehen ausschließlich im internen Betriebshandbuch. Sie sind für Mitwirkende und für den Betrieb einer eigenen Installation nicht erforderlich.

GitLab CI prüft den Quellstand. Coolify steuert Build, Runtime-Variablen und Deployment der freigegebenen Branches.

Rollen

• Mitentwickler:innen liefern kleine, prüfbare Merge Requests, führen die relevanten Tests aus und dokumentieren Auswirkungen auf App, CMS und Docs.
• Maintainer:innen/Projektverantwortliche prüfen Merge Request und CI, nehmen das Ergebnis auf Staging ab, entscheiden über die Freigabe nach main, beobachten das Deployment und führen die nachgelagerte Smoke-Prüfung durch. Bei einem Fehler entscheiden sie über Abbruch, erneutes Deployment oder Rollback.

Konkrete Personen, Vertretungen und Kontaktwege werden nur im internen Betriebshandbuch gepflegt.

Reguläre Freigabe

1. Mitentwickler:innen stellen abgeschlossene Änderungen im Status Abnahme mit einem Merge Request nach dev bereit.
2. Maintainer:innen nehmen sie ab, mergen nach dev und verschieben die Issues nach Release.
3. App, CMS und Docs auf Staging bauen und die integrierten automatischen und manuellen Prüfungen durchführen.
4. Zum vorgesehenen Release-Zeitpunkt Merge Requests von dev nach main erstellen.
5. Bei gekoppelten Änderungen zuerst CMS, dann App, zuletzt Docs deployen.
6. Produktions-Smoke-Test durchführen und veröffentlichte Issues schließen.
7. Projekt-Release mit den tatsächlich eingesetzten Komponentenständen dokumentieren.

Das öffentliche Versionsmodell und die Auswahl gemeinsam getesteter Komponenten- und Datenstände stehen unter Versionen und Kompatibilität.

Docs werden zuletzt veröffentlicht, damit digeko.de keine noch nicht produktive Funktion beschreibt.

Zusammenspiel von App und CMS

App und CMS bilden je Zielumgebung ein festes Paar. Die App lädt veröffentlichte Inhalte aus dem über CMS_URL beziehungsweise NEXT_PUBLIC_CMS_URL zugeordneten CMS. Für die Vorschau verweist das CMS über PREVIEW_FRONTEND_URL zurück auf die zugehörige App. Der serverseitige APP_ORIGIN der App muss diesem öffentlichen Origin entsprechen. Konfigurationen von Staging und Produktion dürfen nicht miteinander gekreuzt werden.

Content- und API-Vertrag →

Content Preview und Sicherheitsgrenze →

Healthcheck und Smoke-Prüfung

Ein technischer Healthcheck prüft ohne Anmeldung, ob der jeweilige Prozess über HTTPS erreichbar ist und mit dem erwarteten erfolgreichen HTTP-Status oder einer vorgesehenen Weiterleitung antwortet. Er ersetzt keine fachliche Smoke-Prüfung.

Nach jedem Deployment werden mindestens diese Punkte geprüft:

Bei Änderungen an Medien, TTS, Datenmodell oder Deploymentkonfiguration werden die betroffenen Pfade zusätzlich geprüft. Wiederkehrende Laufzeitfehler in den Logs, fehlerhafte Abhängigkeiten oder nicht passende Komponentenstände machen das Deployment nicht freigabefähig.

Bei Änderungen am TTS-Zugriffsschutz wird außerdem geprüft, dass eine Admin-UI-Aktion mit passender Content-Manager-Berechtigung funktioniert und dieselbe Route ohne Admin-Session 401 sowie mit fehlender Berechtigung 403 liefert. Weder Reverse Proxy noch Netzwerksegmentierung dürfen dabei die anwendungsseitige Session- und RBAC-Prüfung ersetzen.

Branch-Schutz

main und dev werden gegen direkte Pushes und Force Push geschützt. Änderungen laufen über Merge Requests und benötigen eine grüne relevante CI. Produktion wird ausschließlich aus main, Staging ausschließlich aus dev gebaut.

Hotfix

Ein Produktions-Hotfix zweigt von main ab, wird nach Prüfung dorthin zurückgeführt und anschließend auch nach dev übernommen. Betroffene Dokumentation folgt demselben Weg.

Rollback

Ein Code-Rollback verwendet den letzten nachweislich funktionierenden Commit, Tag oder dokumentierten Release-Stand:

1. fehlerhaften Stand und beobachtete Auswirkungen festhalten;
2. letzten funktionierenden Stand mit unveränderter Zielkonfiguration erneut bauen und bereitstellen;
3. bei gekoppelten Änderungen die Reihenfolge CMS, App und zuletzt Docs beachten;
4. Healthcheck und Smoke-Prüfung vollständig wiederholen;
5. Korrektur anschließend wieder in die regulären Branches übernehmen.

Ein Code-Rollback setzt weder Inhalte noch Datenbank, Medien oder Konfigurationszustände zurück. Schema- und Datenänderungen benötigen deshalb vor der Freigabe einen getrennten Rückweg. Die konkrete Sicherung und Wiederherstellung der offiziellen Umgebungen ist Teil des internen Betriebshandbuchs und wird nicht öffentlich beschrieben.