Een gevulde zandbak is beter dan een kopie van productie
Onze hele lokale omgeving is een Postgres in het proces zelf, die leeg opstart, de echte migraties toepast en zichzelf vult met een overtuigende verzonnen salon. Geen productiewachtwoorden op laptops, geen echte klantgegevens in schermafbeeldingen, en een demo die nooit veroudert.
Er komt in het leven van elk klein team een moment waarop iemand voorstelt om lokaal ontwikkelen op een kopie van de productiedatabase te richten, omdat de verzonnen data dun aanvoelt en de echte bugs alleen bij echte gegevens optreden. Het is een verleidelijk idee met een lange staart aan spijt: wachtwoorden verspreid over laptops, klantnamen in schermafbeeldingen, een testmailtaak die op een dag echte adressen vindt. Wij gingen de andere kant op en hebben nooit omgekeken.
Een hele Postgres binnen het proces
Embedded builds van Postgres zijn echt goed geworden. Onze app beslist bij het opstarten: bestaan er echte databasegegevens in de omgeving, gebruik dan de gehoste database; zijn ze leeg, start dan een Postgres op binnen het proces zelf, die in een lokale map woont. Ontwikkelmachines hebben die gegevens simpelweg nooit, dus het ergste dat een verkeerd ingestelde laptop oplevert is een verse lege database en geen incident in productie.
// 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 });}De weg terug naar een verse database telt net zo zwaar als de motor zelf. Wij bouwen de lokale database opnieuw op door dezelfde migratiebestanden toe te passen die productie draaide, op volgorde, vanaf de allereerste. Die ene beslissing heeft gratis een hele familie bugs gevangen: een migratie die uitging van een kolom uit een later bestand, een schemawijziging die tegen een verouderde momentopname werkte maar niet vanaf nul. Kan de laptop het schema niet uit de geschiedenis opbouwen, dan kon de volgende deploy dat ook niet.
Vul een bedrijf, geen rijen
Het verschil tussen nutteloze en nuttige verzonnen data is het verhaal. Ons seed-script zet niet tien gebruikers met de naam test in de database. Het maakt een salon met een naam, medewerkers met specialismen, diensten met eerlijke prijzen en tijden, klanten met een bezoekgeschiedenis, aankomende afspraken en verkoopproducten met voorraadstanden en een grootboek erachter. De pagina's zien er bewoond uit, en dat betekent dat problemen met de indeling, lege toestanden en lelijk afgekapte tekst zich net zo laten zien als bij een echte klant.

Die laatste eigenschap wordt makkelijk onderschat. Elke schermafbeelding in onze documentatie, op onze blog en in onze bugmeldingen komt uit de gevulde zandbak. Niemand hoeft met samengeknepen ogen naar een afbeelding te kijken met de vraag of er een klantnaam is doorgeglipt, want er zijn geen klantnamen om door te glippen. Het veiligste proces om iets weg te lakken, is niets hebben om weg te lakken.
Wat je goed moet doen
- Maak de veilige weg de standaardweg. Ontwikkelaars horen moeite te moeten doen om bij echte gegevens te komen, niet om ze te vermijden.
- Zet ook de neveneffecten uit: sleutels voor e-mail, betalingen en opslag blijven lokaal leeg, zodat een lus over verzonnen klanten nooit een echt mens kan mailen.
- Vul de toestanden waar je tegenop ziet: het gloednieuwe account, de volgeboekte dag, het uitverkochte product, de klant met één bezoek van jaren geleden.
- Houd de seed in de code review. Voegt een functie een tabel toe, dan groeit de seed mee, of de zandbak rot stilletjes weg.
De winst stapelt zich op. Nieuwe teamleden draaien twee commando's en hebben een werkend bedrijf om in te prikken. Visuele QA kan elke pagina fotograferen zonder privacycontrole. En de demo-omgeving is altijd vijf minuten van smetteloos, want smetteloos is niet meer dan een herbouw ver.
Productiedata beantwoordt vragen. Een gevulde zandbak laat je ze veilig stellen.