Migracja sklepu Shopware 6 wymaga porównania serwera samodzielnie zarządzanego z dostawcą zarządzanym. Wybór modelu wpływa na zakres prac, odpowiedzialność, testy, kontrolę nad wdrożeniem oraz utrzymanie sklepu. Przed zmianą hostingu zaplanuj nie tylko przeniesienie plików i bazy danych, ale także konfigurację wyszukiwania, zadań cyklicznych, kolejek, cache oraz sposobu wdrażania zmian.
Spis treści
Od czego zacząć porównanie hostingu Shopware 6?
Najpierw spisz elementy obecnego środowiska Shopware 6. Ta lista powinna obejmować:
- bazę danych sklepu,
- pliki aplikacji i katalog mediów,
- konfigurację wyszukiwania, w tym Elasticsearch lub OpenSearch,
- zadania cykliczne, takie jak cron,
- queue workers, czyli procesy obsługujące kolejki zadań,
- cache aplikacji i cache używany przed aplikacją,
- procedurę wdrażania zmian oraz możliwość ich wycofania.
Hosting jest jednym z elementów całkowitego kosztu utrzymania Shopware, obok pozostałych kosztów technicznych i operacyjnych. Takie ujęcie kosztów opisano w analizie Shopware 6 Costs: Licenses, Hosting & Full TCO.
Serwer samodzielnie zarządzany: większa kontrola i pełna odpowiedzialność
Serwer samodzielnie zarządzany daje zespołowi kontrolę nad środowiskiem, konfiguracją usług i procesem wdrażania. Może to być właściwy wybór, gdy zespół zna wymagania Shopware 6 i chce samodzielnie decydować o konfiguracji wyszukiwania, kolejek, cronów, cache oraz wdrożeń.
Podczas migracji zespół musi wtedy przygotować cały plan techniczny. Obejmuje on eksport i import bazy danych, przeniesienie mediów, odtworzenie usług wyszukiwania, konfigurację zadań cyklicznych i queue workers oraz sprawdzenie cache po przełączeniu sklepu. Odpowiedzialność obejmuje także kolejność wdrożenia i reakcję na problemy po migracji.
Ten model zapewnia swobodę konfiguracji, ale zwiększa udział pracy operacyjnej po migracji. Każda zmiana w aplikacji, konfiguracji lub infrastrukturze wymaga ustalonego procesu testów i wdrożenia.
Dostawca zarządzany: mniej operacji po stronie zespołu sklepu
Przy dostawcy zarządzanym część zadań infrastrukturalnych może zostać objęta obsługą dostawcy. Przed migracją trzeba jednoznacznie ustalić, kto odpowiada za bazę danych, media, Elasticsearch lub OpenSearch, cron, queue workers, cache, wdrożenia i kopie zapasowe.
Najważniejsza różnica nie polega wyłącznie na przeniesieniu danych. Dotyczy także podziału odpowiedzialności po uruchomieniu sklepu. Sklep potrzebuje procedury kontaktu w razie błędu, planu zmian i informacji o tym, które elementy można konfigurować samodzielnie.
Przy wyborze dostawcy porównaj zakres zarządzania z wymaganiami sklepu.
Jak zaplanować transfer bazy danych i mediów?
Baza danych i media powinny być traktowane jako dwa osobne elementy migracji. Baza zawiera dane operacyjne sklepu, a katalog mediów obejmuje pliki wykorzystywane przez produkty i treści. Plan transferu powinien określać kolejność kopiowania, moment wykonania końcowej synchronizacji oraz sposób sprawdzenia kompletności danych.
- Utwórz kopię bazy danych i plików przed rozpoczęciem zmian.
- Przygotuj środowisko docelowe i odtwórz w nim aplikację oraz wymagane usługi.
- Przenieś bazę danych i katalog mediów.
- Skonfiguruj wyszukiwanie, cron, queue workers i cache zgodnie z docelowym środowiskiem.
- Wykonaj test sklepu na środowisku docelowym.
- Przeprowadź końcową synchronizację danych, a następnie zaplanuj przełączenie ruchu.
Przed zmianą przygotuj możliwość powrotu do poprzedniego środowiska. Jest to szczególnie ważne, gdy sklep przyjmuje zamówienia lub dane zmieniają się podczas kopiowania.
Wyszukiwanie, kolejki i cron po migracji
Shopware 6 powinien być sprawdzony nie tylko przez otwarcie strony głównej. Test obejmuje także wyszukiwanie produktów, działanie zadań cyklicznych, przetwarzanie kolejek i odczyt plików mediów. Jeżeli sklep korzysta z Elasticsearch lub OpenSearch, usługa wyszukiwania musi być uwzględniona w planie migracji i testach.
Na serwerze samodzielnie zarządzanym konfigurację tych elementów przygotowuje zespół sklepu. U dostawcy zarządzanego trzeba potwierdzić, czy należą do zakresu obsługi i jak zgłasza się problemy. Samo skopiowanie plików aplikacji nie zastępuje sprawdzenia tych usług.
Wdrożenia, cache i ryzyko niedostępności
Przed przełączeniem ustal, jak będą wdrażane zmiany Shopware 6 po migracji. Sprawdź, czy procedura obejmuje test, czyszczenie lub odświeżenie cache oraz możliwość cofnięcia wdrożenia.
Ryzyko niedostępności zależy od kolejności prac, końcowej synchronizacji i poprawności konfiguracji środowiska docelowego. Aby je ograniczyć, zaplanuj migrację poza okresem największej liczby zmian w sklepie, wykonaj testy przed przełączeniem i zachowaj działające środowisko poprzednie do czasu potwierdzenia poprawności.
Skalowanie i całkowita odpowiedzialność
W modelu samodzielnym zespół odpowiada za dobór zasobów, konfigurację i reakcję na wzrost obciążenia. W modelu zarządzanym trzeba sprawdzić, jak dostawca obsługuje zmianę zasobów i jakie działania pozostają po stronie sklepu.
Elastyczny Web Hosting dhosting automatycznie dopasowuje zasoby do aktualnego ruchu i obciążenia. Przy większym ruchu może zwiększać moc CPU, RAM i przestrzeń, a po spadku obciążenia wracać do bazowego poziomu. Taki model zmienia sposób planowania zasobów, ale nie zastępuje testów aplikacji, wyszukiwania, kolejek i cache.
FAQ
Czy migracja obejmuje tylko bazę danych i pliki?
Nie. Plan powinien obejmować także media, wyszukiwanie, cron, queue workers, cache i proces wdrażania. Każdy z tych elementów wpływa na działanie sklepu po przełączeniu.
Kiedy wybrać serwer samodzielnie zarządzany?
Ten model pasuje do zespołu, który chce kontrolować konfigurację i ma możliwość samodzielnej obsługi środowiska Shopware 6, w tym wdrożeń, usług wyszukiwania, kolejek i zadań cyklicznych.
Kiedy rozważyć dostawcę zarządzanego?
Wtedy, gdy sklep chce przekazać część prac infrastrukturalnych dostawcy. Przed wyborem trzeba ustalić dokładny zakres obsługi oraz odpowiedzialność za każdy element migracji i późniejszego utrzymania.
Najbezpieczniejszy kolejny krok to przygotowanie tabeli odpowiedzialności dla bazy, mediów, wyszukiwania, cronów, queue workers, cache, wdrożeń i skalowania. Na jej podstawie można porównać oba modele bez pomijania zadań, które pojawiają się po samym transferze plików.