Statiske sites forbliver oppe, mens de udrulles igen

Når man udrullede et statisk site igen på Mythex, slettede vi tidligere de live filer, før vi uploadede det nye build. I uploadens varighed fik nogle besøgende en 404-side eller en side, hvis scripts manglede. En mislykket upload kunne efterlade sitet tomt eller halvt nyt. Nu skrives det nye build oven på det gamle, sider sidst, og rester fjernes nogle minutter senere. En anden rettelse gør, at en ny udrulning vises på få sekunder i stedet for et minut — eller, for filer som et logo, op til en dag.

Sådan serveres et statisk site

Et statisk site er bare filer: HTML-sider, JavaScript, CSS, billeder. Når du publicerer et på Mythex, bygger vi det, uploader output til objektlagring i en mappe for dit site og serverer det via et edge-netværk — servere tæt på dine besøgende, der henter filer fra lageret og gemmer kopier af dem en stund. (Hvis det er nyt for dig, dækker vores guide om hvad et CDN er ideen.)

To ting var galt: rækkefølgen, hvori en udrulning ændrede filerne, og hvor længe gamle kopier blev gemt.

Problem 1: uploaden tømte sitet først

En udrulning slettede alt i sitets mappe og uploadede derefter det nye build. Så længe uploaden tog — 12 sekunder for et site med 250 filer i vores lokale test — fik en besøgende, hvis forespørgsel ikke allerede var cachet ved edge'en, en 404, eller en HTML-side, hvis scripts gav 404.

En mislykket upload var værre. Mappen var allerede tom, og på en af de to uploadveje kunne den nye index.html lande, før filen, der fejlede. En udrulning, der blev rapporteret som mislykket, kunne efterlade et halvt nyt site live.

Rettelsen: skriv oven på, sider sidst, ryd op senere

1. Slet ikke først. Det nye build uploades oven på det gamle.
2. Assets før sider. En side nævner de scripts og styles, den har brug for, så sider uploades til sidst. Indtil de nye sider lander, får besøgende den gamle side, som nævner de gamle assets, og de ligger der stadig. Når de lander, er de nye assets, de nævner, allerede på plads.
3. Fjern rester senere. Før uploaden lister vi, hvad sitet består af. Tre minutter efter en vellykket upload slettes alt på listen, som det nye build ikke omskrev. Tre minutter er længere end de 60 sekunder, en side kan være cachet ved edge'en og i browseren, så en besøgende, der stadig har den gamle side, kan finde de assets, den nævner.
4. Er du i tvivl, så slet intet. Hvis listningen før uploaden fejler, ryddes der intet op. Overskydende filer er ufarlige, og næste udrulning fjerner dem. At slette uden at vide, hvad der var der, er sådan et site ender tomt.

En mislykket upload efterlader nu det forrige site præcis, som det var.

Vi testede det end-to-end lokalt med det rigtige upload-script, den rigtige upload-route og den rigtige lagringsservering, og med besøgende, der ankom med en kold edge-cache. Med den gamle kode var 55 af 91 besøg ødelagt under en udrulning og 61 af 92 under en mislykket. Med den nye kode var 0 ødelagt på tværs af omkring 3.500 besøg, der dækkede begge uploadveje, en mislykket upload og udrulningen efter den — og præcis de rester, der skulle, blev ryddet op.

Problem 2: en udrulning tog for lang tid om at blive vist

Selv når uploaden gik fint, var ændringer langsomme til at dukke op. Edge'en holdt sin kopi af en side i 60 sekunder og af alle andre filer i en dag, og fortalte browsere at gøre det samme. Filer med et fast navn — logo.png, en skrifttype, alt fra en public/-mappe — kunne vise den gamle version i op til en dag efter en udrulning.

Rettelsen: filkopier under build'et

Når edge'en spørger vores API, hvor et site ligger, inkluderer svaret nu en build-markør, som ændrer sig, hver gang en publicering lander. Edge'en gemmer sine kopier under den markør. En publicering bliver derfor til et helt nyt sæt cache-nøgler, så snart edge'ens 30-sekunders opslag udløber. Gamle kopier bliver simpelthen aldrig fundet igen, så edge'en kan beholde kopier i en dag uden nogensinde at servere en, der er forældet i forhold til den publicering, der erstattede den.

Browsere får to forskellige regler:

• Hashet build-output — filer som assets/index-CzLcxDO8.js, hvis navn ændrer sig, når indholdet gør — caches i et år og markeres immutable. Under det navn kan den aldrig være forældet.
• Alt andet — sider og filer med fast navn som et logo — markeres no-cache, hvilket betyder "tjek før brug". Hvis intet er ændret, er svaret et lille 304 Not Modified uden krop, nu hvor vi respekterer browserens If-None-Match-tjek.

At skelne de to kræver omhu: en fil kopieret fra public/assets/ beholder sit eget navn, og at cache'e assets/logo.png i et år ville fastlåse det gamle logo i et år. Så en fil tæller kun som hashet, hvis den ligger i en build-output-mappe og dens navn har et segment, der ligner et hash, ikke et almindeligt ord.

Lokalt var den nye side og logoet synlige 6 sekunder efter, at publiceringen gik live. Før var det 60 sekunder for siden og en dag for logoet.

To mindre rettelser undervejs

• Tomme sider fra HEAD-forespørgsler. En HEAD-forespørgsel beder om en sides headers uden krop. Vi cachede de tomme svar, så næste besøgende på siden fik en tom side. HEAD-svar caches ikke længere.
• En rigtig side for "intet her". En adresse uden app fik tidligere en ren tekst-besked, "This published app is offline or the link was not found", med en 502-fejlkode. Den får nu en ordentlig side, "There's no app here", med en 404-status og en vej tilbage til Mythex for ejeren. Ukendte custom domains får den samme side.

Det vi tog med

• Rækkefølge er en del af korrekthed. De samme filer uploadet i en anden rækkefølge er forskellen mellem et ødelagt og et fungerende site.
• Slet sent, og kun det du ved. At rydde op med en listing taget før uploaden er sikkert; at tømme en mappe og håbe på, at uploaden bliver færdig, er det ikke.
• Cache efter version, ikke efter tid. Udløbstider er et gæt på, hvornår indhold ændrer sig. En nøgle, der ændrer sig med build'et, er et faktum.

Relateret: din publicerede app forbliver oppe, mens du udruller den igen. Mere om publicering i dokumentationen.