Czy masz jakieś skuteczne strategie uruchomienia wersji 2 strony WP?

Mój zespół i ja współpracujemy z klientem, który ma istniejącą witrynę WordPress z dużą ilością treści i niestandardowym motywem. Jest to blog grupowy, co oznacza, że ​​ma kilku blogerów na całym świecie, którzy cały czas dodają i edytują zawartość.

Naszym zadaniem jest stworzenie zupełnie nowego motywu z kilkoma nowymi funkcjami. Niektóre z tych funkcji będą wymagać nowych niestandardowych widżetów, wtyczek i pól bazy danych.

Obecnie pracujemy nad własnymi maszynami programistycznymi i integrujemy je w jeden serwer programistyczny. Cały kod jest wersjonowany w SVN. Nasz wyznaczony DBA teraz ręcznie łączy wszelkie zmiany bazy danych z dev DB, ale mam nadzieję, że będzie w stanie zautomatyzować to wkrótce.

Właśnie zaczęliśmy rozmawiać o naszym procesie produkcji. Czyli: kiedy skończymy, w jaki sposób zamierzamy przenieść cały nasz niestandardowy kod na serwer produkcyjny (na żywo) płynnie i przy możliwie najmniejszych zakłóceniach?

Mamy na myśli kilka planów, ale chciałbym usłyszeć, jak inni również poradzili sobie z tym problemem. Czy są jakieś najlepsze praktyki do naśladowania lub znane pułapki, których należy unikać?

Postępując zgodnie z radą SethMerrick, możesz znacznie skrócić czas przełączania, obniżając TTL w odpowiednich rekordach DNS do około 5 minut lub kilku godzin (w zależności od aktualnego TTL) przed zmianą adresu IP.

Robiąc to, każesz zdalnym serwerom DNS buforować adres tylko przez 5 minut. Po zmianie adresu IP możesz zwiększyć TTL do tego, co było wcześniej. Aby dodatkowo zminimalizować efekt, wykonaj przełączenie w okresie małego natężenia ruchu.

Nie jestem pewien, czy to dotyczy, ale właśnie przeszedłem podobny proces jednoczesnej migracji i aktualizacji witryny o dużym natężeniu ruchu.

Podstawową strategią była praca na serwerze pomostowym, a następnie, gdy wszystko było gotowe, wykonaj zrzut mysql na serwerze pomostowym, zaimportuj go na serwer pomostowy, wykonaj wymagane czyszczenie, a następnie skieruj rekordy DNS na serwer pomostowy, powodując serwer pomostowy, aby stać się nowym serwerem na żywo.

Trudnym zadaniem jest połączenie wszystkich danych, które gromadzą się podczas propagacji DNS na serwerze pomostowym (który jest teraz serwerem na żywo). Innymi słowy, jeśli upłynie 30 godzin między wykonaniem zrzutu / aktualizacji DNS MySQL a zakończeniem propagacji DNS, będziesz musiał selektywnie scalić 30 godzin rekordów ze starej witryny do nowej.

Nie jest to bezproblemowy proces, ale zanim minął tydzień, wszystkie załamania się wygładziły.

@Mike Lee: Świetne pytanie i jeden ze świętych Graala WordPressa (lub dowolnego z głównych CMSów open source, które znam w tej dziedzinie, takich jak Drupal, Joomla i in.)

Chociaż z pewnością nie ma to dotyczyć twojego przypadku użycia, sprawdź moją odpowiedź na powiązane pytanie, które opisuje wtyczkę na poziomie beta, którą właśnie udostępniłem za pośrednictwem WordPress Answers Exchange o nazwie WP Migrate Webhosts (tak, jestem do kitu, jeśli chodzi o twórcze nazewnictwo .)

Ale chcę również rozwiązać opisany przypadek użycia wtyczki i obecnie zastanawiam się, jak to osiągnąć. Myślę, że sposobem na podejście jest rezygnacja z ogólnego rozwiązania, a zamiast tego zająć się znanymi wzorami, które istnieją w WordPress, a następnie pozwolić innym osobom „ zaczepić ” moją wtyczkę do specjalnych przypadków użycia. Myślę również, że podejście polega na serializacji danych i struktur w WordPress jako danych w pliku PHP, tak aby przyszła wtyczka mogła zastosować te zmiany jako delty, podobnie jak system kontroli kodu źródłowego stosuje delty, aby dotrzeć do bieżącej wersji źródła kod.

Więc chociaż nie odpowiadam ani nie rozwiązuję twojego problemu w pełni, mam nadzieję, że daję ci dobre jedzenie do przemyślenia, a także mam nadzieję, że ty lub ktoś inny może chcieć współpracować przy ostatecznym rozwiązaniu.