Magento 2 / Mage-OS / Adobe Commerce

Magento napędza jedne z największych operacji e-commerce w sieci i zasłużenie zyskało opinię platformy wymagającej w utrzymaniu. Dobrze prowadzone, wciąż jest najmocniejszą otwartą platformą dla złożonych katalogów i B2B. Źle prowadzone oznacza kartę produktu ładującą się 12 sekund i koszty hostingu, których nikt nie potrafi uzasadnić. Większość naszych projektów przy Magento zaczyna się od sklepu w tym drugim stanie.

Pracujemy z obiema aktywnie rozwijanymi odmianami platformy:

• Mage-OS: dystrybucja Magento Open Source prowadzona przez społeczność, z własnym procesem wydawniczym i społecznościowym zarządzaniem. Jest celowo zgodna, więc sklep na Mage-OS to nadal sklep na Magento, a istniejące rozszerzenia działają dalej. Nowe otwarte wdrożenia zakładamy tutaj.
• Adobe Commerce: edycja licencjonowana. Opłaca się, gdy naprawdę korzystasz z zarządzanego hostingu w chmurze z SLA albo wsparcia enterprise. Adobe Commerce B2B (konta firmowe, współdzielone katalogi, negocjowane oferty cenowe) to rozszerzenie licencjonowane przez Adobe osobno.

Pracę prowadzi architekt z certyfikatem Adobe Certified Master – Adobe Commerce Architect, najwyższym, jaki Adobe przyznaje dla Commerce, oraz z certyfikatem Hyvä po stronie frontendu. Zapisy weryfikacyjne obu znajdziesz na stronie o nas.

Kiedy Magento jest właściwym wyborem

• Złożone katalogi z wieloma typami produktów, opcjami konfigurowalnymi i regułami cenowymi
• Wymagania B2B: konta firmowe, workflow ofertowy, ceny progowe, akceptacja zamówień
• Konfiguracje multi-store i multi-brand pod jedną administracją
• Istniejąca inwestycja w rozszerzenia i integracje Adobe Commerce

Jeśli żaden z tych punktów Cię nie dotyczy, tańszym rozwiązaniem jest zwykle Shopify i usłyszysz to od nas już na pierwszej rozmowie.

Problemy, z którymi zgłaszają się do nas klienci

• Karty produktów ładujące się trzy sekundy mimo skonfigurowanego Varnisha i Redisa
• Checkout, który nie wytrzymuje obciążenia w kampanii, podczas gdy serwery działają przy 10% obciążenia
• Czterdzieści zainstalowanych rozszerzeń, połowa porzucona przez dostawców, a dwa z nich w konflikcie o ten sam observer
• Indeksery i crony w stanie, w którym sklep pokazuje stany magazynowe, których magazyn nie ma
• Aktualizacja odkładana tak długo, że każda łatka bezpieczeństwa stała się osobnym projektem

Przykłady awarii, które naprawiliśmy

Z dziesięciu lat pracy przy Magento, na których opiera się ta praktyka, anonimowo:

• Rejestracje klientów przestały działać w weekend, bo tabela jednego z rozszerzeń wyczerpała wszystkie 4,29 miliarda identyfikatorów auto-increment, zawierając zaledwie pół miliona wierszy. Hotfix na BIGINT przywrócił rejestracje w ciągu godziny, a nadpisanie schematu sprawiło, że poprawka utrzymuje się mimo aktualizacji.
• Zamówienia za pobraniem zaczęły po aktualizacji wymagać płatności kartą: migracja schematu przebudowała tabelę i przesunęła ID wierszy, których stary moduł używał jako zaszytych na sztywno stałych. Znalezione przez porównanie surowych tabel między środowiskami.
• Stan dostępny do sprzedaży przez miesiące spadał poniżej rzeczywistego. Konektor marketplace’u zmieniał numery zamówień już po założeniu rezerwacji magazynowych, więc MSI nie mogło ich zwolnić. Dowiedliśmy tego anti-joinami na metadanych rezerwacji, naprawiliśmy łatką u dostawcy i cronem czyszczącym dane.
• Adresy przestały się zgadzać w ERP, bo zabezpieczenie Magento przed CSV injection bez ostrzeżenia dodaje spację przed każdą wartością zaczynającą się od „+”, czyli także przed numerami telefonów. Zdiagnozowane w kodzie źródłowym frameworka, naprawione composer patchem.
• Upload mediów działał na stagingu, a na produkcji nie. Eliminacja hipotez doprowadziła do jednego nieaktualnego wiersza konfiguracji, a samonaprawiająca się poprawka danych zagwarantowała, że problem nie wróci.

Co robimy

• Audyty wydajności i przebudowy storefrontu. Domyślnie rekomendujemy Hyvä: wymienia cały zastany stack frontendowy i w naszych własnych pomiarach podnosi wynik wydajności Lighthouse powyżej 90. PWA Studio albo pełny headless tam, gdzie sytuacja naprawdę tego wymaga.
• Moduły na zamówienie i integracje z ERP, PIM, fulfillmentem, płatnościami i marketplace’ami, pisane idempotentnie i obserwowalnie, bo to w warstwie integracji Magento najczęściej dochodzi do awarii.
• Aktualizacje wersji, w tym ratowanie sklepów na Magento 1, migracje do Mage-OS i ograniczanie ryzyka aktualizacji między wersjami głównymi, z pełnym audytem rozszerzeń przed wprowadzeniem jakichkolwiek zmian.
• Długoterminowe wsparcie operacyjne: łatki bezpieczeństwa, monitoring, strojenie cache’a i inżynier on-call na ten dzień, w którym zapełni się tabela blokad w bazie. Wszystko w formie miesięcznego retainera, z DevOps i infrastrukturą w tle.

Jak zwykle zaczyna się współpraca

Dla działającego sklepu naturalnym punktem wyjścia jest audyt wydajności: stała, z góry znana cena, realne pomiary i lista poprawek ułożona według priorytetów, którą wykona Twój własny zespół. Dla sklepu wciąż na Magento 1 albo kilka wersji głównych wstecz zaczynamy od analizy migracyjnej: co przechodzi dalej, co piszemy od nowa i jak wygląda plan przełączenia. W obu przypadkach zakres i cenę znasz na piśmie, zanim cokolwiek trafi na fakturę.