Vai al contenuto

Runbook: deployment standard in sviluppo

Quando usarlo

Usare questo runbook per distribuire una revisione già unita a main nel Frontend Worker o nell'API Worker di sviluppo. Una migrazione D1, se necessaria, rimane un'operazione separata.

Prerequisiti

  • Issue operativo esplicito e go/no-go di Fra;
  • SHA esatto di main con CI completa riuscita;
  • nessun run development-operations o deployment applicativo attivo;
  • target di rollback del componente selezionato;
  • configurazione Access e route già verificate;
  • elenco delle migrazioni pending già classificato.

Procedura

  1. Eseguire localmente npm run check:development:operations.
  2. Avviare Development operations con preflight e PREFLIGHT_DEVELOPMENT_ONLY.
  3. Confrontare checkout, SHA e dry-run con l'Issue.
  4. Se esistono migrazioni autorizzate, fermarsi e usare il runbook D1.
  5. Ottenere un nuovo go/no-go per un solo componente.
  6. Per l'API selezionare deploy-api-worker con DEPLOY_DEVELOPMENT_API_WORKER.
  7. Per il Frontend selezionare deploy-frontend-worker con DEPLOY_DEVELOPMENT_FRONTEND_WORKER.
  8. Attendere il risultato terminale; non avviare l'altro deployment.
  9. Eseguire il runbook smoke limitato.

Verifiche attese

  • il run usa refs/heads/main e il GitHub Environment development;
  • la versione servita corrisponde allo SHA approvato;
  • /health, /version e /db/health passano per un deployment API;
  • HTML, asset, 404, Access e route ownership passano per il Frontend;
  • API, D1 e Frontend non selezionati restano invariati.

Condizioni di stop

Fermarsi su CI incompleta, SHA diverso, migrazione inattesa, workflow concorrente, configurazione non conforme, run ambiguo, versione non dimostrata, health fallito, Access/CORS regressi o ownership delle route non univoca.

Rollback o recupero

Con autorizzazione già prevista o con un nuovo go/no-go, usare soltanto rollback API o rollback Frontend. Una migrazione fallita non autorizza un deployment o un rollback Worker.

Evidenza da conservare

  • Issue e autorizzazione;
  • SHA, run CI e run operativo;
  • operation e conferma selezionate;
  • versione precedente e nuova del solo componente;
  • risultati smoke;
  • conferma degli elementi rimasti invariati;
  • rollback usato o non usato e rischio residuo.