W rzeczywistości chcemy tego: http://www.liquibase.org/
Liquibase to otwarta biblioteka (licencjonowana Apache 2.0), niezależna od bazy danych biblioteka do śledzenia, zarządzania i stosowania zmian w bazie danych. Opiera się na prostej przesłance: wszystkie zmiany w bazie danych są przechowywane w czytelnej dla człowieka, ale możliwej do śledzenia formie i sprawdzane pod kontrolą źródła.
Jednak nasz proces rozwoju tego nie obsługuje. Zazwyczaj nie modyfikujemy bazy danych za pomocą dyskretnych skryptów, które sami piszemy, korzystamy z aktywowanych przez nas wtyczek. Nie piszemy skryptów DML do modyfikowania danych wyszukiwania, które następnie sprawdzamy w celu kontroli kodu źródłowego, używamy interfejsu użytkownika na stronie administratora i dlatego nie mamy kodu źródłowego do późniejszego wykorzystania w replikacji tej zmiany podczas migracji.
Możemy jednak naśladować niektóre z nich - korzystając z niektórych narzędzi wymienionych na tej stronie:
/programming//q/225772/149060
Na przykład baza cieczy ma funkcję różnicowania, która również opcjonalnie obejmuje zmiany danych. Możemy potencjalnie wyprowadzić schemat i różnicę danych do skryptu, wykluczając (jak to możliwe) niektóre tabele, które mogą zawierać dane testowe (tj. Post itp.), A następnie zastosować skrypt do produkcyjnej bazy danych.
MySQLDiff (omówione w pytaniu StackOverflow) ma różnice w schemacie i jego autor zaleca mysql_coldiff w przypadku różnic danych w tabelach - oba są implementowane w perlu, jeśli narzędzia Java (baza płynów) są zbyt obciążające zasoby dla twoich serwerów - chociaż przenieś obie bazy danych lokalnie a uruchomienie narzędzia na komputerze rozwiązuje ten problem ...
Jeśli naprawdę chcemy to zrobić poprawnie, powinniśmy zarejestrować każdy kod SQL związany z ustawieniami, opcjami lub innymi zmianami konfiguracji i wszelkimi zmianami schematu - i przekonwertować zarejestrowany kod na skrypt migracji, aby grać na naszym serwerze produkcyjnym. Zagraj w skrypt migracji na serwerze, skopiuj pliki strony wordpress (z wyłączeniem przesyłania, jeśli dotyczy), a my będziemy złota.
Wydaje mi się więc, że najlepszym wyjściem jest wtyczka do tworzenia i migracji programów deweloperskich, która przechwytuje potrzebną sql, przechowuje ją, a następnie generuje skrypt migracji z zarejestrowanego kodu, zamiast budować sposób na połączenie baz danych między inscenizacją a produkcją. Wydaje się również, że problem jest prostszy do rozwiązania.
Jeśli spojrzymy na kod wtyczki przywoławczej @bueltge, wtyczka wywołuje inspirację: https://gist.github.com/1000143 (dzięki Ronowi Rennickowi za pośrednictwem G + za skierowanie mnie w stronę SAVEQUERIES i haka zamykającego, to poprowadź mnie do znalezienia)
- zmień go, aby otrzymać wyjście SAVEQUERIES
- uruchamiaj tylko będąc w adminie
- odfiltruj wszystkie wybrane
- zapisać wyniki na stole w haku zamykającym
- możemy selektywnie przełączać pułapki wyjściowe w oparciu o to, co robiliśmy w tej chwili.
Na przykład:
Nazwa przechwytywania: Aktywuj i skonfiguruj wtyczkę XYZ
Włącz przechwytywanie stanu
... zainstaluj i skonfiguruj wtyczkę XYZ
Capture State Toggle - off
Eksportuj skrypt migracji dla: Aktywuj i skonfiguruj wtyczkę XYZ
Naciśnij przycisk Eksportuj - aby wyświetlić wyskakujące pole tekstowe z filtrowanym SQL w pułapce - najlepiej wstępnie sformatowane jako skrypt powłoki z wywołaniem wiersza polecenia do mysql. Skopiuj i wklej go do folderu kodu migracji i dodaj do repozytorium kodu źródłowego.
Uważaj na włączanie i wyłączanie przechwytywania podczas pracy, a będziesz w stanie wygenerować idealny skrypt migracji, aby przenieść produkcyjną bazę danych do konfiguracji równoważnej z bazą danych pomostowych.
Co więcej, będziesz mieć skrypt (lub serię takich samych), który możesz TESTOWAĆ. Obrazowanie z powtarzalnymi, testowalnymi skryptami migracyjnymi !!
Jestem już zakochany.
Ktoś jeszcze?