Jede Version läuft die Website ab, bevor du es tust

Der Tag begann mit einem vollständigen Audit der Plattform. Die Startseite war schwerer, als sie aussah: Ihr automatisch startender Demofilm war eine 1080p-Datei mit 14 bis 20 MB pro Sprache. Neu kodiert in 720p wiegt die Seite nur noch etwa ein Sechstel, und der Film startet auf dem Handy schneller.

Derselbe Durchgang behob eine Reihe von Barrierefreiheitsproblemen auf neunzehn Seiten, von unterstrichenen Links im Fließtext bis zu Codeblöcken, die per Tastatur erreichbar sind. Dann kam die große Änderung des Tages: Die Website zog auf Next.js 16 um, das mit Turbopack baut und der Anfrageschicht einen neuen Namen und einen neuen Platz im Code gibt.

Jedes Release hatte schon eine Schranke. Sie wartete, bis der Health-Check der neuen Version antwortete: Der Container läuft, die Datenbank antwortet, die API funktioniert. Das ist nützlich und schnell geprüft, und es ist nicht das, was ein Besucher erlebt.

Ein Besucher fragt nach einer Seite. Bevor sie gezeichnet wird, wählt eine kleine Anfrageschicht die Sprache, schickt Abgemeldete vom Dashboard weg und versieht jede Antwort mit der Version, die sie erzeugt hat. Ein Health-Check kann komplett grün sein, während diese Schicht fehlt. Weil das Framework-Upgrade genau diese Schicht umbenannte, wollten wir, dass eine Version ohne echte Seiten gar nicht live gehen kann, nicht nur unwahrscheinlich.

Also macht die Schranke jetzt, was ein sorgfältiger Mensch nach einem Release tun würde: Sie öffnet die Website. Nach dem Health-Check ruft sie eine Handvoll echter Adressen auf und prüft jede Antwort.

• Startseite und Preisseite ohne Sprachpräfix müssen normal antworten.
• Die französische Start- und Preisseite ebenfalls, damit beide Wege durch die Sprachschicht bewiesen sind.
• Eine Adresse, die es nicht gibt, muss mit 404 antworten, damit eine Website, die zu allem Ja sagt, nicht durchkommt.
• Das Dashboard muss Abgemeldete weiterleiten, der Beweis, dass die Anfrageschicht läuft.

Eine Version, die die API bedient, aber keine Seiten, fällt durch, und der Traffic bleibt auf der Version davor. Niemand muss dafür etwas bemerken, und niemand muss nachts eingreifen.

Seiten abzulaufen überzeugt nur, wenn klar ist, welche Version geantwortet hat. Jede Antwort trägt einen Header mit dem exakten Commit, der sie gebaut hat, und die Schranke verlangt diesen Commit auf jeder geprüften Seite. Eine ältere Version oder eine Kopie aus dem Cache kann nicht an Stelle der neuen durchgehen.

Am selben Tag änderte sich auch die Reihenfolge. Tests und Release starteten bisher bei jeder Änderung nebeneinander, ein roter Test konnte ein Release also nicht stoppen. Jetzt beginnt ein Release erst, wenn die ganze Testsuite bestanden ist, und es baut genau den getesteten Commit. Noch vor jedem Deployment startet der Testlauf die gebaute Website und macht denselben Rundgang.

Zusammen genommen muss eine neue PageToVid-Version vier Stufen nehmen, bevor sie dich erreicht:

1. 1die ganze Testsuite besteht auf genau diesem Commit
2. 2die gebaute Website startet und besteht den Seitenrundgang im Test
3. 3die ausgerollte Version beantwortet ihren Health-Check
4. 4die ausgerollte Version liefert echte Seiten in zwei Sprachen, eine echte 404 und eine funktionierende Weiterleitung, jede mit ihrem Commit gestempelt

Das Prinzip dahinter ist einfach und leitet jetzt jede neue Prüfung: Teste, was der Mensch sieht, nicht nur, was die Maschine meldet. Ein Health-Check sagt, dass der Server lebt. Nur eine Seite sagt, dass das Produkt funktioniert. So bleibt ein Release eine ruhige Sache, selbst an einem Tag mit einem großen Framework-Wechsel. Weitere Kapitel aus dem Aufbau der Plattform findest du im Blog.