Der Commit war gepusht. Der Build lief durch, grün, kein Fehler im Log. Vercel sagte „Ready". Und die Seite zeigte trotzdem die alte Version.
Ich hab an dieser Stelle schon mehr Lebenszeit verloren, als ich zugeben möchte. Also schreibe ich es auf — auch als Notiz an mich selbst für das nächste Mal, an dem ich wieder anfange, am Code zu zweifeln, obwohl der Code überhaupt nicht das Problem ist.
Der Reflex ist immer derselbe — und immer falsch
Eine Änderung kommt nicht live an, und der erste Gedanke ist: Hab ich was übersehen? Also liest man den eigenen Code nochmal. Dann die Env-Variablen. Dann baut man lokal, es funktioniert, man versteht die Welt nicht mehr.
Diesmal war es ein Footer-Hinweis, den ich auf einer Seite ergänzen wollte. Winzige Sache. Ich hab die Datei bearbeitet, committet, gepusht — und live tat sich nichts. Also der Reflex: nochmal die Datei anschauen. Stimmt doch alles. Nochmal committen. Nichts. Cache? Hard-Reload? Nichts.
Erst als ich aufgehört habe, meinen Code zu verdächtigen, wurde es klar. Es waren zwei Fehler gleichzeitig, völlig unabhängig voneinander — deshalb hat auch kein einzelner Versuch gewirkt. Man fixt den einen, der andere hält die alte Version weiter am Leben, und man denkt, der Fix war falsch.
Schicht eins: Die Datei, die ich bearbeitet habe, gab es gar nicht
Genauer: Es gab sie, aber sie war ein Bauprodukt. Das Projekt setzt seine Seiten aus Bausteinen zusammen — ein Skript nimmt kleine Teile, Kopf, Navigation, Fuß, und baut daraus die fertige Seite. Ich hatte die fertige Seite bearbeitet. Beim nächsten Build wurde sie aus den Bausteinen neu zusammengesetzt, und meine Änderung war weg. Überschrieben von der Maschine, die genau dafür da ist.
Bevor man eine Datei bearbeitet, lohnt eine Sekunde die Frage: Ist das hier das Original oder das Ergebnis? Ein Projekt mit einem Build-Schritt hat fast immer beides — und die Änderung gehört ins Original.
Also gut, Änderung in den richtigen Baustein, neu gebaut, committet, gepusht. Jetzt musste es ja klappen.
Tat es nicht.
Schicht zwei: Der Build war fertig. Die Domain wusste es nur nicht.
Das war der Moment, in dem ich fast wieder in den Code geschaut hätte. Stattdessen hab ich mir die Deployments angesehen — die Liste, nicht das Log. Und da standen sie: zwei frische Deployments, beide „Ready", beide erfolgreich. Der Build war nie das Problem gewesen.
Das Problem war, dass die Domain auf ein vier Stunden altesDeployment zeigte. Vercel hatte brav gebaut, hatte jedem neuen Stand eine eigene kryptische URL gegeben — aber die eigentliche Adresse, die Leute aufrufen, hing noch am alten Stand. Der Build wandert nicht automatisch auf die Domain. Das ist ein zweiter Schritt, und der war irgendwo hängengeblieben.
Ein Befehl, der die Domain auf das neue Deployment umhängt, und die Sache war erledigt. Sekunden. Nach — sagen wir — deutlich mehr als Sekunden Suche.
Die Checkliste, bevor ich wieder am Code zweifle
„Deployment erfolgreich" heißt nicht „live". Es heißt: gebaut. Ob die Domain das zeigt, ist eine völlig andere Frage — und genau die vergisst man, weil das grüne Häkchen so beruhigend aussieht.
Seitdem gehe ich, wenn eine Änderung nicht ankommt, erst den Weg durch, bevor ich den Editor überhaupt aufmache:
- Bearbeite ich die Quelle oder ein Bauprodukt? (Beim ersten Fehler heute die halbe Miete.)
- Lief der Build für diesen Commit — und ist er auch fertig?
- Zeigt die Domain wirklich auf das neueste Deployment, oder klebt sie am alten?
Erst wenn alle drei sitzen, ist der Code dran. Meistens ist es dann gar nicht der Code.