Sylius za kulisami: Test Application

Kiedy Sylius przeszedł na wersję 2.0, pojawił się poważny problem z aktualizacją wtyczek i pakietów tworzonych przez developerów, często w wolnym czasie po godzinach pracy.

Wyzwanie szybko stało się jasne: semantyczne wersjonowanie wymaga częstych aktualizacji, wtyczki muszą pozostać kompatybilne z odpowiadającymi im wersjami Syliusa, a aktualizowanie wtyczek zajmuje sporo czasu, za który nikt nie zapłaci. Choć Sylius dostarcza szkielet do budowania wtyczek (PluginSkeleton), który pokazuje developerom, jak powinny być budowane rozszerzenia, zawiera on również coś, co nazywa się zależnością do katalogu (ang. dependency) z całą aplikacją testową – i tu właśnie zaczynają się komplikacje.

Zacznijmy jednak od początku...

W czym tkwił problem?

Plugin Skeleton dostarczany jest wraz z gotową aplikacją testową. Można to porównać do dodatku do gry wideo, który działa wyłącznie w połączeniu z określoną wersją gry. Przykładowo, wtyczka Sylius CMS opiera się właśnie na takim szkielecie, zawierającym aplikację testową z zainstalowaną konkretną wersją Sylius. Oznacza to, że każda wersja wtyczki przygotowana dla Sylius 1.x ma lokalnie również Sylius 1.x. Dzięki temu wszystko, co potrzebne do uruchomienia wtyczki, znajduje się w jednym katalogu.

W praktyce wtyczka zawiera zarówno kod odpowiadający za logikę biznesową, jak i szkielet umożliwiający testowanie tej logiki w kontekście danej wersji Sylius. Takie podejście ma sens w procesie tworzenia rozszerzeń – deweloperzy chcą mieć możliwość stałego sprawdzania, czy wtyczka działa poprawnie w całym środowisku.

Problem polegał jednak na tym, że do tej pory każda wtyczka miała własną aplikację testową w repozytorium szkieletu – z duplikowanymi konfiguracjami i ustawieniami. Przy drobnych aktualizacjach (minor) nie stanowiło to dużego wyzwania. Schody zaczynały się przy większych zmianach, gdy okazywało się, że utrzymanie i aktualizacja wtyczki wymagały ogromnej ilości pracy poświęconej nie samej logice, lecz zarządzaniu szkieletem.

Skalę problemu dobrze oddaje przykład: wtyczka może zawierać 100 plików odpowiadających za jej logikę (np. kod CMS do obsługi blogów czy obrazów), podczas gdy szkielet liczy nawet 1000 plików. Przy aktualizacji deweloperzy musieli przejrzeć i dostosować wszystkie te pliki, choć realne zmiany dotyczyły zaledwie kilku.

Można to porównać do sytuacji, w której twórca „skina” do gry wideo, zamiast pracować wyłącznie nad grafiką, za każdym razem musi pobierać i ręcznie zastępować tysiące plików całej gry. Efekt? Dwie godziny pracy nad grafiką, piętnaście godzin nad utrzymaniem środowiska.

Twórcy wtyczek musieli aktualizować nie tylko własny kod, lecz także całą aplikację testową, aby zachować kompatybilność z nowszymi wersjami Sylius. Nawet w BitBag początkowo traktowaliśmy to jako naturalny koszt pracy. W praktyce okazało się to jednak frustrującym i czasochłonnym procesem – każda drobna aktualizacja oznaczała konieczność zmiany wersji Sylius w szkielecie. A przy ok. 500 wtyczkach w całym ekosystemie oznaczało to setki osób spędzających godziny na przeglądaniu tysięcy plików przy każdej aktualizacji.

Rozwiązanie w postaci nowej aplikacji testowej

Aby uprościć proces aktualizacji wtyczek i wesprzeć społeczność w przejściu na Sylius 2.x, wprowadzono znaczące zmiany w dotychczasowym podejściu. Sylius udostępnił rozwiązanie, którego brakowało w standardzie od lat – wspólną, oficjalną aplikację testową do tworzenia wtyczek (TestApplication).

Nowa aplikacja testowa została przeniesiona do katalogu vendor, czyli miejsca, do którego developerzy nie ingerują bezpośrednio. Dzięki temu jest centralnie zarządzana i aktualizowana przez Syliusa, a twórcy wtyczek mogą skupić się wyłącznie na logice swojego rozwiązania, zamiast na utrzymaniu całej infrastruktury testowej. Rezultatem jest znacznie „odchudzony” szkielet wtyczki, w którym pozostawiono jedynie elementy odpowiadające za właściwą logikę.

W praktyce oznacza to wyeliminowanie wielu ręcznych kroków integracji. Developerzy nie muszą już modyfikować konfiguracji czy ustawień Webpack – w wielu przypadkach wystarczy uruchomić jedną komendę instalacyjną. Umożliwiają to Symfony Flex oraz dedykowane receptury.

To podejście jest przełomowe z dwóch powodów. Po pierwsze, znacząco skraca i upraszcza proces aktualizacji, eliminując większość czasochłonnych zadań związanych z zarządzaniem plikami. Po drugie, umożliwia centralne zarządzanie wersjami Syliusa – Core Team może szybko sprawdzić, jak dana logika wtyczki zachowuje się w odniesieniu do wersji 1.4, 2.0, 2.1 i kolejnych, zarówno przyszłych, jak i starszych.

Efektem jest znaczne uproszczenie migracji i utrzymania wtyczek. Zostały one zredukowane o setki zbędnych plików, co pozwala twórcom skupić się wyłącznie na własnym kodzie. Każda nowa wersja Sylius nie wymaga już ręcznych aktualizacji – proces jest centralnie zarządzany i zautomatyzowany.

Można to porównać do „emulatora” Sylius – wspólnej aplikacji testowej, wielokrotnego użytku, oficjalnie utrzymywanej przez zespół. Jest ona kompatybilna z wersją 2.0+ i sprawia, że praca nad wtyczkami staje się prostsza, szybsza i bardziej przewidywalna.

{{cta-technology-sylius="/pl/comp/cta"}} 

Implementacja w praktyce

Sylius wdrożył nową aplikację testową wewnętrznie przy okazji niedawno ogłoszonej wtyczki CMS i wyniki okazały się bardzo satysfakcjonujące. Testy w rzeczywistych warunkach potwierdziły, że rozwiązanie nie jest jedynie koncepcją teoretyczną, lecz sprawdzonym w praktyce narzędziem. Sukces wdrożenia wtyczki CMS był na tyle znaczący, że w najbliższym czasie Sylius planuje przenieść wszystkie swoje rozszerzenia na ten standard. Zaangażowanie zespołu core w ten proces nie tylko potwierdza zaufanie do rozwiązania, ale także wyznacza jasny kierunek rozwoju całego ekosystemu.

Co to oznacza dla developerów

Dla twórców wtyczek ten krok reprezentuje fundamentalną zmianę w podejściu do ich pracy. Proces rozwoju (lub aktualizacji) staje się znacznie łatwiejszy i dużo przyjemniejszy dla całej społeczności Syliusa, redukując pakiety wtyczek średnio o kilkaset plików. Zamiast zmagać się z kwestiami infrastruktury, developerzy mogą skupić się całkowicie na unikalnej wartości, jaką dostarczają ich wtyczki.

Standaryzacja oznacza też lepszą spójność w całym ekosystemie. Kiedy wszystkie wtyczki używają tej samej podstawy testowej, łatwiej jest utrzymać standardy jakości i zapewnić kompatybilność między różnymi rozszerzeniami.

Podsumowanie

Ta zmiana oszczędza developerom setki godzin poprzez uproszczenie całego procesu aktualizacji wtyczek. Społeczność może teraz skupić się na tym, co najważniejsze – budowaniu innowacyjnych wtyczek eCommerce, zamiast spędzać czas na aktualizacjach infrastruktury.

Ponadto społeczność jest zachęcana do wypróbowania nowej aplikacji testowej (dokumentacja), dzielenia się opiniami i przyczyniania się do dalszych ulepszeń. To podejście oparte na współpracy zapewnia, że rozwiązanie będzie się dalej rozwijać w oparciu o rzeczywiste potrzeby i doświadczenia developerów.

<div class="rtb-text-box is-blue-50">Szukasz specjalistów Syliusa? Skontaktuj się z nami i skorzystaj z darmowej konsultacji.</div>