Baza danych tworzenia i produkcji?

Question

Pracuję z PHP & mySQL. W końcu mam kontrolę nad źródłami i jestem całkiem zadowolony z całego rozwoju (testowania) v produkcji v repozytorium dla części PHP.

Mój nowy dylemat polega na tym, co zrobić z bazą danych. Czy mogę utworzyć dla środowiska testowego i środowiska produkcyjnego? Obecnie mam tylko ten, którego używają oba środowiska, pozostawiając tam moje dane testowe. Czuję, że powinienem mieć dwa, ale jestem nerwowy pod względem upewnienia się, że moja baza danych produkcji wygląda i czuje się dokładnie tak samo jak moja testowa.

Jakieś przemyślenia w którą stronę pójść? A jeśli myślisz o tym drugim, jaki jest najlepszy sposób na zachowanie tych samych dwóch baz danych (poza danymi oczywiście ...)?

Answer 1

Powinieneś mieć dwa. Jeśli chcesz zachować synchronizację, zawsze powinieneś utworzyć DDL do tworzenia obiektów bazy danych. Traktuj te skrypty tak samo jak kod PHP - zachowaj je w kontroli wersji. Za każdym razem, gdy musisz zmodyfikować bazę danych testowych, zrób skrypt, który to zrobi, i sprawdź to. Następnie możesz wprowadzić zmiany do systemu produkcyjnego, gdy będziesz gotowy.

Answer 2

Każde środowisko powinno mieć osobną bazę danych. Skryptuj wszystkie obiekty bazy danych (tabele, widoki, procedury itp.) I zapisz skrypty w kontroli źródła. Skrypty są stosowane najpierw do bazy danych programowania, następnie promowane do testów (kontrola jakości, UAT itp.), A następnie do produkcji. Stosując te same skrypty do każdej bazy danych, wszystkie powinny być takie same na końcu.

Jeśli masz dane, które wymagają załadowania (tabele kodów, wartości wyszukiwania itp.), Skrypty ładują dane w ramach procesu tworzenia bazy danych.

Dzięki skryptowaniu wszystkiego i utrzymywaniu go w kontroli kodu źródłowego, struktura bazy danych może być odtworzona w dowolnym momencie dla dowolnego poziomu kompilacji.

Answer 3

Po wdrożeniu mojej bazy danych wszelkie zmiany wprowadzone do moich baz danych programistycznych są wykonywane w skrypcie SQL (a nie narzędziu), a skrypt jest zapisywany i ponumerowany.

deploy.001.description.sql 
deploy.002.description.sql 
deploy.003.description.sql 
... etc.. 

Następnie uruchamiam każdy z tych skryptów po uruchomieniu.

Potem archiwizować je w katalogu o nazwie coś jak

\deploy.YYMMDD\ 

i zacząć wszystko od nowa.

Jeśli popełnię błąd, nigdy nie wrócę do poprzedniego skryptu wdrażania, utworzę nowy skrypt i tam wprowadzę poprawkę.

Powodzenia

Answer 4

Jako minimum jednej bazy danych dla każdej stacji roboczej rozwoju i jeden dla produkcji. Poza tym powinieneś mieć jeden dla środowiska testowego, chyba że jesteś tylko jednym programistą i ma on podobną konfigurację co środowisko produkcyjne.

Answer 5

Jedną z rzeczy, nad którymi pracowałem, jest tworzenie maszyny wirtualnej z zainstalowaną bazą danych. możesz zapisać VM jako plik gry, w tym jego dane. Możesz wtedy zrobić migawkę pliku gry i uruchomić tyle różnych maszyn wirtualnych, ile chcesz. Wszystkie mogą być identyczne lub można modyfikować jeden lub drugi. Oto dobra rzecz: zakładając, że masz wersję deweloperską bazy danych, którą chcesz uruchomić, możesz po prostu uruchomić tę maszynę wirtualną na serwerze produkcyjnym zamiast na bieżącym serwerze.

Jest to zupełnie inny problem, jeśli masz dane produkcyjne, które nie znajdują się na komputerach użytkowników. W takim przypadku można jednak skonfigurować śledzącą maszynę wirtualną. Uruchom replikację z głównej bazy danych do maszyny śledzącej. Kiedy dojdziesz do punktu, w którym musisz uruchomić kilka zmian w produkcyjnej bazie danych, najpierw zatrzymaj niewolnik i zapisz migawkę.

Uruchom instancję tej migawki, całkowicie ją wyłącz, zastosuj zmiany i wskaż pole QA w tej bazie danych. Jeśli działa zgodnie z przeznaczeniem, możesz uruchomić poprawki względem głównej bazy danych produkcji. Jeśli nie, wywołaj migawkę i przywróć ją do wzorca ponownie, aż będziesz gotowy do powtórzenia testu aktualizacji.

Answer 6

Zobacz także

How do you version your database schema?

To typowe pytanie i został poproszony i odpowiedział na wiele razy.

Thomas Owens: Replikacja nie nadaje się do wersjonowania schematów - służy do powielania danych. Nigdy nie chcesz replikować z dev do produkcji lub odwrotnie.

Answer 7

Miałem te same dylematy. Utknąłem myśląc, że istnieje wyraźna dychotomia między production db a development db. To były dwie strony medalu i nigdy nie spotka się dwoje.

Wiele problemów zniknął, kiedy zatrzymał się, że mój wniosek „myślenia” w kategoriach „Alboproduction dbLUBdevelopment db”. Zamiast tego moja aplikacja używa numeru local db.

Po uruchomieniu na moim komputerze wirtualnym (dev) ta lokalna baza danych staje się numerem jeden dev db. Moja aplikacja tak naprawdę "nie" wie.

W głównej części problem znika.

Czasami jednak chcę przeprowadzić testy przy użyciu danych na żywo lub przenieść dane z kodu do bazy produkcyjnej na żywo i szybko zobaczyć wyniki.

To jest, gdy dodałem pojęcie live-read-only db connection. Aplikacja traktuje to inaczej. To trochę tak, jak aplikacja może traktować usługę internetową, taką jak Google Apps. To "zewnętrzne źródło, z którego korzysta twoja aplikacja".

Domyślnie moja aplikacja używa local db iw niektórych bardzo szczególnych warunkach (w pakiecie testowym) również używa live-readonly db. (Ponieważ jest to połączenie tylko do odczytu, nie obawiam się, że podczas testów wystąpią bałagany na żywo).

Więc zamiast zadać pytanie "dev dbLUBproduction db?", Moja aplikacja pyta "local dbLUBlive-read-only db".

Oczywiście moja sytuacja może się różnić od twojej, ale ten "przełom w zrozumieniu" okazał się dla mnie najbardziej pomocny.