Wszystko, co musisz wiedzieć o upgrade do Pimcore X

Z tego artykułu dowiesz się:

• Dlaczego w ogóle warto robić aktualizację aplikacji do Pimcore X?
• Jakie ryzyka wiążą się z taką zmianą?
• Z jakich etapów składa się proces migracji?
• W jaki sposób, jako klient, możesz się przygotować do takiego procesu?

3 powody, by zaktualizować Twój system Pimcore do wersji X

Jeśli korzystasz z Pimcore w wersji 5, aktualizacja jest dla Ciebie wręcz niezbędna. Ta edycja nie jest już utrzymywana przez twórców. Dla edycji 5 i 6 Pimcore'a nie są przygotowywane już aktualizacje bezpieczeństwa, które usuwałyby nowo znalezione luki. Jeśli korzystasz z takiej wersji oprogramowania, możesz przejść na płatną wersję LTS (Long Term Support). Pamiętaj jednak, że wymaga to płatnej subskrypcji.

Poniżej znajdziesz najważniejsze argumenty stojące za tym, by przeprowadzić upgrade do Pimcore X.

1. Przestarzałe oprogramowanie stanowi zagrożenie dla bezpieczeństwa.

Jeśli w Twojej wersji systemu wykorzystane są nieaktualne biblioteki i rozszerzenia, może oznaczać to luki bezpieczeństwa. Tak będzie np. we wspomnianej wersji 5, która straciła aktualizacje 9.12.2019, oraz 6, która straciła je 23.06.2021.

Jeśli korzystasz ze starszego wydania systemu, musisz liczyć się też z tym, że może być w nim używana wersja PHP bez aktualizacji bezpieczeństwa.

2. Wstrzymując się z aktualizacją, zwiększasz swój dług technologiczny.

Może to oznaczać sytuację, w której pozornie wybierasz tańszą opcję, czyli nie inwestujesz w aktualizację systemu, ale w dłuższej perspektywie będzie to wymagało od Ciebie większego nakładu środków. Usunięcie nagromadzonego długu technologicznego, który przenika całą aplikację, będzie droższe niż przeciwdziałanie mu na bieżąco. Może się okazać, że czas potrzebny na aktualizację do najnowszej wersji można było spożytkować na upgrade.

Z poziomu zespołu zatrudnionego w firmie – programiści zwykle chętniej aplikują do organizacji realizujących projekty, które są dla nich atrakcyjne pod kątem wyzwań. Przychylniej patrzą na nowości technologiczne niż legacy code. Dodatkową przesłanką do upgrade’u jest także brak dokumentacji technicznej do przestarzałych wersji oprogramowania czy ścieżek upgrade’u.

Im szybciej wykonasz upgrade, tym niższe koszty i mniej pracy potrzebnej do jego przeprowadzenia. W przeciwnym razie musisz liczyć się ze spadkiem wydajności oprogramowania i wzrostem ryzyka błędów.

3. Decydując się na pozostanie przy starej wersji oprogramowania, blokujesz sobie nowe możliwości.

Nie skorzystasz z aktualizacji funkcji czy zupełnie nowych rozwiązań wprowadzanych przez Pimcore, bo nie będziesz mógł np. instalować nowych rozszerzeń. Oznacza to, że choć pierwotnie zdecydowałeś się na elastyczne rozwiązanie o dużych możliwościach, trwając przy jego starszej wersji, zamykasz się do limitowanego (i, jak już pisaliśmy, coraz mniej bezpiecznego) zestawu funkcji.

Wiesz już, dlaczego warto zaktualizować swój system Pimcore. Taka operacja wiąże się naturalnie z pewnymi wyzwaniami. Możesz się jednak na nie przygotować, zawczasu nimi zarządzać, a w konsekwencji – uniknąć potencjalnego ryzyka.

Jakie ryzyka warto przewidzieć przy okazji upgrade’u?

• Warto mieć świadomość, że migracja zakładająca przechodzenie przez kilka wersji jest trudniejsza. Przykładem może być przejście z Pimcore 5 do 6, potem z Pimcore 6 do Pimcore X. Tutaj wiele zależy też od wariantu migracji (3 możliwe opisaliśmy poniżej).
• Poziom trudności upgrade’u będzie proporcjonalny do złożoności projektu. Im więcej rozszerzeń, im bardziej kod dopasowany do potrzeb klienta, im większy dług technologiczny, tym więcej pracy i większe ryzyko.
• Jeśli projekt nie ma dokumentacji i testów automatycznych, możliwa jest niezauważona regresja funkcji.
• Przy migracji może nastąpić utrata spójności bazy danych. To bardzo duże ryzyko biznesowe, zwłaszcza biorąc pod uwagę cele wdrożenia Pimcore w przedsiębiorstwie. Jednak jeśli zachowane zostaną kopie zapasowe i przeprowadzone solidne testy, zagrożenie to będzie zminimalizowane.
• Mogą pojawić się też problemy wynikające ze zmian w samym Pimcore.

Po pierwsze: rozszerzenia Pimcore, które posiadasz, mogą nie być już aktualizowane. W takiej sytuacji mamy 3 wyjścia: sami próbujemy aktualizować te rozszerzenia, rezygnujemy z nich albo odkładamy upgrade do czasu wydania aktualizacji rozszerzeń przez ich autorów.

Po drugie: kod napisany dla poprzednich wersji Pimcore wskutek upgrade’u może stać się przestarzały. W takiej sytuacji potrzebny jest refaktoring (czyli proces restrukturyzacji istniejącego kodu).

• Warto brać też pod uwagę, że ścieżka upgrade’u przygotowana przez Pimcore nie jest doskonała i aktualizację trzeba będzie dostrajać samodzielnie. Tutaj jednak znów z pomocą przychodzą Ci nasi specjaliści.

Jak wygląda proces migracji?

Szczegóły zależą od tego, na jaki wariant aktualizacji się zdecydujesz (3 możliwe opisaliśmy dalej). Jednak co do zasady podstawowe kroki to:

• Downtime, czyli wyłączenie serwera produkcyjnego. Wykonuje się go po to, aby nie nastąpiła utrata danych pochodzących z nowych aktywności użytkowników.
• Koordynacja upgrade’u z administratorami infrastruktury, np.: przełączenie wersji PHP, monitoring zasobów serwera, utworzenie kopii zapasowej bazy danych.
• Stworzenie kopii zapasowych danych i plików (tzw. assets).
• Opcjonalnie: uruchomienie równoległej infrastruktury różniącej się wersją oprogramowania, np. różne wersje PHP i Elasticsearch. (Podwójna infrastruktura daje Ci możliwość powrotu do poprzedniej wersji w razie niepowodzenia upgrade’u).
• Weryfikacja procesu, testy, poprawki.
• W razie niepowodzenia: przywrócenie starej wersji z kopii zapasowej bazy.

Możliwe warianty upgrade’u

Aktualizację do Pimcore X możesz przeprowadzić na 3 sposoby. Poniżej opisujemy wady i zalety każdego z nich.

Upgrade na serwerze produkcyjnym

Oznacza aktualizację na serwerze, na którym docelowo znajduje się Twoja platforma. To praca na „żywym organizmie”.

Zaletą jest w tym przypadku tzw. aktualizacja in-place (dotychczasowy kod i struktura danych jest bezpośrednio aktualizowana). Dla Ciebie oznacza niższe koszty dodatkowej infrastruktury potrzebnej w przypadku upgrade’u – tu po prostu jej nie potrzebujesz.

Taki sposób niesie ze sobą jednak ryzyko utraty spójności danych. Musisz też być gotowy na dłuższy downtime (czas wyłączenia aplikacji, kiedy użytkownicy nie mogą z niej korzystać).

Dobrymi praktykami będą tu robienie kopii zapasowych oraz ostrożne i wielokrotne testy, najlepiej na środowisku najbardziej zbliżonych do produkcyjnego (staging).

Ten wariant wymaga synchronicznej pracy z administratorami.

Lokalny upgrade bazy danych i import efektu na produkcję

Oznacza to, że aktualizacja jest przeprowadzana poza środowiskiem produkcyjnym, a następnie przenoszona na serwer docelowy (produkcyjny).

Tutaj możemy mówić o większym bezpieczeństwie aktualizacji: ryzyko uszkodzenia bazy danych jest minimalne, ponieważ proces można powtórzyć.

W takiej sytuacji jednak downtime aplikacji będzie dłuższy („produkcja” na czas prac związanych z aktualizacją musi być wyłączona). Jeśli istnieją różnice między środowiskiem produkcyjnym i lokalnym, testy będą nieco mniej miarodajne.

Ten wariant nie wymaga dużego zaangażowania administratorów.

Eksport danych ze starej wersji Pimcore do nowej wersji

W tym wypadku aktualizacja odbywa się poprzez przeniesienie danych z jednego systemu do drugiego – za pomocą plików.

Aktualizacja aplikacji może tu być przeprowadzona z wersji obecnej do najnowszej (np. z wersji 5 do 10), a nie stopniowo.

To dobry wariant dla małych i prostych projektów, nie nadaje się jednak do większych projektów (gdzie eksport-import byłby zbyt pracochłonny).

Zamiast zakończenia: w jaki sposób możesz się przygotować do takiego procesu?

• Zaplanuj budżet proporcjonalny do tego, jak złożona jest Twoja aplikacja oraz z której wersji będzie przeprowadzana aktualizacja. Możesz zastanawiać się, skąd w ogóle zaczerpnąć taką wiedzę – co ważne, jesteśmy tu po to, by pomóc Ci przeprowadzić estymacje w czasie etapu przygotowawczego do aktualizacji.
• Bądź gotów na testy akceptacyjne po swojej stronie. Zabezpiecz czas u odpowiednich osób z Twojego zespołu (np. content managerów) – tak aby testy nie kolidowały z ich codziennymi obowiązkami.
• Przygotuj środowiska testowe. Najlepiej jedno do prac bieżących, a drugie do upgrade’u. Pamiętaj, że aktualizacja to długotrwały proces i najczęściej prace trwają równolegle na starej i nowej wersji systemu.