Niektóre moduły mają procedury deinstalacji. Które zazwyczaj usuwają tabele bazy danych dla tego modułu, zmienne z tabeli zmiennych i ustawienia narodowe wprowadzone przez ten moduł. Te procedury działają w .installtym module.
Dlatego nie można ich uruchomić bez obecności tego modułu. Oto nasze aktualne kroki. Moje pytanie brzmi: czy można to zrobić prościej i skuteczniej? Powiedzmy, że usuwam moduł foo_bar.
- W RCS przygotuj nową wersję, w której:
- Wszystkie css i przesłonięcia motywów, które używają lub budują na foo_bar są usuwane.
- Wszystkie css i przesłonięcia motywów dla modułów w zależności od foo_bar są usuwane.
- Przekaż to wydanie do akceptacji. Przetestuj deïnstallation (od administratora / modułów) przy użyciu najnowszej kopii produkcyjnej bazy danych.
- Jeśli wszystko pójdzie dobrze, wdróż nową bazę kodu w środowisku produkcyjnym i usuń tam foo_bar i jego zależności. Spowoduje to wywołanie dezinstalacji w różnych modułach, czyszcząc bazę danych.
- W RCS (git) przygotuj nową wersję, w której kod zostanie faktycznie usunięty.
- Zastosuj to do akceptacji, gdy testujemy, czy nic przypadkowo nie zależało od tego (niektóre brzydkie moduły lub funkcje motywu zawierają pliki bezpośrednio z innych modułów. W szczególności CSS, JS lub pliki obrazów).
- Jeśli zostanie zaakceptowany, wdróż nową wersję do produkcji. produkcja ma teraz czystą bazę danych i czystą bazę kodów .
Problem, którego nie widzę jak rozwiązać, polega na tym, że zawsze wymaga to dwóch wydań. Ponieważ w Drupal wydanie wymaga, aby strona była offline, oznacza to dwa razy przestoje w celu usunięcia jednego modułu. Wymaga także dwóch procedur wydania, które w profesjonalnych środowiskach hostingowych mogą być bardzo drogie, czasochłonne lub frustrujące.
Jeśli usuniemy moduł z bazy kodu w pierwszej iteracji, nie będziemy mogli uruchomić haków deinstalacyjnych, utrzymując wiele kłopotów w bazie danych; nie tylko kilka tabel, ale głównie zmienne i ustawienia regionalne. Jeśli nie usuniemy modułu z bazy kodu, oznacza to, że baza kodu powiększy się o przestarzały, nieużywany kod; nie powoduje to narzutu wydajności, ale utrudnia utrzymanie kodu.
Jak sobie z tym radzisz?
[edytuj: często dodawano uwagę, że wdrożenie jest trudną procedurą]
źródło
Odpowiedzi:
Zachowaj ostrożność przy synchronizowaniu bazy danych i kodu; jak wspomniałeś w swoim pytaniu, moduły do odinstalowania muszą pozostać w bazie kodu, dopóki ich haki dezinstalacyjne nie zostaną uruchomione w bazie danych na żywo. Jest to ograniczenie Drupala, którego sam przepływ pracy ściągania gitów nie rozwiąże.
Zalecam, aby zamiast próbować dostosować proces, zamiast szukać sposobów na ograniczenie przestojów wymaganych do przetworzenia aktualizacji. Poleciłbym utworzenie wieloetapowego środowiska testowego ying / yang, aby rozwiązać ten problem. nb Nie korzystałem ze skryptów zawartych w poprzednim linku; Może chcesz ustawić rzeczy się inaczej, po tej samej idei, że można zamiana swoje sceniczne na żywo i miejsca podczas instalacji.
Postępuj zgodnie z procedurą opisaną w pytaniu, wprowadzając następujące zmiany:
za. Synchronizuj z programisty na scenę (yang) jak zwykle. Przetestuj, wykonując deinstalację modułów, które chcesz usunąć, a następnie usuń kod itp. Uwagi do przepływu pracy Git: utwórz znacznik lub zanotuj hashid różnych stanów kodu: wszystkie moduły na miejscu przed deinstalacją, moduły kodu usunięte, twoje zastępuje & c. usunięte itp. w razie potrzeby. Być może potrzebne są tylko dwa odniesienia.
b. Po zakończeniu testów i zaakceptowaniu przywróć kod na scenie (yang) do stanu na żywo (ying).
do. Przygotuj witrynę aktywną (ying) do aktualizacji, wyłączając możliwość zmiany treści w systemie przez dowolnego użytkownika. Zazwyczaj aktualizacja sql do tabeli uprawnień będzie tutaj. W tym momencie użytkownicy nadal będą mogli czytać treści w aktywnej witrynie, ale otrzymają błąd odmowy uprawnień, jeśli spróbują zaktualizować zawartość. (Jeśli jesteś fajny, być może możesz zmienić odmowę obsługi, aby wydrukować odpowiednie powiadomienie, że funkcja jest chwilowo niedostępna).
re. Teraz przenieś bazę danych live (ying) z powrotem do bazy danych stage (yang), wyłączając tabelę uprawnień z aktualizacji.
mi. Powtórz krok a. jeszcze raz. Jeśli masz pod ręką hashtagi, powinno być łatwo przywrócić do stanu, w którym istnieją moduły do usunięcia, uruchom haki dezinstalacyjne w bazie danych, a następnie przejdź z powrotem do stanu kodu, w którym elementy z kroku 1 zostały scalone z powrotem w.
fa. Jesteś teraz gotowy, aby zamienić ying i yang. Zrób to, dostosowując dyrektywy konfiguracyjne Apache. Pamiętaj, że jeśli wykonasz
/etc/init.d/apache restart, niektóre połączenia mogą zostać porzucone, ale/etc/init.d/apache reloadpozwolą na czystą zamianę.sol. Życie to teraz „yang”; tabela uprawnień jest tutaj niezmodyfikowana, więc użytkownicy mogą tworzyć treści. Jeśli zautomatyzujesz kroki e. i f. niedostępny czas powinien być bardzo krótki.
h. Wciśnij na żywo (yang) z powrotem na scenę (ying), zarówno kod, jak i bazę danych - lub w razie potrzeby wypchnij z dev. Teraz masz czyste środowisko gotowe do następnej iteracji.
źródło
if (module_exists('removeme')) { ... }. Wdróż ten kod. Jeśli przetestujesz i potwierdzisz, że usunięcie modułu nie psuje już kodu niestandardowego, uprości to wdrożenie. Nadal zaleca się wykonanie kroku wyłączania w witrynie, która nie jest aktywna, ale być może nieco zawęzi okno. Nie sądzę, że niestandardowy hak aktualizacji sprawi, że bezpieczniej będzie wyłączyć moduł na żywo.