Runbook: staging e attivazione Frontend
Quando usarlo
Usare questo runbook quando l'Issue richiede di caricare una versione Frontend senza traffico e attivarla soltanto dopo una verifica separata. Il percorso steady-state dall'Admin può invece caricare e attivare nello stesso workflow dopo l'approvazione applicativa.
Prerequisiti
- SHA esatto e build Frontend deterministica;
- origine API corretta per l'ambiente;
- target Frontend precedente registrato;
- pacchetto statico validato e privo di binding o marker sensibili;
- autorizzazioni distinte per staging e attivazione;
- API e D1 baseline verdi.
Procedura
- Eseguire
npm run check:production. - Avviare
stage-frontend-versionconSTAGE_PRODUCTION_FRONTEND_VERSION. - Registrare la versione caricata e verificare che non riceva traffico.
- Confrontare tag, SHA e metadati dell'artefatto.
- Ottenere il go/no-go separato per l'attivazione.
- Attivare l'esatta versione registrata:
npm run activate:frontend:production -- \
--version-id <VERSIONE_FRONTEND_CARICATA> \
--percentage 100 \
--yes
- Non modificare trigger o domini.
- Eseguire il runbook smoke limitato.
Verifiche attese
- staging terminale senza variazione di traffico;
- attivazione al cento per cento della sola versione approvata;
- dominio Frontend invariato;
- HTML, asset, sitemap, robots, redirect e 404 conformi;
- API, D1, Access e CORS ancora verdi;
- Frontend sempre binding-free.
Condizioni di stop
Fermarsi se la versione caricata non è univoca, il tag non corrisponde allo SHA, lo staging cambia traffico, l'attivazione seleziona una versione diversa, il pacchetto contiene binding o lo smoke fallisce.
Rollback o recupero
Usare il rollback Frontend verso il target registrato. Non distribuire l'API, migrare D1 o cambiare routing durante il recupero.
Evidenza da conservare
- SHA, build e origine API;
- run di staging;
- versione caricata e percentuale prima dell'attivazione;
- autorizzazione di attivazione;
- deployment/versione attiva;
- risultati smoke;
- eventuale rollback.