Viele technische Teams haben Redaktion als Nachgedanken. Die Website entsteht aus internen Wiki-Einträgen, die irgendwann jemand überarbeitet. Blog-Posts werden zwischen Tür und Angel geschrieben. Feature-Ankündigungen warten, bis ein Engineer Zeit hat, sie in Formulare einzupflegen. Das Ergebnis: Inhalte erscheinen spät, sind uneinheitlich, und niemand hat klare Verantwortung.
Das Problem mit traditionellen CMS
Die klassische Antwort ist: "Installiert doch ein CMS." Wordpress, Contentful, Sanity — alle lösen das Publikations-Problem auf ihre Weise. Keine der Lösungen passt aber wirklich gut zu technischen Teams, die mit Git, IDE und Code-Review gewohnt sind zu arbeiten.
CMS-Oberflächen sind für Nicht-Techniker gebaut. Das ist gut für Redaktions-Teams ohne Technik-Hintergrund, aber es zwingt Engineering-Teams in eine fremde Arbeitsumgebung. Die Folge: Inhalte werden doppelt gepflegt (einmal im Wiki, einmal im CMS), oder der Publikations-Prozess wird komplett an Marketing ausgelagert.
Git-native Redaktion
Unsere Lösung — in drei Projekten erprobt — ist Git-native: Alle Inhalte (Blog-Posts, Landing-Pages, Produktbeschreibungen) leben als Markdown-Dateien in einem separaten content-Repository. Engineers pushen Änderungen wie Code. Redaktion arbeitet in der gleichen Oberfläche — aber wir haben einen schlanken Web-Editor gebaut, der Markdown im Hintergrund produziert.
Der Flow ist:
- Draft: Ein neuer Post entsteht entweder im Web-Editor oder direkt als Markdown-Datei. Status:
draft. - Review: Pull Request oder Share-Link. Redaktion + Fach-Owner prüfen. Feedback via Kommentar.
- Publish: Merge nach
main. CI triggert Rebuild, Inhalt geht live.
Jeder Schritt ist auditierbar. Jede Änderung ist reversibel. Jede Freigabe ist an einen Namen geknüpft.
Statuswerte, die zählen
Wir haben uns auf fünf Statuswerte geeinigt:
draft— in Arbeit, noch nicht reviewgereifreview— wartet auf Freigabescheduled— freigegeben, Veröffentlichung in der Zukunftpublished— livearchived— war mal live, wird nicht mehr angezeigt
Archivierung ist wichtig. Zu löschen ist zu destruktiv — URLs führen ins Leere, SEO-Juice verschwindet. Archivierte Posts bleiben unter ihrer URL erreichbar, werden aber aus Indexlisten ausgeblendet.
Der Rolle-Split
Wir haben klare Rollen definiert:
- Autor: erstellt und bearbeitet Drafts.
- Reviewer: gibt frei. Kann Autor sein, für einfache Fälle.
- Publisher: triggert Deploy (automatisch bei Merge).
- Owner: ist verantwortlich für den Lebenszyklus eines Posts. Bei uns meist der Fach-Experte.
Der Owner ist das wichtigste Rolle. Ohne klaren Owner veralten Posts schleichend. Mit Owner passiert das Review-Datum nicht unbemerkt — er bekommt ein Review-Reminder per Slack.
Tooling-Integration
Slack-Integration für Status-Changes ist gesetzt. Grafana-Dashboard zeigt uns: Wie viele Drafts sind älter als 30 Tage? Welche Posts warten länger als 7 Tage auf Review? Welche Posts sind über 12 Monate alt und reviewbedürftig?
Das Dashboard ist der stille Gewinn dieses Setups. Redaktion wird dadurch messbar.
Was wir mitgeben würden
Wer ein CMS abschaffen will, sollte zuerst den Flow klären. Wer ein Git-natives Setup einführen will, sollte zuerst die Redaktion einbinden. Der Tool-Wechsel ist die einfache Komponente — der schwere Teil ist, Rollen und Erwartungen neu zu verhandeln.