Aktualizacja PrestaShop bez przestoju: jak to robimy

Większość właścicieli sklepów odkłada aktualizacje z jednego powodu: boją się, że sklep przestanie działać, a oni stracą dzień sprzedaży. Ten strach jest uzasadniony, jeśli aktualizację robi się na żywym sklepie przyciskiem w panelu. Jest nieuzasadniony, jeśli robi się ją według procedury. Poniżej opisujemy naszą, krok po kroku, razem z tym, co robimy, gdy coś idzie nie tak.

Dlaczego aktualizacje psują sklepy

PrestaShop sam w sobie aktualizuje się dobrze. Update Assistant (dawniej 1-Click Upgrade) podmienia pliki, uruchamia skrypty migracji bazy i czyści cache. Problem leży obok: w modułach, które nie są zgodne z nową wersją, w nadpisaniach rdzenia, które zostały stare, w szablonie, który odwołuje się do zmienionych plików. Do tego dochodzi PHP, bo aktualizacja PrestaShop często wymaga też nowszej wersji PHP, a to osobna zmiana z własnymi skutkami.

Jeśli robisz to wszystko naraz na żywym sklepie, każdy błąd widzi klient, a Ty naprawiasz pod presją. Jeśli robisz to na kopii, błędy widzisz tylko Ty i masz czas.

Krok 1: kopia, którą da się odtworzyć

Przed czymkolwiek robimy pełną kopię: baza danych, pliki sklepu, zdjęcia, pliki konfiguracyjne, certyfikaty, zadania cron. Potem odtwarzamy ją na innym serwerze i sprawdzamy, czy sklep z kopii się uruchamia. Kopia, której nikt nie odtworzył, to tylko plik o nazwie backup. Dopiero odtworzona kopia jest planem powrotu.

Krok 2: środowisko testowe

Kopię sklepu stawiamy na subdomenie testowej, zabezpieczonej hasłem i wyłączonej z indeksowania. Ustawiamy na niej docelową wersję PHP, bo chcemy od razu zobaczyć, co nie działa z nowym PHP, a co z nową wersją PrestaShop. Wyłączamy wysyłkę maili do klientów i przestawiamy płatności na tryb testowy, żeby żaden klient nie dostał wiadomości z kopii i żadna integracja nie wysłała zamówienia do magazynu dwa razy.

Na tym etapie środowisko testowe jest wierną kopią produkcji z jedną różnicą: nikt poza nami go nie widzi.

Krok 3: lista modułów i nadpisań

Z panelu eksportujemy listę modułów z wersjami. Dla każdego sprawdzamy trzy rzeczy: czy jest używany, czy autor deklaruje zgodność z docelową wersją i czy jest dostępna aktualizacja. Powstaje tabela, która decyduje o całym harmonogramie.

Stan modułu	Co robimy	Kiedy
Nieużywany	Odinstalowujemy przed aktualizacją	Na kopii, potem na produkcji
Używany, ma wersję zgodną	Aktualizujemy moduł przed aktualizacją rdzenia	Na kopii, test, potem produkcja
Używany, brak zgodnej wersji, autor aktywny	Pytamy autora o termin, czasem czekamy	Przed ustaleniem daty przełączenia
Używany, porzucony przez autora	Szukamy zamiennika albo przepisujemy funkcję	Największa pozycja w kosztorysie
Nadpisanie rdzenia (override)	Sprawdzamy, czy jest potrzebne, przepisujemy na hook	Przed aktualizacją, bo stare nadpisania psują nową wersję

Dopiero po tej tabeli wiemy, czy aktualizacja zajmie dwa dni czy trzy tygodnie i czy w ogóle ma sens w porównaniu z nową instalacją.

Krok 4: aktualizacja na kopii

Na środowisku testowym uruchamiamy Update Assistant. Przy większych sklepach robimy to z linii komend, bo przeglądarka potrafi zerwać połączenie w trakcie długiej migracji bazy. Po zakończeniu przeglądamy dziennik aktualizacji i dziennik błędów PHP, włączamy tryb debugowania i klikamy po sklepie. Zwykle pierwsza próba kończy się listą kilku do kilkunastu problemów. Naprawiamy je, robimy notatkę, co i jak, i powtarzamy aktualizację od świeżej kopii, żeby sprawdzić, czy procedura jest powtarzalna. Dopiero gdy druga lub trzecia próba przechodzi czysto, mamy gotowy scenariusz na produkcję.

Krok 5: testy ścieżki zakupu

Testujemy sklep tak, jak korzysta z niego klient i pracownik, nie tak, jak wygląda. Lista jest zawsze ta sama i zawsze spisana, żeby nic nie umknęło.

• Strona główna, kategoria z filtrami, wyszukiwarka, karta produktu z wariantami, na telefonie i na komputerze.
• Rejestracja, logowanie, odzyskiwanie hasła, edycja adresu.
• Koszyk z rabatem, kodem promocyjnym i darmową dostawą od progu.
• Każdy przewoźnik, każda metoda płatności w trybie testowym, powrót z bramki płatności.
• Maile: potwierdzenie zamówienia, zmiana statusu, faktura w załączniku.
• Panel: lista zamówień, zmiana statusu, wystawienie faktury, zwrot, dodanie produktu z zdjęciem.
• Integracje: synchronizacja stanów z magazynem, eksport zamówień, import z marketplace, zadania cron.
• Adresy URL i przekierowania, mapa strony, dane strukturalne, plik robots.

Krok 6: przełączenie z planem powrotu

Co, jeśli coś się posypie po tygodniu

Nie wszystko wychodzi w pierwszej dobie. Błąd w rzadko używanej metodzie płatności, moduł, który psuje faktury tylko dla firm z zagranicy, zadanie cron, które nie uruchamia się co noc. Dlatego przez dwa tygodnie po aktualizacji trzymamy kopię sprzed aktualizacji w gotowości i codziennie sprawdzamy logi. Po dwu tygodniach, jeśli jest spokój, kopia trafia do archiwum, a sklep do normalnego cyklu opieki.

Na produkcji nie robimy nic, czego nie zrobiliśmy wcześniej na kopii. To cała tajemnica aktualizacji bez przestoju.

Pytania, które słyszymy najczęściej

Czy mogę zaktualizować sklep przyciskiem w panelu bez tego wszystkiego?

Możesz, i przy małym sklepie z kilkoma modułami od renomowanych autorów często się uda. Ryzyko polega na tym, że gdy się nie uda, nie masz dokąd wrócić i naprawiasz na żywo.

Jak długo trwa cała procedura?

Przy zadbanym sklepie na 8.x: dwa do pięciu dni roboczych, z czego przestój dla klientów to kilkanaście minut. Przy sklepie z dziesiątkami modułów i nadpisaniami: dwa do czterech tygodni, nadal z przestojem liczonym w minutach.

Czy w czasie aktualizacji na kopii mogę normalnie sprzedawać?

Tak. Produkcja działa bez zmian. Prosimy tylko, żeby nie instalować w tym czasie nowych modułów, bo wtedy scenariusz z kopii przestaje pasować.

Jak często aktualizować?

Poprawki bezpieczeństwa w ciągu dni od wydania. Wersje pośrednie co kilka miesięcy. Duże wersje, jak 8 na 9, planowo, raz na kilka lat, po przeglądzie modułów.