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 żywymi gałęziami platformy:

• Mage-OS: fork prowadzony przez społeczność, który uniezależnia przyszłość platformy od roadmapy Adobe i wydaje szybciej. Nowe otwarte wdrożenia trafiają dziś tam, a nie na stockowe Magento Open Source; to do forka przeniosła się wydawnicza energia społeczności.
• Adobe Commerce: licencjonowana edycja chmurowa z pakietem B2B, page builderem i enterprise’owymi SLA.

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. Oba sprawdzisz na LinkedInie.

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 kampanii, podczas gdy serwery pracują na 10% obciążenia; wąskie gardło prawie zawsze leży w kodzie albo w konfiguracji cache’a, a nie w sprzęcie
• 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

Ze sklepów, przy których pracowaliśmy przez lata, bez nazw:

• 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 przeżywa aktualizacje.
• Zamówienia za pobraniem zaczęły po aktualizacji żądać 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ący się data patch zagwarantował, że problem nie wróci.

Co robimy

• Audyty wydajności i przebudowy storefrontu. Domyślnie rekomendujemy Hyvä: wymienia cały zastany stack frontendowy i zwykle wprowadza wyniki Lighthouse w okolice 90. PWA Studio albo pełny headless tam, gdzie przypadek 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ą pod spodem.

Jak zwykle zaczyna się współpraca

Dla działającego sklepu naturalnym wejściem 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 dowolny zespół. Dla sklepu wciąż na Magento 1 albo kilka wersji głównych do tyłu 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ę.