FAQ su verifica del deployment e primo accesso a Emdash CMS
Controlli di accettazione pratici dopo il deployment, setup iniziale admin e diagnosi di stati di successo parziale.
Cosa verificare per primo dopo il deployment?
Sequenza di accettazione a tre livelli:
- Frontend raggiungibile: la homepage restituisce il contenuto atteso.
- Admin raggiungibile:
/_emdash/adminsi carica. - Dati scrivibili: creare e leggere un elemento di contenuto.
La sola raggiungibilità delle route non completa il deployment.
Perché il frontend può funzionare mentre l’inizializzazione admin fallisce?
Cause più comuni:
- mismatch dei binding (
DB,MEDIA, ecc.) - variabili d’ambiente o segreti mancanti
- config non supportata mantenuta per il piano Free
Ordine di triage consigliato: prima binding, poi variabili d’ambiente, poi vincoli del tier.
Cosa succede durante il primo accesso admin?
Tipicamente:
- creazione dell’identità admin
- registrazione delle credenziali (es. Passkey)
- scrittura dello stato iniziale del sistema
Questo passo dipende dal browser e dall’account. Completalo su rete stabile e browser supportato.
Cosa controllare per primo se la configurazione Passkey fallisce?
In quest’ordine:
- supporto browser e disponibilità Passkey
- accuratezza dell’orologio di sistema
- problemi cross-origin o header del reverse proxy
Non iniziare sospettando il database — la maggior parte dei fallimenti auth è legata al client o al proxy edge.
Cos’è uno script minimo di accettazione in produzione?
Flusso ripetibile:
- Aprire la homepage del frontend e registrare la risposta.
- Accedere all’admin e completare la configurazione iniziale.
- Creare e pubblicare un contenuto di test.
- Caricare un file media e verificarne il recupero.
- Confermare che il contenuto pubblicato sia visibile sul frontend.
Questo valida route, auth, scrittura, storage e lettura.
Il deployment sembra riuscito ma manca contenuto. Da dove iniziare?
Diagnostica più breve:
- L’elemento è pubblicato (non bozza)?
- Il frontend interroga la collection attesa?
- Controllare i log runtime per errori di query o permessi.
La maggior parte dei contenuti mancanti sono problemi di stato o percorso di query, non outage della piattaforma.
Come le squadre possono istituzionalizzare la qualità dell’accettazione?
Aggiungere al workflow di release:
- pre-merge: accettazione a tre livelli in locale o staging
- post-release: l’ingegnere di turno esegue lo script minimo entro 10 minuti
- post-incident: aggiungere un nuovo controllo deterministico per evitare ricorrenze
Lanci affidabili vengono dai controlli di processo, non dalla memoria tribale.
Snippet di comandi di verifica
# Esempi di controlli runtime
curl -I https://your-site.workers.dev
curl -I https://your-site.workers.dev/_emdash/admin
npx wrangler tail your-worker-name