Witryny pomostowe, w jaki sposób zarządzasz synchronizowaniem aktualizacji w bazie danych?

Powszechnie przyjmuje się, że programiści powinni testować aktualizacje za pośrednictwem strony testowej przed wydaniem ich na serwerze na żywo, jednak gdy aktualizacje programistyczne wymagają modyfikacji w Wordpress DB, sprawy się komplikują, ponieważ użytkownicy w witrynie na żywo również zaktualizują DB.

Jedyny (zamglony) przepływ, jaki mogę sobie wyobrazić, jest następujący:

1. Test na lokalnym serwerze (WAMP, XAMP itp.)
2. Gdy wszystko będzie gotowe do wdrożenia, ustaw działającą witrynę w trybie konserwacji
3. Kopia zapasowa witryny na żywo (powielacz, sqldump itp.)
4. Utwórz klon zablokowanej witryny na żywo do strony pośredniej
5. Prześlij modyfikacje ze środowiska lokalnego do witryny pomostowej
6. Przetestuj stronę testową
7. Wciśnij stronę inscenizacji, aby żyć.
8. Usuń tryb konserwacji

Wady przepływu powyżej:

• przestoje mogą być dłuższe niż oczekiwano dla użytkowników, gdy programista dokładnie testuje aktualizacje w witrynie pomostowej;
• może wymagać ręcznego zarządzania modyfikacjami: na przykład układy programu budującego strony siteorigin są przechowywane w bazie danych, więc po zmodyfikowaniu układu należy go ręcznie zaimportować w witrynie pomostowej; w takim przypadku wystarczy po prostu upuścić i zaimportować strony do witryny pomostowej, a jeśli działa, zaimportować je do witryny na żywo

Zastanawiam się, czy istnieje lepszy i bardziej zautomatyzowany sposób na osiągnięcie tego.

Co myślisz?

EDYCJA, zgodnie z żądaniem, niektóre rozwiązania były proponowane w przeszłości, ale żadne nie oferuje ostatecznego rozwiązania:

• 9/2010 - Synchronizacja bazy danych między programowaniem / etapowaniem a produkcją
• 12/2011 - Wdrażanie zaktualizowanych lub nowych wtyczek modyfikujących tabelę wp_options
• 9/2014 - Jak przesłać lokalne zmiany na serwer na żywo bez nadpisywania nowych postów / stron?
• 1/2015 - Jak utrzymywać blogi witryny wordpress w produkcji i inscenizacji?

Nowsze firmy hostingowe, które obsługują WordPress, zwykle dysponują narzędziami, które łagodzą ten ból. Umieszczam moich klientów w Pantheon, który ma ten ciekawy przepływ pracy z obsługą Gita , w którym kod przesuwa się tylko w górę (od dewelopera przez etapowanie do produkcji), a elementy DB tylko w dół (odwrotnie od kodu). Kopiowanie bazy danych z produkcji na etapy to jedno kliknięcie z ich interfejsem. Pod warunkiem, że ten przepływ pracy jest przestrzegany, to w zasadzie eliminuje problem zepsucia produkcyjnej bazy danych, umożliwiając mi zawsze testowanie moich zmian na świeżym klonie produkcyjnych danych DB w obu etapach programowania.

Nie trzeba używać Panteonu - możesz zastosować podobne podejście w swoim procesie, używając własnych narzędzi (Git + wtyczka do klonowania DB, np. WP Migrate DB). Po prostu uważam, że ten sposób działa dla mnie dobrze.

Pytanie: dlaczego miałbyś przestawić swój zakład produkcyjny w tryb konserwacji podczas testowania etapów? W większości przypadków nie powinno być takiej potrzeby. Jedyny przypadek, jaki mogę sobie wyobrazić, to posiadanie pewnego rodzaju bardzo kruchego systemu, który jest bardzo wrażliwy na podawanie dodatkowych danych użytkownika, z katastrofalnym błędem do uruchomienia - ale to prawdopodobnie wskazywałoby na inny, większy problem, w którym trzeba by było do przemyślenia całej architektury swojego produktu.

Zobacz VersionPress, który przenosi wersjonowanie GIT do całego procesu (plików i bazy danych)

Jak opisano na ich stronie:

VersionPress zapewnia bezbolesną inscenizację . Oznacza to, że możesz łatwo stworzyć bezpieczne środowisko testowe dla swoich zmian i scalić je z powrotem, gdy będą gotowe. Scalanie jest tutaj kluczowym słowem - VersionPress bezproblemowo radzi sobie z sytuacjami, w których witryna na żywo ma nową treść.