Vai al contenuto

Deployment e operazioni

La piattaforma promuove D1, API Worker ed Editorial MCP Worker attraverso un percorso lineare e verificabile. ADR-037 stabilisce che i file Wrangler canonici del repository sono l'unica configurazione deployable dei Worker.

ADR-030 assegna invece il public site ad Astro su Vercel: il deployment frontend è separato dal lifecycle editoriale e non viene attivato da publish/unpublish.

  • CI valida repository, migration append-only, workflow e codice; non distribuisce Worker e non muta D1 remoto.
  • Un push su main con CI verde alimenta automaticamente la release Development.
  • Development può anche essere rieseguito tramite workflow_dispatch senza parametri sul current main.
  • Production richiede un workflow_dispatch esplicito e senza parametri su main; il workflow congela il candidate e richiede CI verde più una release Development verde sullo stesso commit.
  • Il normale ordine di release è D1 → API → smoke API/D1 → MCP → smoke MCP.
  • Le migration D1 sono append-only. Il normale apply usa Wrangler nativo; dopo un failure è ammessa una sola riconciliazione autorevole e nessun blind retry.
  • wrangler.jsonc è la configurazione deployable canonica dell'API Worker. apps/mcp/wrangler.jsonc è la configurazione deployable canonica dell'Editorial MCP Worker.
  • Variabili applicative operator-managed e secret runtime restano autorità Cloudflare. Modifiche ordinarie e rotazioni sono operazioni dirette dell'operatore, non release e non gate Project.
  • Il solo step smoke API può riusare, tramite la coppia cifrata dello stesso ambiente, l'identità Public Site Access per il contratto public-content protetto.

Una release ordinaria non richiede una seconda Issue operativa, uno stato Project aggiuntivo o micro-conferme: l'intento esplicito Production di Fra e lo scope delivery già revisionato sono sufficienti.

Lo stesso vale per un bug Production confermato quando il recupero usa soltanto il normale percorso Worker reversibile.

Una Issue operativa separata resta necessaria quando il recupero aggiunge migration D1/data straordinarie, Access/security, Queue topology/configuration, azioni distruttive, mutazioni di provider esterni oltre la release ordinaria o stato ambiguo che richiede recovery revisionata separatamente.

Configurazione runtime e secret rotation seguono invece il percorso diretto descritto in configurazione runtime e operazioni.

Leggere topologia, sviluppo, produzione, migrazioni D1 e rollback. Per il percorso publish → public site leggere il contratto architetturale.