Una sandbox popolata batte una copia della produzione

Nella vita di ogni piccolo team arriva il momento in cui qualcuno propone di far puntare lo sviluppo locale a una copia del database di produzione, perché i dati finti sembrano poveri e i bug veri capitano solo con i record veri. È un'idea allettante con una lunga scia di rimpianti: credenziali sparse sui portatili, nomi di clienti negli screenshot, un lavoro di invio email che un giorno trova indirizzi veri. Noi siamo andati dall'altra parte e non ci siamo mai voltati indietro.

Un Postgres intero dentro al processo

Le build di Postgres integrato sono diventate davvero buone. La nostra app decide all'avvio: se nell'ambiente ci sono credenziali vere di database, usa il database ospitato; se sono vuote, avvia un Postgres dentro al processo che vive in una cartella locale. Le macchine di sviluppo semplicemente non hanno mai le credenziali, quindi il peggio che può succedere a un portatile configurato male è un database vuoto e nuovo, non un incidente in produzione.

1// Choose the database at runtime. Blank env = embedded, local, harmless.2function makeDb() {3  const url = process.env.DATABASE_URL;4  if (url) return connectHosted(url);5  // In-process Postgres persisted to a local folder6  const client = new EmbeddedPostgres('./.pgdata');7  return drizzle(client, { schema });8}

Il percorso di ricostruzione conta quanto il motore. Ricreiamo il database locale applicando gli stessi file di migrazione che ha eseguito la produzione, in ordine, dal primo. Quella sola decisione ha intercettato gratis una famiglia di bug: una migrazione che dava per scontata una colonna di un file successivo, una modifica dello schema che funzionava su uno snapshot vecchio ma non partendo da zero. Se il portatile non riesce a costruire lo schema dalla storia, non ci riuscirebbe nemmeno il prossimo rilascio.

Popola un'attività, non delle righe

La differenza tra dati finti inutili e dati finti utili è il racconto. Il nostro script di popolamento non inserisce dieci utenti chiamati test. Crea un salone con un nome, staff con le proprie specialità, servizi con prezzi e durate onesti, clienti con uno storico di visite, appuntamenti in arrivo, prodotti da vendere con le loro giacenze e un registro dietro. Le pagine sembrano abitate, il che vuol dire che i bug di layout, gli stati vuoti e i troncamenti sgraziati si presentano come si presenterebbero a un cliente vero.

Quest'ultima proprietà è facile da sottovalutare. Ogni screenshot nella nostra documentazione, nel nostro blog e nelle nostre segnalazioni di bug viene dalla sandbox popolata. Nessuno deve strizzare gli occhi su un'immagine chiedendosi se sia sfuggito il nome di un cliente, perché non ci sono nomi di clienti che possano sfuggire. Il processo di oscuramento più sicuro è non avere niente da oscurare.

Cosa conviene fare bene

• Rendi il percorso sicuro il percorso predefinito. Gli sviluppatori devono fare uno sforzo per arrivare ai dati veri, non per evitarli.
• Neutralizza anche gli effetti collaterali: email, pagamenti e chiavi di archiviazione restano vuoti in locale, così un ciclo sui clienti di esempio non può mai scrivere a una persona vera.
• Popola gli stati che temi: l'account appena creato, la giornata al completo, il prodotto esaurito, il cliente con una sola visita di anni fa.
• Tieni lo script di popolamento nella revisione del codice. Quando una funzione aggiunge una tabella, lo script cresce con lei, altrimenti la sandbox marcisce in silenzio.

Il guadagno si somma nel tempo. Chi entra nel team lancia due comandi e si ritrova un'attività funzionante con cui giocare. Il controllo visivo può fotografare ogni pagina senza una revisione sulla privacy. E l'ambiente dimostrativo è sempre a cinque minuti dall'essere immacolato, perché immacolato è solo una ricostruzione più in là.

I dati di produzione rispondono alle domande. I dati di esempio ti lasciano farle in sicurezza.