En sandkasse med testdata slår en kopi af produktion

Der kommer et øjeblik i ethvert lille teams liv, hvor nogen foreslår at pege den lokale udvikling mod en kopi af produktionsdatabasen, fordi de opdigtede data føles tynde, og de rigtige fejl kun sker med rigtige poster. Det er en fristende idé med en lang hale af fortrydelse: adgangsoplysninger spredt ud over bærbare, kundenavne i skærmbilleder, et testjob til mails der en dag finder rigtige adresser. Vi gik den anden vej og har ikke kigget tilbage.

En hel Postgres inde i processen

Indlejrede Postgres-versioner er blevet virkelig gode. Vores app beslutter ved opstart: findes der rigtige adgangsoplysninger til databasen i miljøet, bruges den hostede database; er de tomme, startes en Postgres i samme proces, der bor i en lokal mappe. Udviklingsmaskiner har simpelthen aldrig adgangsoplysningerne, så det værste, en forkert opsat bærbar kan gøre, er at give en frisk tom database og ikke en hændelse i produktion.

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}

Vejen til at bygge op igen betyder lige så meget som selve motoren. Vi genskaber den lokale database ved at køre de samme migreringsfiler, som produktion har kørt, i rækkefølge, fra den første. Den ene beslutning har fanget en hel familie af fejl gratis: en migrering der gik ud fra en kolonne fra en senere fil, en skemaændring der virkede mod et forældet øjebliksbillede, men ikke fra bunden. Kan den bærbare ikke bygge skemaet op fra historikken, kunne det næste deploy heller ikke.

Sæt en forretning op, ikke rækker

Forskellen på ubrugelige og brugbare opdigtede data er en fortælling. Vores seed-script indsætter ikke ti brugere ved navn test. Det laver en salon med et navn, medarbejdere med specialer, ydelser med ærlige priser og varigheder, kunder med besøgshistorik, kommende aftaler, varer med lagerbeholdning og et bevægelsesspor bag sig. Siderne ser beboede ud, og det betyder, at fejl i layout, tomme tilstande og akavet afkortning dukker op, som de ville gøre for en rigtig kunde.

Den sidste egenskab er nem at undervurdere. Hvert skærmbillede i vores dokumentation, vores blog og vores fejlrapporter kommer fra sandkassen. Ingen skal sidde og myse på et billede og spørge, om et kundenavn er sluppet med, for der er ingen kundenavne at slippe med. Den sikreste sløring er ikke at have noget at sløre.

Det, du skal have styr på

• Gør den sikre vej til standardvejen. Udviklere skal gå ud af deres vej for at nå rigtige data, ikke for at undgå dem.
• Neutralisér også sideeffekterne: nøgler til mail, betalinger og lagring står tomme lokalt, så en løkke over opdigtede kunder aldrig kan skrive til et rigtigt menneske.
• Sæt de tilstande op, du frygter: den helt nye konto, den fuldt bookede dag, varen der er udsolgt, kunden med ét besøg for år tilbage.
• Hold seed-scriptet med i code review. Når en funktion tilføjer en tabel, vokser seedet med den, ellers rådner sandkassen stille.

Gevinsten vokser med tiden. Nye kolleger kører to kommandoer og har en fungerende forretning at rode med. Visuel QA kan fotografere hver eneste side uden en gennemgang af privatliv. Og demomiljøet er altid fem minutter fra at være helt rent, fordi rent bare er en genopbygning væk.

Produktionsdata svarer på spørgsmål. Testdata lader dig stille dem trygt.