Jak przeprowadzić migrację ze środowiska testowego do środowiska produkcyjnego?

Migracja odbywa się ze środowiska lokalnego do środowiska produkcyjnego. Środowisko produkcyjne działało przez pewien czas i stworzyło wiele artykułów.

Aby dodać nowe rzeczy do mojej witryny, dodałem niestandardowy motyw i zainstalowałem CCK, widoki i inne moduły w moim lokalnym środowisku testowym. Teraz, gdy lokalne środowisko testowe jest gotowe, w jaki sposób przeprowadzić migrację do środowiska produkcyjnego bez niszczenia zawartości jego bazy danych?

Jest to nietrywialny problem, na który prawie każdy ma inną odpowiedź: nie ma kanonicznego sposobu Drupala na radzenie sobie z inscenizacją do produkcji. Dries Buytaert, facet prowadzący program Drupal, uczynił go jedną z kluczowych inicjatyw Drupala 8 . Oczywiście, Drupal 7 został właśnie wydany, więc minie trochę czasu, zanim przyniesie on jakiekolwiek owoce.

Problem można podzielić na dwie osobne kwestie:

• Konfiguracja etapowa (zmienne, typy zawartości, pola, widoki itp.)
• Inscenizacja treści (węzły, użytkownicy itp.)

Ten pierwszy może być w większości obsługiwany przez moduł Funkcje , który zabierze konfigurację witryny i przekształci go w moduł, który możesz dodać do instalacji Drupal: w ten sposób możesz dodać go do systemu kontroli wersji i nie martwić się o to zdmuchnięte podczas migracji treści.

To drugie jest naprawdę trudne, ponieważ w aktywnej witrynie prawdopodobnie zawartość zmieni się podczas produkcji, nawet po początkowej synchronizacji ze środowiskiem programistycznym. Zapobiega to hurtowej zamianie treści podczas przemieszczania, tak jak w przypadku konfiguracji.

Ponadto Drupal nie używa uniwersalnie unikalnych identyfikatorów (UUID) dla treści: za każdym razem, gdy dodawany jest węzeł lub użytkownik, identyfikator zwiększa się o jeden. Więc co może być węzłem 45 w twojej witrynie programistycznej, może być węzłem 90 w twojej witrynie produkcyjnej.

Niestety nie mam na to świetnego rozwiązania: inscenizacja treści jest prawdziwą słabością Drupala. Osobiście robię tylko dodawanie treści na stronie produkcyjnej. Jeśli klient chce zobaczyć, jak wygląda treść przed uruchomieniem, skonfiguruję klon witryny produkcyjnej, która jest dostępna tylko dla klienta. Następnie, po zatwierdzeniu, te same zmiany są następnie wprowadzane bezpośrednio do produkcji.

Istnieje jeszcze jedna alternatywa, którą można rzucić: moduł Wdróż . Ma to na celu wykorzystanie Usług, aby relacjonowanie treści było stosunkowo bezbolesne. Ale nie mogę ręczyć za jego skuteczność i nie ma wersji Drupal 7.

W naszym procesie.

1. Mamy skrypt powłoki, który wyciąga db z prod.

2. Używamy Hudsona do przebudowy naszych gałęzi deweloperów / pośredników, aby zsynchronizować gałęzie deweloperów i żywych.

   Ponieważ korzystamy z Git, każde zadanie, które wykonujemy, ma swój własny oddział, a następnie przekazane do kontroli jakości, łączymy je w celu opanowania jako naszego serwera pomostowego do testowania regresji.

   Kiedy master jest gotowy, wykonujemy testową wersję naszego, Release Serverktóra jest repliką live (konfiguracja, sprzęt itp.).

3. Używamy Featuremodułu do wdrażania konfiguracji. Niektóre rzeczy nie są jeszcze obsługiwane przez funkcję, więc używamy hook_update_N, a następnie uruchamiamy updatedb.php lubdrush -vd updb

4. Po wydaniu wykonaj Funkcje revert ( drush fra --yes), aby przywrócić wszystkie zastąpione funkcje.

5. Ponieważ używamy funkcji Boost (przejście do Varnish) i Memcache, musimy wyczyścić pamięć podręczną ( drush cc all).

   Używamy rsync do synchronizacji naszych zdjęć / wideo itp.

Aby przeprowadzić migrację z serwera XAMPP na inny serwer, postępowałem zgodnie z instrukcjami na tej stronie .

Upewnij się, że zachowujesz taką samą strukturę na serwerze produkcyjnym, jak na serwerze programistycznym. Musiałem także edytować niektóre pliki na pulpicie administracyjnym Drupal pod adresem: admin / config / media / file-system

Upewnij się, że ścieżka publicznego systemu plików i katalog tymczasowy mają ustawione prawidłowe lokalizacje.