En sandkasse med såddata slår en kopi av produksjon
Hele det lokale miljøet vårt er en Postgres som kjører i selve prosessen, starter tom, kjører de ekte migrasjonene og fyller seg selv med en overbevisende oppdiktet salong. Ingen produksjonsnøkler på laptoper, ingen ekte kundedata i skjermbilder, og en demo som aldri blir gammel.
Det kommer et øyeblikk i ethvert lite teams liv der noen foreslår å peke lokal utvikling mot en kopi av produksjonsdatabasen, fordi de oppdiktede dataene føles tynne og de ekte feilene bare skjer med ekte oppføringer. Det er en fristende idé med en lang hale av anger: nøkler spredt utover laptoper, kundenavn i skjermbilder, en testjobb for e-post som en dag finner ekte adresser. Vi gikk den andre veien og har aldri sett oss tilbake.
En hel Postgres inne i prosessen
Innebygde Postgres-bygg har blitt genuint gode. Appen vår bestemmer ved oppstart: finnes det ekte databasenøkler i miljøet, brukes den hostede databasen, er de tomme, startes en Postgres i prosessen som bor i en lokal mappe. Utviklingsmaskiner har rett og slett aldri nøklene, så det verste som kan skje med en feilkonfigurert laptop er en fersk, tom database, ikke en produksjonshendelse.
// Choose the database at runtime. Blank env = embedded, local, harmless.function makeDb() { const url = process.env.DATABASE_URL; if (url) return connectHosted(url); // In-process Postgres persisted to a local folder const client = new EmbeddedPostgres('./.pgdata'); return drizzle(client, { schema });}Veien tilbake til en fersk database betyr like mye som motoren. Vi bygger den lokale databasen på nytt ved å kjøre de samme migrasjonsfilene som produksjon kjørte, i rekkefølge, fra den aller første. Den ene avgjørelsen har fanget en hel familie av feil gratis: en migrasjon som antok en kolonne fra en senere fil, en skjemaendring som virket mot et gammelt øyeblikksbilde, men ikke fra bunnen. Klarer ikke laptopen å bygge skjemaet fra historikken, klarte ikke neste utrulling det heller.
Så en virksomhet, ikke rader
Forskjellen på ubrukelige og nyttige oppdiktede data er fortellingen. Såscriptet vårt setter ikke inn ti brukere som heter test. Det lager en salong med et navn, ansatte med spesialiteter, tjenester med ærlige priser og varigheter, kunder med besøkshistorikk, kommende avtaler, butikkvarer med lagernivåer og en hovedbok bak seg. Sidene ser bebodde ut, og det betyr at layoutfeil, tomme tilstander og klønete avkorting dukker opp slik de ville gjort for en ekte kunde.
Den siste egenskapen er lett å undervurdere. Hvert skjermbilde i dokumentasjonen vår, på bloggen vår og i feilrapportene våre kommer fra sandkassen med såddata. Ingen må myse på et bilde og lure på om et kundenavn slapp gjennom, for det finnes ingen kundenavn å slippe gjennom. Den tryggeste sladdingen er å ikke ha noe å sladde.
Hva du bør få riktig
- Gjør den trygge veien til standardveien. Utviklere skal måtte gå ut av sin vei for å nå ekte data, ikke ut av sin vei for å unngå dem.
- Nøytraliser bivirkningene også: nøkler for e-post, betaling og lagring står tomme lokalt, så en løkke over sådde kunder kan aldri sende melding til en ekte person.
- Så de tilstandene du gruer deg til: den splitter nye kontoen, den fullbookede dagen, produktet det er tomt for, kunden med ett besøk for flere år siden.
- Hold såddataene med i kodegjennomgangen. Når en funksjon legger til en tabell, vokser såddataene med den, ellers råtner sandkassen stille.
Gevinsten bygger seg opp. Nye kolleger kjører to kommandoer og har en fungerende virksomhet å rote i. Visuell QA kan fotografere hver side uten en personvernvurdering. Og demomiljøet er alltid fem minutter fra plettfritt, fordi plettfritt bare er én ombygging unna.
Produksjonsdata svarer på spørsmål. Såddata lar deg stille dem trygt.
