Dlaczego to tyle trwa? 6 zasad dobrego developmentu Magento2
Już od prawie 15 lat zajmujemy się projektowaniem i wdrażaniem aplikacji webowych, a od 10 lat wdrożeniami eCommerce w oparciu o Magento. Przez cały ten czas często otrzymywaliśmy od klientów pytania: dlaczego development Magento jest tak czasochłonny? Dlaczego nawet proste modyfikacje mogą zajmować kilkanaście godzin pracy, a bardziej złożone kilkanaście dni? W niniejszym artykule postaramy się podsumować co składa się na dobry development Magento.
Zasada 1: Standardy kodowania i przewidywanie złożonych mechanizmów Magento
Decydując się na wdrożenie Magento, należy pamiętać o korzyściach z wyboru tej platformy, ale brać też pod uwagę konsekwencje takiej decyzji. Z jednej strony platforma świetnie się sprawdzi jako system dobrze skalujący się pod kątem rozbudowy funkcjonalnej jak i skalowania poziomego w przypadku architektury wieloserwerowej. Z drugiej strony, źle pisany kod i działania “na skróty” szybko wykażą, że nieprawidłowo utrzymywana i rozwijana platforma będzie generować problemy ─ co z kolei wygeneruje duży koszt przeprowadzenia audytu i działań naprawczych. Słaby kod nawet prostych modułów może w konsekwencji być nawet wymiernymi stratami dla biznesu, ponieważ będzie generował słabszą wydajność i niedostępność sklepu w wybranych obszarach.
Standardem, który spełniamy w Lizard Media ® jest pisanie kodu:
- Zgodnego ze standardami PSR
- Napisanego zgodnie z dobrymi praktykami DRY, SOLID
- Samodokumentującego się
- Czytelnego i pozwalającego na łatwy rozwój przez większy zespół
- Zgodnego z tzw. Developer Best Practices z oficjalnej dokumentacji Magento
- Odpornego na typowe problemy security
- Zgodnego z możliwościami wykorzystywanej wersji PHP (szczególnie dotyczy to np. strict types z PHP7).
- Zweryfikowanego pod kątem wydajności za pomocą narzędzi do debugowania bottlenecków (tzw. wąskich gardeł)
W ramach pełnej automatyzacji procesu wdrażania kodu na środowiska, kod jest weryfikowany i automatycznie przetwarzany przez mechanizmy automated markdown oraz automated CBF (tzw. Code beautifuler). Elementem standardowym jest również tzw. Code review, czyli weryfikacja kodu przez innego programistę z zespołu ─ często kilka razy, aż do uzyskania właściwej jakości kodu.
W warstwie frontendu Magento należy brać pod uwagę wszystkie obszary, które obsługuje Magento ─ nawet jeśli w danym momencie nie są one fizycznie używane. Przykładowo: modyfikacja obszaru wyświetlania ceny produktów musi zostać obsłużona dla listy produktów, strony produktowej (wariantu produktów: simple, configurable, bundle, grouped i ewentualnie innych customowych), wyników wyszukiwania, autosuggest, koszyka, checkout, powiadomień e-mail i wielu innych obszarów. Podobnie z procesem testowym ─ a o tym szerzej w punkcie 3. Wdrażając Magento warto tworzyć customowy template frontend, aby jego utrzymywanie i rozwijanie było stosunkowo łatwe ─ w przeciwieństwie do wykorzystywania tzw. “gotowych” template, których rozwój i poprawianie najczęściej wydłuża cały proces developmentu i nie pozwala na pełną kontrolę nad rozwiązaniem. Elementem standardowym podczas developmentu frontend powinno być również dbanie o optymalizację JS kodu (aby nie generować nadmiarowego wykorzystania pamięci przeglądarki), a także odpowiednio niskie współczynniki CLS.
Zasada 2: Testy jednostkowe, integracyjne, end2end
Zgodność ze standardami to tylko jeden z obszarów, który jest istotny z punktu widzenia tworzenia dobrej jakości kodu Magento2. Ważne jest również, aby zespół dbał o możliwie wysokie pokrycie kodu testami jednostkowymi oraz integracyjnymi. Stopień pokrycia kodu testami (tzw. coverage rate) zależy oczywiście od złożoności i odpowiedzialności danego modułu ─ nie wszystkie tego wymagają.
Dzięki takiemu podejściu, w ramach automatycznego procesu deploymentu, kod nowej lub zmodyfikowanej funkcjonalności nie trafi na żadne ze środowisk, ponieważ nie kompletny kod nie przejdzie przez wykonanie testów jednostkowych oraz integracyjnych.
Sytuacją idealną jest stworzenie i używanie testów end2end, napisanych np. z użyciem frameworka Cypress. To platforma, która symuluje zachowania użytkownika i potrafi również porównywać wizualnie wygląd platformy przed i po wdrożeniu danej funkcjonalności ─ skraca to proces testów manualnych regresji, ale wymusza z drugiej strony utrzymywanie czasochłonnych testów automatycznych. Jest to jednak podejście rekomendowane, ponieważ w czasie intensywnego rozwoju kodu pozwala na częstą weryfikację czy development nie wygenerował regresji.
Zasada 3: Proces QA
Gdy kod nowego lub zmodyfikowanego modułu trafił na środowisko testowe (za pomocą procesu opisanego w punkcie 4), jest przekazywany do zespołu QA. Teraz wykonywany jest szereg czynności, które mają za zadanie sprawdzenie jakości. Są to m.in.:
─ Testy zgodności z wymaganiem biznesowym
─ Testy poprawności wyświetlania desktop w różnych przeglądarkach (najczęściej w najbardziej aktualnych wersjach)
─ Testy poprawności wyświetlania mobile na różnych urządzeniach ─ najczęściej realizowane przez kilka fizycznych urządzeń oraz komercyjne symulatory (np. Lambdatest czy Browserstack)
─ Testy poprawności współczynnika CLS, istotnego z punktu widzenia Google Page Speed Insights
─ Testy regresji zmodyfikowanego obszaru
Jeśli testy wykażą błędy, wracają do procesu developmentu aż do akceptacji przez zespół QA.
Kluczowe jest również bieżące utrzymywanie tzw. arkuszy testów regresji, czyli rozbudowanego dokumentu, który pozwala zespołowi QA po każdym wdrożeniu upewnić się czy kluczowe funkcjonalności działają bez błędów. Tego typu dokumentacja zawiera zwykle kilkaset przypadków testowych zależnie od skali wdrożenia Magento.
Zasada 4: Wdrożenia na środowiska oraz testy regresji
Sam proces wdrożenia na środowiska powinien być w pełni zautomatyzowwany. Nasze wdrożenia Magento obejmują automatyzację zapewnioną przez mechanizmy GitLab CI ─ czyli tzw. Pipelines, które wykonują nie tylko deployment samego kodu, ale również:
─ Backup kodu i bazy danych
─ Uruchomienie narzędzi: autocbf, automd (używane również w trybie prehooków GIT)
─ Deployment nowego kodu i uruchomienie testów jednostkowych oraz integracyjnych
─ Standardowych czynności związanych z cache i indekserami Magento
Dopiero na tym etapie zmodyfikowany czy nowy kod Magento może być przekazany do akceptacji klienta. Jeśli otrzyma akceptację, może być zaplanowany do wydania w kolejnym tzw. release.
Zasada 5: Zawsze aktualna dokumentacja i czytelne wymagania biznesowe
Dobrej jakości kod to tylko jeden składnik poprawnego rozwoju Magento. Kluczowe jest również zapewnienie:
─ Dobrej i zawsze aktualnej dokumentacji ─ co jest szczególnie istotne w rozwoju, gdy modyfikowane są już istniejące i działające funkcjonalności
─ Zdefiniowanie wymagania biznesowego (tzw. BR, Business Requirement) które pozwoli na dobre przełożenie potrzeb klienta na kod źródłowy, a potem czytelną dokumentację
W Lizard Media ® traktujemy te elementy jako standard, który pozwala na długofalowy rozwój, ale jest też dla klienta dobrym źródłem informacji kto/kiedy podjął decyzję biznesową wraz z ciągłym dostępem do aktualnej dokumentacji przez cały zespół eCommerce.
Zasada 6: Wydajność i testy regresji po wdrożeniu
Po wydaniu produkcyjnym danego zakresu (paczki), konieczny jest monitoring rozwiązania w zakresie wydajności. Wykorzystujemy w tym celu m.in. platformę NewRelic oraz odpowiednie połączenie pomiędzy repozytorium kodu GitLab a API NewRelic ─ mierzymy w ten sposób różnice w wydajności pomiędzy wydaniami.
Samo wdrożenie przeprowadzane jest w ustalonym wcześniej okienku serwisowym, ale w większości przypadków nie wiąże się z żadną przerwą czy niedostępnością e-sklepu (tzw. zero downtime deployment). Po wykonaniu release konieczne jest zlecenie do zespołu QA kompletnych testów regresji (opisanych w punkcie 4) i dopiero po ich poprawnym zakończeniu można zamknąć proces wdrożenia zmian.
W okresie po wdrożeniu zespół SWAT (dyżurujący w celu utrzymania sklepów) obserwuje logi aplikacji. Posiadamy również jako standard mechanizmy tzw. FLS (First Line Support), które powiadamiają zespół SWAT w formie telefonów i SMS o sytuacjach krytycznych ─ aby możliwa była reakcja zanim będzie to rzutowało na biznes klienta w sposób zauważalny.
Podsumowując: dobrze zaprojektowany proces developmentu jest warunkiem stabilnego działania sklepu internetowego. To z kolei rzutuje na możliwość prowadzenia intensywnych działań marketingowych i rozwijanie funkcjonalne samej platformy. W Lizard Media ® zaprezentowane podejście stanowi standard i jest on ciągle rozwijany o nowe elementy. Samych składowych procesu jest więcej i powyższy artykuł jest tylko ogólnym podsumowaniem. Szukasz sprawdzonego Partnera skontaktuj się z nami sales@lizardmedia.pl.