Vai al contenuto

Deployment standard in sviluppo

Quando usarlo

Per comprendere o verificare il release automatico successivo a un merge su main.

Prerequisiti

PR validata, squash merge Fra, Environment development e credenziali di deployment Cloudflare.

Procedura

  1. Il push su main avvia CI, che congela e valida l'exact SHA senza autorità di deployment.
  2. Solo una CI success originata da un push same-repository su main avvia la release automatica sul proprio immutabile head_sha; failure, cancellazione, PR, branch differenti e dispatch CI non autorizzano alcuna mutazione.
  3. Il workflow riusa l'evidenza CI exact-SHA senza rieseguire release pack, manifest/immutabilità, test, typecheck, build, dry-run, docs, Brain o version checks. Se previsto dall'Issue mergiata, l'intento Rilascia in development. può osservare o riprendere solo l'exact head corrente con CI push verde.
  4. Confronta la topologia Queue Development candidata con l'ultimo release Development riuscito. Se cambia, la promozione automatica si ferma prima dell'Environment: serve un dispatch manuale sull'exact SHA con authorize_queue_topology_change: true entro una Issue che governa quella variazione. Il booleano non autorizza altre mutazioni o altri ambienti.
  5. Solo dopo il gate entra nell'Environment development, legge il ledger e richiede che sia un prefisso esatto.
  6. none non muta D1; expand applica il delta esatto e rilegge il ledger; extraordinary-blocked si ferma prima della mutazione.
  7. Distribuisce API, esegue smoke API/D1, distribuisce MCP e ne verifica readiness/version.
  8. Registra un'unica evidenza sanificata per ogni fase.

Queue Campaign Draft ritirata

La Queue email-campaign-draft, il producer binding e il consumer API non sono più superfici del runtime target. prepare, content_upload e schedule restano operazioni esplicite e sincrone del Campaign Draft; publish non chiama Mailjet e non accoda lavoro email. I validator di configurazione Development e Production ne rifiutano la reintroduzione.

La rimozione provider avviene separatamente per Development e Production dopo readback autorevole di backlog, retention, operazioni e ownership. Non eseguire purge. Se un esito è ambiguo, fermarsi senza retry cieco. Un rollback verso un Worker legacy richiede prima di ricreare e verificare Queue, binding producer e consumer con gli esatti parametri congelati; solo dopo può essere riattivata la versione Worker precedente.

Non creare un secondo percorso manuale di deployment.

Confine Public Content dopo #380

ADR-030 ha rimosso dal target il rebuild event-driven. Publish e unpublish non provocano build frontend; ADR-032 assegna ad Astro su Vercel letture REST server-side protette da Cloudflare Access, con rendering on-demand e ISR bounded. /public/v1/*, catalogo/snapshot globale, public_content.changed, producer Queue, recovery amministrativa e resolver interno non fanno più parte del runtime applicativo.

check-development-configuration.mjs e check-production-configuration.mjs rifiutano la reintroduzione del binding PUBLIC_CONTENT_CHANGE_QUEUE, delle Queue delivery-only, di Service Binding Coordinator e di variabili candidate-specific. Publish e unpublish aggiornano soltanto lo stato editoriale canonico in D1.

Le righe outbox D1 storiche sono terminali e inerti; la tabella e la colonna di revisione non sono lette o scritte dal codice. Le Queue provider esistenti e un'eventuale contrazione fisica D1 non si gestiscono da questo runbook: servono una Issue operativa separata, preflight esatto, ordine compatibile e rollback. Non configurare consumer Coordinator, fallback diretti o nuove operazioni di delivery frontend.

Verifiche attese

SHA, manifest, ledger, health, versione, API e MCP sono coerenti.

Condizioni di stop

Ambiente, SHA, release pack, credenziali, binding, Queue, migrazioni, rollback target, drift o smoke ambigui.

Rollback o recupero

Usare soltanto il rollback bounded definito dall'Issue per il componente coinvolto; se manca o lo stato è ambiguo, fermarsi senza migrare D1 come recupero implicito.

Evidenza da conservare

Commit, workflow, controlli, componenti ed esito redatti.