W jaki sposób można zaimplementować replikację bazy danych na potrzeby aplikacji demo/staging?
Czy warto w ogóle bawić się w anonimizację przy bardziej złożonych asocjacjach?
Jeśli użyję bazy z produkcji naruszę ustawę o ochronie danych osobowych. Jeśli przepuszczę bazę z produkcji przez Faker’a albo seed’a, żeby wymazać prywatne dane, część z nich zostanie w załączonych wygenerowanych plikach oraz utrudnię testowanie i akceptację kolejnych feature’ów. Poza tym błąd na produkcji nie zawsze musi być reprodukowalny po anonimizacji bazy danych.
My do testów mamy bazy demo generowane przez nas i na nich testujemy sprawdzamy. Minus jest taki, że czasem musimy sobie “dogenerować” trochę danych, czasem bierzemy do testów bazę produkcyjną - ale to jeśli trzeba.
http://rubygems.org/gems/copydb
Copydb is a gem that helps you to copy databases e.g. from a production database to your development database. During the process it is possible to define columns in tables in which the data should be exchanged for fake data. This can be interesting in a scenario where you want to run your development machine with production data, but privacy laws (such as in Germany) prohibit you to use real data.
wszystko już zostało wymyślone i jest dwa google stąd 
1 Like
kopiowanie bazy do yamla to słabe rozwiązanie, potem są problemów ze znakami narodowymi
Z tego co wiem to nie ma. YAML obsluguje unicode poprawnie.
Nie rozwiązuje to kilku problemów:
- Dane osobowe w wygenerowanych plikach
- Za każdym przebiegiem db:dump db:load muszę wygenerować loginy dla testerów oraz ich konfiguracje
- niektóre błędy i tak mogą nie zostać wychwycone np brak obsługi polskich znaków w loginach
Może już lepiej posiadać bardzej rozbudowany db:seed + kopiować bazę z produkcji do developer’a tylko w przypadku błędów które tego wymagają.
Wygląda nieźle, ale czy aby jeszcze żyje? Ostatni commit 2 lata temu…
1 Like
Czasami projekty po prostu działają 
nawet po 2 latach 
oczywiście nie gwarantuję bo sam wyguglałem a nie testowałem. zawsze można rzucić okiem na githuba może są nowocześniejsze forki
PS.
@usek nie bardzo rozumiem twoje zastrzeżenia. 1) jest opcja kasowania poszczególnych kolumn. 2) Dlaczego? Nie wystarczy im założyć kont na produkcji? 3) tego też ni czaję? jaki ma to związek z dump/restore?
PPS. Przecież jesteś programistą jak potrzebujesz zawsze coś robić po kopii bazy jaki widzisz problem z dodaniem krótkiego skryptu?
- Nawet jeśli zmienie dane osobowe w bazie, nie zmienie ich w wygenerowanych plikach np faktura z imieniem i nazwiskiem w formacie pdf
- Jak założe konto na produkcji a potem przefiltruje Faker’em to dostanę losowy email, jak się mam z nim na konto zalogować?
- Na produkcji mamy użytkownika Józek Ogórek który wywala błąd przy loginie, kiedy przepuszczę go przez faker’a dostanę Johnego Bravo bez polskich znaków który zaloguje się bez problemów.
PPS. Przecież jesteś programistą jak potrzebujesz zawsze coś robić po kopii bazy jaki widzisz problem z dodaniem krótkiego skryptu? smile
Właśnie jeden z programistów napisał skrypt i jest on przerażająco długi i drogi w utrzymaniu a nie rozwiązuje on wszystkich problemów, stąd moje pytanie o doświadczenie innych osób.
Oczywiście. Takie projekty dzielą się na dwie grupy. Te, które nie są używane i te, które nie są monitorowane.
@sharnik a tam mam kilka projektów które używam, i kilka wtyczek które napisałem lata temu pod spree. jedna z tych wtyczek przez 3 lata nie wymagała żadnej modyfikacji, spełniała swoje zadanie, funkcjonalnośc była konkretna i ograniczona. Nie było żadnej potrzeby jej ruszać aż wyszła nowa major wersja.
ad A) wyfiltruj?
ad B) whitelista emaili, zależnie od aplikacji możesz mieć też przez przypadek pole “login” puste gdzie wystarczy uzupełnić dla testerów
ad C) Dodaj polskie generatory do fakera? dodaje się dosyć trywialnie nawet widziałem gdzieś przykład.
Generalnie zadałeś pytanie, dostałeś odpowiedź która daje ci dobry start teraz drążysz dziurę w całym? oczekiwałeś innej odpowiedzi czy jak?