11. Oktober 2026

Neues Neues Website!

Vierzehn Jahre sind seit dem früheren Post „Nyt website!” (siehe hier) vergangen, in dem WordPress den CMS-Wettbewerb gewann. Es lief — aber ein CMS mit PHP-Backend und Datenbank ist eben auch viel, in dem Fehler oder Schwachstellen sein können — und es braucht Wartung, selbst wenn sich nichts tut.

Also ist die Website 2026 von Grund auf neu aufgebaut worden, und die neue Grundlage ist flach: gitservice.dk ist jetzt eine statische Website, in der eine Seite einfach eine gewöhnliche HTML-Datei ist, die der Webserver ausliefert. Es gibt kein PHP, keine Datenbank und keine Plugins — der Server (Apache) liefert schlicht die Datei. Die Website ist schnell, weil schlicht weniger vorhanden ist, in dem Fehler sein können.

Der gesamte Inhalt liegt als reiner Text in Git auf unserem eigenen Forgejo-Server: die Artikel werden als Markdown geschrieben, die Seiten als strukturierter Text pro Sprache. Astro, ein Web-Framework, das alles zu statischen Dateien kompiliert, sammelt das in einem fertigen dist/-Ordner mit HTML, CSS und den JavaScript-Stücken, die die Seiten tatsächlich verwenden. Die Website ist das, was sie zu sein scheint: keine versteckten Ebenen, keine Überraschungen.

Die Veröffentlichung ist ebenso wichtig richtig zu bauen wie der Inhalt. Die neue Pipeline besteht aus vier getrennten Handlungen, jede für sich rückgängig machbar, damit „Kode aktualisieren” nie mit „Ändern, was die Öffentlichkeit sieht” verwechselt wird:

1. Build — Typ- und Build-Check des Codes, gefolgt von einer lokalen Vorschau, in der das Ergebnis verifiziert wird.
2. Release — ein Versionstag (UTC-Datum, z. B. v2026.10.12) wird aus einem sauberen, verifizierten main geschnitten. Das Tag ist das, was wir veröffentlichen.
3. Deploy — der getaggte Commit wird gebaut, und dist/ wird rollierend erst auf den einen Stack (A), dann auf den anderen (B) kopiert. Zeitgleich ist höchstens einer der beiden außer Betrieb — und bei einer unterbrochenen Kopie liefert der Stack einfach die alte Version weiter.
4. Cutover — einmalig: Beide Stacks treten in den Pool des Lastausgleichs ein, wird WordPress zum automatischen Backup, und die gesunden Stacks nehmen den Traffic.

Die Regel ist kurz: Wir deployen nie etwas, das nicht released wurde, und wir release nie etwas, das nicht verifiziert wurde. Wenn es schiefgeht, ist die Lösung einfach: Das vorherige Tag wird rollierend neu deployed — oder gar nichts: WordPress bleibt als Backup im Pool und springt ein, sobald ein Stack den Health-Check nicht mehr besteht.

WordPress war gut. Aber es ist auch alt geworden — und wenn so etwas das nächste Mal passiert, darf der Plan nicht „noch ein Plugin” sein. Es soll eine neue Grundlage, eine neue Pipeline und (wieder) ein neuer „Nyt website!“-Post sein.