Zasiana piaskownica bije kopię produkcji
Całe nasze lokalne środowisko to Postgres działający w tym samym procesie, który startuje od pustki, stosuje prawdziwe migracje i sam wypełnia się przekonującym, wymyślonym salonem. Żadnych danych dostępowych do produkcji na laptopach, żadnych prawdziwych danych klientów na zrzutach ekranu i demo, które nigdy się nie starzeje.
W życiu każdego małego zespołu przychodzi moment, w którym ktoś proponuje podpięcie lokalnego developmentu pod kopię bazy produkcyjnej, bo wymyślone dane wydają się cienkie, a prawdziwe błędy zdarzają się tylko na prawdziwych zapisach. To kusząca myśl z długim ogonem żalu: dane dostępowe rozsiane po laptopach, nazwiska klientów na zrzutach ekranu, testowe zadanie od e-maili, które pewnego dnia trafia na prawdziwe adresy. Poszliśmy w drugą stronę i nigdy tego nie żałowaliśmy.
Cały Postgres wewnątrz procesu
Wbudowane wersje Postgresa zrobiły się naprawdę dobre. Nasza aplikacja decyduje przy starcie: jeśli w środowisku są prawdziwe dane dostępowe do bazy, używa bazy hostowanej, a jeśli są puste, podnosi Postgresa w tym samym procesie, mieszkającego w lokalnym folderze. Maszyny deweloperskie po prostu nigdy nie mają tych danych, więc skutkiem źle skonfigurowanego laptopa jest świeża pusta baza, a nie incydent na produkcji.
// 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 });}Ścieżka odtwarzania liczy się tak samo jak silnik. Lokalną bazę odtwarzamy, stosując te same pliki migracji, które przeszła produkcja, po kolei, od pierwszego. Ta jedna decyzja złapała nam za darmo całą rodzinę błędów: migrację, która zakładała kolumnę z późniejszego pliku, zmianę schematu, która działała na przestarzałej migawce, ale nie od zera. Jeśli laptop nie potrafi zbudować schematu z historii, kolejne wdrożenie też by nie potrafiło.
Zasiej firmę, a nie wiersze
Różnica między bezużytecznymi a użytecznymi wymyślonymi danymi to opowieść. Nasz skrypt zasiewający nie wstawia dziesięciu użytkowników o nazwie test. Tworzy salon z nazwą, personel ze specjalizacjami, usługi z uczciwymi cenami i czasami trwania, klientów z historią wizyt, nadchodzące rezerwacje, produkty do sprzedaży ze stanami magazynowymi i księgą za nimi. Strony wyglądają na zamieszkane, co znaczy, że błędy układu, puste stany i niezgrabne ucięcia tekstu pojawiają się tak, jak pojawiłyby się u prawdziwego klienta.
Tę ostatnią właściwość łatwo niedocenić. Każdy zrzut ekranu w naszej dokumentacji, na blogu i w zgłoszeniach błędów pochodzi z zasianej piaskownicy. Nikt nie musi mrużyć oczu nad obrazkiem i pytać, czy nie przemknęło jakieś nazwisko klienta, bo nie ma tam żadnych nazwisk, które mogłyby przemknąć. Najbezpieczniejszy proces anonimizacji to taki, w którym nie ma czego anonimizować.
Co trzeba zrobić dobrze
- Zrób z bezpiecznej ścieżki ścieżkę domyślną. Programista powinien się nagimnastykować, żeby dotrzeć do prawdziwych danych, a nie po to, żeby ich uniknąć.
- Unieszkodliw też skutki uboczne: klucze do e-maili, płatności i magazynu plików zostają lokalnie puste, więc pętla po zasianych klientach nigdy nie napisze do prawdziwej osoby.
- Zasiej te stany, których się boisz: zupełnie nowe konto, dzień zapełniony do końca, produkt bez stanu, klient z jedną wizytą sprzed lat.
- Trzymaj skrypt zasiewający w przeglądzie kodu. Kiedy nowa funkcja dodaje tabelę, skrypt rośnie razem z nią, albo piaskownica po cichu gnije.
Zysk się kumuluje. Nowe osoby w zespole uruchamiają dwa polecenia i mają działającą firmę do pogrzebania. Wizualne QA może sfotografować każdą stronę bez przeglądu pod kątem prywatności. A środowisko demo jest zawsze pięć minut od nieskazitelnego, bo nieskazitelne to po prostu jedno odtworzenie stąd.
Dane produkcyjne odpowiadają na pytania. Dane zasiane pozwalają je bezpiecznie zadawać.
