Production playbook

Usa questa checklist quando un'app passa da esperimento a qualcosa su cui le persone contano ogni giorno. I mattoni sono Snapshot e Deployment.

Topologia consigliata

App	Ruolo
Development	Qui sviluppi l'app o qualsiasi nuova modifica, con dati fittizi.
Staging	Qui fai provare agli utenti finali le modifiche strutturali, le nuove pagine, le Task; dati campione o anonimizzati.
Production	Utenti reali e dati reali.

Change management

Per ogni modifica non banale:

1. Implementa e testa su staging.
2. Opzionalmente fai uno Snapshot di staging quando la versione è "buona".
3. Su production, apri Deployments → scegli staging (live o Snapshot) → supera la compatibilità → avvia con un summary chiaro.
4. Fai smoke test su production (login, una creazione, un aggiornamento, un percorso e-mail se sicuro).
5. Se qualcosa non va, usa lo Snapshot automatico pre-deploy di production come punto di partenza per il recovery (il ripristino crea una nuova app — pianifica la capacità).

Non fare "click a caso" su rename strutturali solo su production senza uno Snapshot prima.

Cadenza backup

Quando	Cosa
Prima di import, redesign, Task batch massive	Snapshot manuale (struttura + dati)
Prima di ogni deployment in production	Snapshot automatico del target (da Deployments)
Periodico (es. settimanale) su app critiche	Snapshot manuale per drill di disaster recovery

Gli Snapshot solo struttura sono più leggeri quando ti serve solo il blueprint.

Modifiche schema sicure con dati live

• Preferisci modifiche additive (nuovi campi, nuove pagine) rispetto a rename/eliminazioni quando gli utenti sono online.
• Migra i dati con griglie, Task batch o import — poi rimuovi i campi obsoleti.
• Disabilita i campi automatici durante riscritture enormi; ricalcola dopo.
• Cambiare le etichette delle opzioni Choice può rompere filtri e condizioni Task — aggiorna le automazioni nello stesso rilascio.
• Testa le login rule dopo qualsiasi modifica agli oggetti utente.

Sicurezza e-mail

• Le app ripristinate / clonate partono con l'e-mail in uscita disabilitata — lasciala così sulle copie non di production.
• Punta i template di staging a caselle interne quando abiliti la posta per i test.

Lista breve go-live

• Staging approvato
• Deployment in production completato e rivisto nella cronologia
• Custom domain / DNS verificati (se applicabile)
• Monitoraggio: invia una transazione reale end-to-end
• Owner rollback identificato

Consegna partner e agenzia

Agenzie e freelancer spesso costruiscono app Bobuild per i clienti. Questi pattern mantengono chiara la proprietà dopo il handoff.

Modello di consegna

Fase	Dove	Chi
Build	App staging nell'account partner o cliente	Collaborator partner
Accept	Staging con dati campione realistici	Operator cliente
Go-live	Production via deployment	Partner + owner cliente
Run	Portali production	Operator cliente; partner in retainer se concordato

Preferisci costruire nell'organizzazione Bobuild del cliente quando gestirà fatturazione e dati a lungo termine. Se costruisci nel tuo account, pianifica export/handoff (Snapshot + trasferimento collaborator) con il supporto Bobuild se serve.

Igiene multi-cliente

• Un'app (o coppia staging+prod) per cliente — non mescolare dati cliente.
• Naming chiaro: clientname-staging, clientname-prod.
• Account Operator separati per cliente; non riusare mai password tra progetti.
• Documenta quali custom domain e mittenti e-mail appartengono a quale cliente.

Handoff branding

• Logo, colori, footer via Customize
• Lingua e fuso orario in Settings
• Snippet embed per il sito WordPress/marketing del cliente (Embedding)
• Lascia una breve pagina Rich Text "Brand notes" su un portale solo staff per il prossimo designer

Checklist handoff

• L'utente cliente è un collaborator Builder (owner) e capisce il rischio delle modifiche strutturali
• Accesso partner ridotto a ciò che serve il retainer
• Percorso deployment production dimostrato una volta
• Snapshot etichettato handoff effettuato
• E-mail in uscita e proprietà dominio confermate sotto il cliente
• Operator formati sui portali live
• Token API ruotati se il partner ne ha creati temporanei
• Elenco scritto delle funzionalità gated (schedule, SPID, …) e chi contattare in Bobuild

Correlati

• Troubleshooting — quando deploy o posta si comportano male
• Panoramica sulla sicurezza
• Integrazioni