Dane na środowiskach testowych i lokalnych

Cześć,

chciałbym się dowiedzieć jak u was to wygląda w projektach jeśli chodzi o dane w bazie na których można pracować na środowiskach testowych i/lub lokalnie.

W obecnym projekcie brak prawdziwych lub zbliżonych danych do produkcyjnych stał się sporym problemem. Posiadamy dev + stg, specyfika projektu wymaga testowania manualnego. Często ewentualne problemy z wydajnością wychodzą dopiero po releasie i są widoczne w monitoringu. Idealnie byłoby mieć taką informację wcześniej. Dodam, że dane są na tyle "wrażliwe", że nie możemy skopiować ich 1:1 na inne środowiska, do których dostęp mają wszyscy. Dodatkowym utrudnieniem jest sterta zależności z innymi zewnętrznymi komponentami, więc przenoszenie danych 1:1 bez modyfikacji może być niewykonalne.

Mamy DevOps'a, są gdzieś skrypty ansible'a i terraforma, więc nie wykluczam skill issue, być może dałoby radę to sparametryzować jakoś. Widziałem też, że istnieją toole do anonimizacji/mixowania danych w postgresie - może ktoś ma doświadczenie w tym aspekcie?

Co w przypadku lokalnego środowiska - praktykujecie tworzenie skryptów do tworzenia danych na potrzeby lokalne wraz z powstawaniem nowej funkcjonalności, czy raczej jakiś dump ze środowiska dev/stg?

Szukam rozwiązania/inspiracji jak mógłbym uczynić życie przyjemniejszym.

PS: Na potrzeby wątku załóżmy, że Continous Integration i merge'owanie Od razu do mastera nie wchodzi w grę

Mozna robic np tak rozrozniajac srodowiska:
DEV - dane testowe
TST - dane testowe
ACC - dane produkcyjne (skopiowane z PRD z danej daty) - tu juz dostep do danych musi byc odpowiednio chroniony
PRD - dane produkcyjne

pozdr

Pierwsze co warto by zrobić, to zastanowić się czy wszystkie z tych "danych" muszą być danymi. Czasem się zdarzy że trzymamy w bazie dane które nigdy się nie zmieniają (i są takie same na wszystkich środowiskach). Wtedy czasem warto je po prostu przenieść do kodu.

Natomiast jeśli dane faktycznie są "danymi", to w zasadzie pojawia się pytanie - po co chcielibyśmy je współdzielić między środowiskami?

fespue napisał(a):

W obecnym projekcie brak prawdziwych lub zbliżonych danych do produkcyjnych stał się sporym problemem.

Co to za "problem" konkretnie?

Jedyne "dane" jakie ja staram się automatycznie tworzyć, to tylko i wyłącznie te które umiem manualnie stworzyć i tworzę często (np. jak tworzę usera do testów, to sobie zautomatyzuję dodawanie go), ale jeśli czegoś nie tworzę ręcznie, albo robię to dosyć rzadko (np. raz na 2 tygodnie) to wolę utrzymać aplikację "pustą".

Jak wyżej, a ja akurat preferuję stworzenie sobie danych na deva, (czasem może być tak, że się to musi zrobić), a nie preferuję testowania manualnego.

Ostatnio miałem trochę tematów związanych z persistence. Głownie optymalizacja zapytań / bazy / data retention. Dane generowaliśmy za pomocą sqli bo inaczej się nie dało.

W zaleznosci od potrzeb, rozwiazaniem moze byc https://postgresql-anonymizer.readthedocs.io/en/stable/

Robisz dumpa proda -> lokalnie robisz anonimizacje -> dumpujesz zanonimizowane dane -> uzywasz zanonimizowanych, ale relewatnych danych gdzie chcesz - w tym przekazujesz do devow bez uprawnien do proda

I mozesz aktualizowac co dzien/tydzien/miesiac/...

EDIT: Na koniec jeszcze mozesz walnac asercje, ze wszystkie kolumny zostaly obsluzone:

-- check missing ones
SELECT 'SECURITY LABEL FOR anon ON COLUMN ' || table_name || '.' || column_name || ' IS ''MASKED WITH VALUE ' ||
       column_name || ''';' AS objname
INTO TEMPORARY missing_security_labels
FROM information_schema.columns isc
         LEFT JOIN pg_catalog.pg_seclabels pgs ON pgs.objname = isc.table_name || '.' || isc.column_name
WHERE isc.table_schema = 'public'
  AND (pgs.provider IS NULL OR pgs.label NOT LIKE 'MASKED WITH%')
  AND isc.table_name
ORDER BY table_name, column_name;

SELECT * FROM missing_security_labels;
do $$
    declare
        missing_security_labels_count integer;
    begin
        select count(*)
        into missing_security_labels_count
        from missing_security_labels;

        assert missing_security_labels_count = 0, 'Security labels not found for some fields.';
    end$$;

Często ewentualne problemy z wydajnością wychodzą dopiero po releasie i są widoczne w monitoringu

Zdecydowanie generatory danych. Najlepiej jeśli są częścią aplikacji (żadnych lewych skryptów "na boku"). Najprościej: aplikacja webowa/mikroserwis w trybie/profilu dev ma włączony endpoint /generate gdzie przekazujesz, że chcesz stworzyć 20 customerów z 1000 użytkownikami, a każdy z nich ma cośtam i cośtam itd. Może być seed rng przekazany też, jeśli chcemy mieć reprodukowalność, taki bajer. Minus - trzeba to utrzymywać jak każdy inny ficzer, i łatwo stworzyć coś, co nie daje realnego obrazu produkcji, trzeba się postarać.

Anonimizacja + dump jest spoko, ale często ciężko określić jest co jest tajne a co nie, a zwykle nikt nie weźmie za ewentualne błędy odpowiedzialności.

Aczkolwiek z doświadczenia, jestem coraz bardziej zdania, że należy jak najwięcej testować na produkcji i nie rozwiązywać problemów, których nie ma, a raczej pozwolić sobie na margines wpadek, jednocześnie mając możliwość szybko je poprawiać.

Jeśli nie masz naprawdę dobrych testów to nie widzę innej opcji niż anonimizacja bazy. Generatory są dobrym podejściem, ale bugi najczęściej wychodzą w specyficznych przypadkach o których ktoś nie pomyślał w czasie developmentu, bo generatory nie wygenerowały wszystkich przypadków.

U mnie środowiska testowe są regularnie odświeżane i dane w bazach są zastępowane zanimizowanymi danymi z produkcji (nie jestem pewien jaki wolumen ale raczej duży).
Też, niestety, gros testów to jedynie testy manualne (jak się przyjmowałem do pracy to słyszałem,m że mój nowy zespół i umie i pisze testy -> praktyka pokazałą, że nie pisze a jak już sporadycznie napisze to nie umie w efekcie czego 99% zmian w kodzie testowym to bezmyślne poprawianie obecnych testów żeby się kompilowało bo np. w jakimś obiekcie doszło jakieś pole) xD