Vai al contenuto

Runbook: rollback Frontend

Quando usarlo

Usare questo runbook quando HTML, asset, metadata, redirect, 404 o shell Admin regrediscono mentre API e D1 restano autorevoli.

Prerequisiti

  • trigger Frontend isolato;
  • autorizzazione di rollback;
  • versione Frontend precedente registrata;
  • dominio e route ownership correnti noti;
  • API e D1 health verdi;
  • nessun cambio route, dominio o Access richiesto.

Procedura

  1. Fermare ogni altra mutazione.
  2. Registrare versione Frontend attuale e target.
  3. Ripristinare il target:
npx wrangler rollback <VERSIONE_FRONTEND_PRECEDENTE> \
  --env <AMBIENTE> \
  --config apps/frontend/wrangler.jsonc \
  --yes
  1. Attendere il risultato terminale.
  2. Verificare home, asset, sitemap, robots, redirect permanente e 404.
  3. Verificare challenge Access sulla shell Admin.
  4. Eseguire npm run smoke:cutover:rollback.
  5. Confermare che API e D1 non siano cambiati.

Verifiche attese

  • il dominio resta posseduto dal Frontend Worker;
  • l'HTML canonico torna disponibile;
  • il pacchetto resta statico e binding-free;
  • API health e D1 health restano verdi;
  • nessun fallback HTML legacy dell'API viene reintrodotto.

Condizioni di stop

Fermarsi se il target non è noto, il problema coinvolge API o D1, il routing è ambiguo, il rollback cambia trigger o dominio, oppure lo smoke non ripristina la baseline.

Rollback o recupero

Non distribuire l'API come compensazione. Se la baseline non torna verde, conservare lo stato fail-closed e aprire un Issue di recupero.

Evidenza da conservare

  • trigger;
  • versione Frontend fallita e target;
  • autorizzazione;
  • risultato Wrangler;
  • verifiche HTML, asset, metadata, redirect, 404 e Access;
  • conferma di API/D1 invariati;
  • rischio residuo.