Naplněný sandbox je lepší než kopie produkce
Celé naše lokální prostředí je Postgres běžící v procesu, který nastartuje prázdný, spustí skutečné migrace a naplní se přesvědčivým smyšleným salonem. Žádné produkční přístupy na noteboocích, žádná skutečná data klientů na snímcích obrazovky a ukázka, která nikdy nezestárne.
V životě každého malého týmu přijde chvíle, kdy někdo navrhne napojit lokální vývoj na kopii produkční databáze, protože smyšlená data působí tence a skutečné chyby se dějí jen na skutečných záznamech. Je to lákavý nápad s dlouhým ocasem lítosti: přístupové údaje roztroušené po noteboocích, jména klientů na snímcích obrazovky, testovací rozesílání e-mailů, které jednoho dne najde skutečné adresy. Šli jsme opačnou cestou a nikdy jsme toho nelitovali.
Celý Postgres uvnitř procesu
Vestavěné buildy Postgresu jsou dnes opravdu dobré. Naše aplikace se při startu rozhodne: když jsou v prostředí skutečné přístupové údaje k databázi, použije hostovanou databázi; když jsou prázdné, spustí Postgres uvnitř procesu, který žije v lokální složce. Vývojářské počítače ty údaje prostě nikdy nemají, takže špatně nastavený notebook skončí čerstvou prázdnou databází, ne incidentem na produkci.
// 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 });}Cesta k přestavbě je stejně důležitá jako samotný stroj. Lokální databázi vytváříme znovu tak, že spustíme stejné migrační soubory, jaké prošly na produkci, popořadě, od úplně prvního. To jediné rozhodnutí zdarma odchytilo celou rodinu chyb: migraci, která počítala se sloupcem z pozdějšího souboru, změnu schématu, která fungovala proti zastaralému snímku, ale ne od nuly. Když notebook neumí schéma postavit z historie, nedokázalo by to ani další nasazení.
Naplňte podnik, ne řádky
Rozdíl mezi neužitečnými a užitečnými smyšlenými daty je příběh. Náš seed skript nevkládá deset uživatelů jménem test. Vytvoří salon se jménem, personál se specializacemi, služby s poctivými cenami a délkami, klienty s historií návštěv, nadcházející rezervace, prodejní zboží se stavy skladu a knihou za nimi. Stránky vypadají obydleně, což znamená, že chyby v rozvržení, prázdné stavy i nešikovné oříznutí textu vylezou stejně, jako by vylezly skutečnému zákazníkovi.
Tuhle vlastnost je snadné podcenit. Každý snímek obrazovky v naší dokumentaci, na našem blogu i v hlášeních chyb pochází z naplněného sandboxu. Nikdo nemusí mžourat do obrázku a ptát se, jestli tam neproklouzlo jméno klienta, protože tam žádná jména klientů proklouznout nemůžou. Nejbezpečnější začerňování je nemít co začerňovat.
Co udělat dobře
- Bezpečná cesta ať je ta výchozí. Vývojáři by se ke skutečným datům měli muset dostávat oklikou, ne se jim oklikou vyhýbat.
- Zneškodněte i vedlejší účinky: klíče k e-mailům, platbám a úložišti zůstávají lokálně prázdné, takže smyčka přes seed klienty nemůže nikdy napsat skutečnému člověku.
- Naplňte stavy, kterých se bojíte: úplně nový účet, plně obsazený den, vyprodaný produkt, klienta s jedinou návštěvou před lety.
- Držte seed v revizích kódu. Když funkce přidá tabulku, seed roste s ní, jinak sandbox potichu zplesniví.
Výnos se skládá. Noví kolegové spustí dva příkazy a mají funkční podnik, do kterého můžou šťourat. Vizuální QA může vyfotit každou stránku bez kontroly na soukromí. A ukázkové prostředí je vždycky pět minut od panenského stavu, protože panenský stav je jen jedna přestavba daleko.
Produkční data odpovídají na otázky. Seed data vám dovolí je bezpečně klást.
