Przez trzy tygodnie moja własna strona mnie okłamywała

Zawodowo buduję systemy, które umieją powiedzieć człowiekowi, że coś poszło nie tak.

Moja własna strona przez trzy tygodnie serwowała wersję sprzed dwóch commitów, a ja nie miałem o tym pojęcia.

Przebieg wydarzeń. 6 sierpnia wypchnąłem dwie zmiany na podstronie. Ruszyły trzy wdrożenia. Wszystkie trzy padły. Każde zapisało czas builda równy zeru milisekund i komunikat „Page build failed." Bez szczegółów, bez powiadomienia, nic w skrzynce.

Zero milisekund znaczy, że build nawet nie wystartował, więc nie chodziło o mój kod. Położyło się coś wyżej.

A strona? Strona miała się świetnie. HTTP 200, ważny certyfikat, wszystko się ładuje. Bo dalej szedł ostatni udany build, dokładnie tak jak dzień wcześniej. Awaria nie miała żadnej widocznej powierzchni. Z zewnątrz, z mojej przeglądarki, z czyjejkolwiek innej — zdrowa strona.

Znalazłem to tylko dlatego, że dłubałem przy czymś zupełnie niezwiązanym i z ciekawości zajrzałem w status wdrożeń.

Nieprzyjemna analogia

To dokładnie ten sposób psucia się, przed którym całymi dniami stawiam bramki. Przyszedł tylko od strony, której nie broniłem.

Agent melduje sukces. Testy przechodzą. Diff wygląda czysto. Wszystko na powierzchni mówi, że robota zrobiona, a jedyny sposób, żeby się przekonać inaczej, to sprawdzić coś, nad czym meldujący nie ma władzy: uruchomić prawdziwą aplikację, odpytać prawdziwy stan, porównać z czymś, czego optymalizujący nie dosięgnie.

Wobec agentów miałem ten odruch. Wobec własnego pipeline'u wdrożeniowego już nie, a on przez dwadzieścia jeden dni po cichu serwował nieświeżą treść.

Naprawa, nawiasem mówiąc, polegała na usuwaniu, nie na dokładaniu. Strona to czysty HTML, a mimo to każde wdrożenie przepuszczało ją przez silnik szablonów, którego nigdy nie potrzebowała: 165 sekund na opublikowanie pół megabajta. Jeden pusty plik później wdrożenie jest zwykłym kopiowaniem plików i trwa 19 sekund. Dziewięć dziesiątych czasu szło na krok, którego jedynym realnym wkładem była zdolność do popsucia się.