Vai al contenuto

Runbook: deployment standard in produzione

Quando usarlo

Usare questo runbook per una finestra di produzione che può comprendere, soltanto in fasi seriali e separatamente autorizzate, migrazione D1, deployment API e deployment Frontend.

Prerequisiti

  • Issue operativo di produzione con scope e stop condition completi;
  • SHA congelato di main e CI completa verde;
  • nessun run o operation concorrente;
  • inventory delle versioni API e Frontend precedenti;
  • elenco autorevole delle migrazioni pending;
  • baseline health, D1, Access, CORS e route ownership verde;
  • conferma che il Frontend è binding-free;
  • autorizzazione non ancora consumata.

Procedura

  1. Avviare Production operations con preflight e PREFLIGHT_ONLY.
  2. Conservare l'evidenza e fermarsi per il go/no-go successivo.
  3. Se servono migrazioni, eseguire il runbook D1; non proseguire su risultato non terminale o ambiguo.
  4. Ottenere autorizzazione API e avviare deploy-api-worker con DEPLOY_PRODUCTION_API_WORKER.
  5. Verificare API e D1 prima di qualsiasi operazione Frontend.
  6. Ottenere autorizzazione Frontend.
  7. Usare il percorso applicativo steady-state quando capability e azione server-owned sono disponibili; altrimenti seguire il runbook staging e attivazione previsto dall'Issue.
  8. Eseguire il runbook smoke limitato.
  9. Conservare evidenza terminale prima di chiudere la finestra.

Verifiche attese

  • ogni fase ha un run e un go/no-go distinti;
  • API, Frontend e D1 corrispondono alla revisione e alle migrazioni approvate;
  • il Frontend serve asset statici senza binding;
  • Access e CORS esatto proteggono l'Admin;
  • domini e route hanno un owner unico;
  • nessuna mutazione editoriale o Mailjet è avvenuta.

Condizioni di stop

Fermarsi su revision drift, CI incompleta, baseline non verde, migrazione inattesa, run concorrente, approvazione non autorevole, provider ambiguity, versione non dimostrata, smoke fallito o necessità di cambiare configurazione.

Rollback o recupero

Ripristinare soltanto il componente fallito con rollback API o rollback Frontend. Se D1 è coinvolto o la causa non è isolata, mantenere lo stato fail-closed e aprire un Issue di recupero.

Evidenza da conservare

  • SHA e CI;
  • baseline e target di rollback;
  • run separati di preflight, migrazione, API e Frontend;
  • versioni caricate e attivate;
  • storia migrazioni;
  • risultati health, D1, Access, CORS, route e static output;
  • eventuale rollback e rischio residuo.