Skylotec

Decyzja o platformie zapadła, zanim dołączyliśmy. Skylotec nie szukał doradcy do wyboru systemu, lecz niezawodnego partnera wdrożeniowego. Ostatecznie przesądziły dwie rzeczy. Po pierwsze, pierwsze projekty strony głównej – ambitne, z animacjami i wielobarwną, ruchomą typografią, technicznie dalekie od trywialnych. Po drugie, i to było dla Skylotec ważniejsze, kilka spotkań, na których wyjaśniliśmy, jak pracujemy.

Skylotec bardzo uważnie przygląda się praktyce programistycznej i software delivery. Jak zorganizowany jest cykl życia, jak kod trafia na produkcję, jak wygląda zapewnienie jakości. Nasze procesy spełniły ich oczekiwania, a częściowo je przekroczyły. To, że agencję ocenia się po tych pytaniach, a nie tylko po prezentacji ofertowej, zdarza się rzadziej, niż można sądzić.

Oprócz Magento, dotychczasowej platformy, Skylotec porównał kilka systemów klasy enterprise. Decydujące były trzy kryteria: architektura multi-tenant, podejście API-first do głębokiej integracji z ERP Microsoft Dynamics oraz elastyczne funkcje content commerce. W biznesie B2B Skylotec indywidualne ceny i warunki klientów muszą pochodzić z ERP – to był warunek konieczny.

Wybór padł na Shopware 6 Evolve, ponieważ ta edycja pokrywa kluczowe wymagania już w standardzie. Należą do nich natywne funkcje B2B, takie jak zapytania ofertowe (request for quote), szybkie zamówienia i loginy dla przedstawicieli handlowych.

Dużą zaletą jest koncepcja kanałów sprzedaży w Shopware. Skylotec prowadzi dzięki niej główną stronę internetową i główny sklep B2B, a także osobną stronę i dodatkowy sklep B2B dla segmentu outdoor – wszystko na tej samej instancji. Dzięki Rule Builderowi i zintegrowanemu CMS zespół zarządza w jednym miejscu uprawnieniami dostępu do produktów, treściami dla grup docelowych i regułami B2B dla obu obszarów biznesowych.

Pierwszy commit pojawił się 22 lipca 2024 r. o 15:26. Soft launch odbył się w lutym 2025 r., pełny go-live w marcu 2025 r. Zespół tworzyli dwaj backend developerzy, jeden frontend developer, kierownik projektu, QA i DevOps.

Relaunchu z trzema kanałami sprzedaży nie da się przełączyć jednego dnia. Stąd podejście etapowe: najpierw łagodny start, obserwacja, poprawki, a potem pełne przekazanie.

Trzy większe. ERP Microsoft Dynamics podłączyliśmy przez interfejsy REST. PIM, system iPIM, jest zintegrowany przez platformę integracji danych. Do tego dochodzi media service dla dokumentów, gwarancji i instrukcji obsługi, osadzony w sklepie za pomocą JavaScriptu.

Właściwa praca nie polegała na pojedynczej integracji, lecz na modelu danych. Wszystkie trzy systemy zasilają Shopware, a ich struktury nie pasują automatycznie do struktur Shopware. Przykład: PIM Skylotec odwzorowuje produkty inaczej, niż Shopware rozumie produkty i warianty. Rozwiązujemy to tak, że nawet pojedynczy produkt otrzymuje technicznie jeden wariant – pragmatycznie, ale model pozostaje spójny. Takie dostosowania trzeba było wprowadzać na poziomie importu, osobno dla każdego systemu.

Projekt opierał się na ścisłej współpracy z technicznymi osobami kontaktowymi u wszystkich trzech dostawców. I na tym, że każda zmiana trafiała najpierw na system stage, a dopiero potem na produkcję.

Indywidualne cenniki klientów. Skylotec kalkuluje ceny dla setek grup klientów z bardzo drobnym zróżnicowaniem. Mechanizm, który Shopware oferuje w tym celu, działa dobrze przy niewielkiej liczbie klientów – przy tysiącach obliczanie reguł dochodzi do granic możliwości.

Rozwiązaliśmy to dodatkową warstwą cache dla obliczonych cen. Jest ona przebudowywana przy każdej synchronizacji aktualizacji cen, zamiast przeliczania przy każdym wyświetleniu strony. Ciekawy epilog: w Shopware 6.7 podobna funkcja trafiła do standardu i problem zniknął. To typowe dla szybko rozwijającej się platformy – budujesz coś, bo tego brakuje, a wydanie później to już jest.

Są to dwa kanały B2B – jeden dla sektora profesjonalnego, jeden dla outdooru i wspinaczki – oraz kanał B2C. Każdy z własną grupą docelową, własną logiką cenową i własnymi zachowaniami użytkowników.

Kluczem były feature toggles. Większość funkcji znajduje się już w kodzie produkcyjnym, ale jest wyłączona. Biznes decyduje, kiedy funkcja zostaje aktywowana i dla kogo – tylko B2B, tylko B2C, zgodnie z harmonogramem. Dzięki temu relaunch nie jest jednym wydarzeniem, lecz sekwencją małych przełączników. Każdy kanał mógł wystartować osobno, praktycznie bez przestoju, a jeśli coś nie działało zgodnie z oczekiwaniami, powrotem był toggle, a nie deployment.

Skylotec sprzedaje międzynarodowo – w Europie, USA, Australii i nie tylko. Sklep działa w pięciu językach: angielskim, niemieckim, hiszpańskim, francuskim i włoskim. W połączeniu z trzema kanałami sprzedaży powstaje macierz, w której niemal każda funkcja rodzi pytanie, dla jakiego kanału, w jakim regionie i w jakim języku obowiązuje. To mniej problem techniczny, a bardziej kwestia staranności.

To było jedno z ciekawszych zadań w projekcie. Wdrażamy na stack Kubernetes, który obsługuje Skylotec. Obie strony miały wypracowane rutyny, które się nie pokrywały. Takiej sytuacji nie rozwiązuje się, gdy jedna strona po prostu narzuca swoje.

Efektem jest model współdzielonej odpowiedzialności: Kubernetes Skylotec zapewnia infrastrukturę dla aplikacji sklepu, a konfiguracja i dostarczanie aplikacji odbywają się według naszego podejścia. Zespół DevOps Skylotec zachowuje pełny wgląd w elementy i komponenty, a my odpowiadamy za to, jak nasza aplikacja jest dostarczana i instalowana. Obie strony widzą, co się dzieje, i nikt nie musi przejmować sposobu pracy drugiej strony.

Do nadzoru nad aplikacją stawiamy na stały monitoring z alertami oraz application performance monitoring, aby wykrywać problemy z wydajnością na poziomie kodu, zanim ujawnią się w działaniu.

Towarzyszyliśmy migracji środowiska Kubernetes od hyperscalera do europejskiego dostawcy hostingu. Naszą standardową platformą jest AWS, ale budujemy rozwiązania tak, aby działały bez vendor lock-in – to nie hasło marketingowe, lecz coś, co sprawdza się właśnie w takich momentach.

Migracja przebiegła bezproblemowo, głównie dlatego, że przed aplikacją działa CDN, którego konfiguracja była wystarczająco elastyczna, by złagodzić zmianę. Migracja infrastruktury w trakcie działania to najuczciwszy test tego, czy architektura jest naprawdę przenośna. Ta go zdała.

Shopware jest wydajny i szybko się rozwija. Mimo to trafia się na brakujące funkcje lub miejsca, w których wydajność mogłaby być lepsza.

Konkretnie trzy punkty. Cenniki już wspomniałem – do wersji 6.7 był to realny problem. Brakowało nam pakietów produktów (bundles). A model danych produkt–wariant nie pasuje do każdego PIM, co wymusza obejścia.

Tym, co do dziś pozostaje niewygodne, jest instalacja pluginów i templating. Dostarczamy deterministycznie, przez kontenery i z systemami plików tylko do odczytu – z perspektywy operacyjnej to słuszne, ale wiele rzeczy staje się mniej wygodnych. Kto jest przyzwyczajony do kliknięcia pluginu w backendzie Shopware i wypróbowania go, musi u nas poczekać, aż przejdzie przez pipeline. Od developmentu do produkcji trwa to około 20 minut. Jak na deployment to szybko. Dla kogoś, kto chce przetestować pomysł, to długo. Ten konflikt między niezawodnym dostarczaniem a szybkim eksperymentowaniem nie jest rozwiązany i nie jestem pewien, czy da się go w pełni rozwiązać.