Pasterskie koty — wnioski wyciągnięte podczas tworzenia dla środowiska WordPress

Kiedy Elementor 3.0 został wydany ponad rok temu, w 2020 roku, uznaliśmy to za znaczący krok w kierunku szybszego i znacznie wydajniejszego edytora. Chociaż to prawda, ta wersja miała również ważne, nieoczekiwane konsekwencje – spowodowała, że ​​znaczna liczba witryn przestała działać i, szczerze mówiąc, zaszkodziła naszej reputacji. Po tym wydaniu musieliśmy wprowadzić szereg poprawek, aby te witryny znów działały. Co więcej, całe doświadczenie pokazało nam, że musimy zmienić całą naszą procedurę testowania i wydania. Choć bolesny, proces ten dziś się opłaca, co odzwierciedla nadzwyczajny spadek liczby problemów, zwłaszcza krytycznych, między wydaniem naszych wersji v3.0 i v3.4:

Teraz, gdy zbliżamy się do pierwszej rocznicy wydania Elementora 3.0, nadszedł dobry czas, aby spojrzeć wstecz i przeanalizować procedury, które wprowadziliśmy, aby upewnić się, że problemy towarzyszące jego wydaniu nie wystąpią ponownie. Aby być jak najbardziej przejrzystym dla naszej społeczności, chciałbym zbadać tło problemów związanych z wydaniem 3.0, kroki, które podjęliśmy w ciągu ostatniego roku, jak byliśmy w stanie zapewnić stabilne wydania i co przyniesie przyszłość. Ale najpierw ważne jest, aby zrozumieć trochę historii Elementora i wyzwania, przed którymi stoimy, tworząc skomplikowaną, wyrafinowaną wtyczkę w środowisku WordPress.

Elementor i Wyzwanie WordPress

W czerwcu 2016 roku, kiedy wydaliśmy pierwszą wersję Elementora, byliśmy tylko kilkoma „dzieciakami”, które lubiły tworzyć wtyczki i pomagać ludziom w tworzeniu stron internetowych. To nie był nasz pierwszy produkt, opracowaliśmy już kilka wtyczek używanych przez społeczność WordPressa. Jednak podczas pracy nad Elementorem przekonaliśmy się, że tworzymy coś wyjątkowego. Jak się okazało, mieliśmy rację – zaledwie kilka miesięcy po naszym pierwszym wydaniu dziesiątki tysięcy użytkowników zainstalowało już Elementora i używało go do tworzenia stron internetowych na całym świecie.

Od tego czasu nasza firma rozwinęła się pod każdym względem, dzięki większej liczbie programistów, większej liczbie użytkowników i większej liczbie funkcji. Wraz z tym wzrostem pojawiło się mnóstwo nowych problemów, w tym rosnący deficyt technologii, ponieważ koncentrowaliśmy się na pilnych sprawach, odkładając na bok ważne, ale bardziej przyziemne problemy.

Radzenie sobie z tymi problemami było jeszcze trudniejsze ze względu na ogólne wyzwanie, jakie stanowi natura środowiska WordPress.

Jako otwarta platforma WordPress oferuje programistom wiele wspaniałych korzyści. Istnieje kilka blokad na drodze, które monitorują i spowalniają wydania. Koncepcje są wymyślane, rozwijane i dodawane do repozytorium. Użytkownicy próbują, testują i oceniają te produkty, a rynek decyduje, które z nich będą się rozwijać, a które nie. Jednak ta szybkość i prostota mają swoją cenę.

W środowisku WordPress jest niewielka jednolitość i brak uporządkowanego przepływu pracy. Twórcy stron internetowych mogą dowolnie definiować środowisko swoich witryn, korzystając z szerokiej gamy wtyczek, motywów itp. Oznacza to, że witryny WordPress zawierają niezliczone kombinacje wtyczek, motywów i konfiguracji serwera.

Ponadto prostota procesu wydania i brak solidnych narzędzi do wdrażania oznacza, że ​​programiści WordPress nie są w stanie wykorzystać nowoczesnych koncepcji wydań, takich jak CI/CD, Canary Deployment i Feature Flags.

Chociaż otwartość jest częścią piękna WordPressa, nieodłączna mnogość konfiguracji witryn i serwerów stanowi dla programistów prawdziwe wyzwanie, jeśli chodzi o rozliczanie konfliktów wtyczek i konkretnych problemów z serwerem.

W naszym przypadku, ponieważ Elementor był używany w coraz większej liczbie stron internetowych, potrzeba obsługi wszystkich tych różnych kombinacji spowalniała nasz harmonogram wydań, a nawet sprawiała, że ​​wahaliśmy się przed opracowywaniem nowych funkcji. Nie trzeba dodawać, że ta sytuacja była nie do przyjęcia i musieliśmy wszystko zmienić.

Opracowywanie nowych funkcji bez łamania starych

Wszystkie powyższe czynniki pozostawiły nas przed dylematem, w jaki sposób możemy dalej rozwijać się i doskonalić bez negatywnego wpływu na pracę tych, którzy już polegali na Elementorze?

Zaczęliśmy od wprowadzenia kilku drobnych zmian w naszym procesie wydawniczym. W Elementorze 1.5 zaczęliśmy oferować programistom dostęp do wersji beta. Zrobiliśmy to za pośrednictwem Github i innych społeczności, które umożliwiły nam otrzymywanie informacji zwrotnych przed wydaniem, wskazujących, w jaki sposób ta wersja współdziałała z szeroką gamą kombinacji wtyczek/motywów/środowisk i ostrzegając nas o wszelkich niezgodnościach na wczesnym etapie. To podejście działało dobrze przez jakiś czas, ale wraz z rozwojem Elementora, odkryliśmy, że to nie wystarczy.

Do tego czasu przekroczyliśmy próg pięciu milionów instalacji. Choć było to niesamowite osiągnięcie, oznaczało to również, że jesteśmy teraz odpowiedzialni za sprawne działanie wszystkich tych witryn.

Rzeczy w końcu przyszły na głowę wraz z wydaniem Elementora 3.0. W tej wersji postanowiliśmy porzucić niektóre stare, pozornie przestarzałe funkcje, usuwając elementy DOM w celu zwiększenia szybkości ładowania. Było to przynajmniej częściowo odpowiedzią na uzasadnione skargi, że niepotrzebnie obciążamy system.

Niestety ta zmiana spowodowała, że ​​wiele stron, które polegały na usuniętym przez nas kodzie, zepsuło się podczas aktualizacji. Pomimo naszych wysiłków, aby zaangażować w ten proces programistów zewnętrznych, te błędy pozostały nieodkryte i musieliśmy szybko działać, aby naprawić sytuację. W końcu udało nam się to zrobić, czyniąc część aktualizacji opcjonalną, ale zdarzyło się, że niektórzy członkowie naszej społeczności mieli wstrząśnięte zaufanie do stabilności naszej wtyczki.

To doświadczenie zmusiło nas do długiego, surowego przyjrzenia się naszemu procesowi rozwoju, z myślą o wprowadzeniu wielu poważnych zmian. Nasze procesy po prostu nie były odpowiednie dla firmy naszej wielkości i bazy instalacyjnej. Pierwszym i być może najbardziej oczywistym posunięciem było zwiększenie liczebności i zakresu naszego zespołu ds. kontroli jakości, ale nadal borykaliśmy się z kilkoma nierozstrzygniętymi problemami:

• Sprawdzanie zgodności wersji z niezliczonymi ustawieniami witryny
• Zapewnienie kompatybilności wstecznej z ponad pięcioma milionami istniejących witryn
• Sprawdzanie zgodności setek zewnętrznych rozszerzeń Elementora

Aby poradzić sobie z tymi wszystkimi problemami, musieliśmy wprowadzić do świata WordPressa bardziej aktualne metody tworzenia oprogramowania.

Pętla sprzężenia zwrotnego

Jednym z głównych problemów, z jakimi borykają się deweloperzy, jest to, że użytkownicy doświadczają aktualizacji dopiero po ich wydaniu. Oznacza to, że funkcja została już zaprojektowana, opracowana i wydana do czasu otrzymania przez nas opinii od użytkowników. W naszym przypadku, gdy mamy do czynienia z setkami rozszerzeń i wtyczek firm trzecich, problem tego sprzężenia zwrotnego jest jeszcze ważniejszy.

Szukając sposobów na skrócenie tego sprzężenia zwrotnego, przyjrzeliśmy się, jak programiści przeglądarek radzą sobie z problemami podobnymi do naszych – muszą również zapewnić zgodność z niezliczonymi stronami internetowymi, aplikacjami, rozszerzeniami i nie tylko innych firm.

Na przykład zbadaliśmy system opracowany przez Google dla ich przeglądarki Chrome. W dowolnym momencie programiści mają dostęp do trzech wersji przeglądarki — wersji beta, wersji deweloperskiej i wersji nocnej. Oznacza to, że programiści wcześnie przyglądają się nowym funkcjom Chrome i mogą zacząć przekazywać Google opinie na długo przed oficjalną premierą wersji.

Stosując te lekcje do naszej wtyczki, Elementor zaczął wypuszczać własną edycję dla programistów – Elementor Beta (Developer Edition), dostępną z repozytorium WordPress i skierowaną do programistów, którzy są zainteresowani sprawdzeniem naszych nowych funkcji „na gorąco”, że tak powiem.

Dla nas oczywiście odnosimy korzyści, otrzymując wczesne ostrzeżenia o problemach ze zgodnością. Wersja deweloperska nie tylko umożliwia użytkownikom dostęp do wszystkich tych nowych funkcji, ale jest nawet bezpośredni link do Github do zgłaszania błędów. Oznacza to, że możemy stale wdrażać nowe funkcje i otrzymywać informacje zwrotne na ich temat bez narażania istniejących witryn. Programistom pozwala to na przygotowanie się do nadchodzących oficjalnych wydań z dużym wyprzedzeniem, pomagając zapobiegać ich własnym problemom ze zgodnością, a także dając im możliwość dostarczenia informacji zwrotnych na temat produktu i informacji technicznych, gdy funkcja jest nadal opracowywana.

Należy zauważyć, że wydania edycji deweloperskiej działają równolegle do normalnego — alfa, beta, RC i produkcyjnego — procesu używanego do opracowywania wydań Elementora. Kiedy tworzymy nową funkcję, gdy tylko jest wystarczająco stabilna do użycia, ale nadal jest w wersji alfa, dodajemy ją do edycji deweloperskiej. W ten sposób nasi programiści mogą przekazywać nam swoje opinie, jeszcze zanim funkcja wejdzie w fazę beta. Oznacza to również, że wersja deweloperska zawiera funkcje, które nie osiągnęły etapu beta.

Zasadniczo faza beta jest zarezerwowana dla przemyślanego procesu debugowania, podczas gdy wersja deweloperska jest aktualizowana częściej, włączając funkcje na najwcześniejszych etapach.

Edycja deweloperska od momentu wprowadzenia okazała się wielkim sukcesem, zdobywając ponad 40 tysięcy instalacji w niecały rok.

Przedstawiamy funkcje „eksperymentalne”

Z biegiem lat inną koncepcją, którą przyjęli twórcy, są flagi funkcji, które są szczególnie rozpowszechnione w świecie SaaS. Ogólną ideą jest to, że te flagi funkcji umożliwiają programistom testowanie nowych funkcji poprzez ich włączanie i wyłączanie dla różnych segmentów użytkowników, aby je przetestować i zobaczyć, jak działają.

Jak wspomniano powyżej, wiele problemów związanych z wydaniem 3.0 było spowodowanych nowymi funkcjami eliminującymi starszy kod. Aby uniknąć tego rodzaju problemów, postanowiliśmy zastosować podejście podobne do flag funkcji.

Począwszy od Elementora 3.1, zaczęliśmy ostrożniej wydawać nowe funkcje, oznaczając je jako „eksperymentalne”. Obejmuje to system stopniowego wprowadzania nowych funkcji. W tym systemie nowo opracowana funkcja będzie oznaczona jako „Alfa”. Oznacza to, że jest domyślnie wyłączone we wszystkich witrynach. Ponieważ okazuje się, że jest bardziej stabilny, staje się „Beta”, co oznacza, że ​​jest teraz domyślnie włączony dla nowych witryn i wyłączony dla istniejących witryn. Gdy mamy pewność, że jest stabilny, jest domyślnie włączony dla wszystkich witryn. Nawet wtedy użytkownicy będą mieli możliwość dezaktywacji tej funkcji przez ograniczony czas.

Ten system pozwala nam na dalsze rozwijanie Elementora, dodając zarówno jego zestaw funkcji, jak i jego szybkość, jednocześnie umożliwiając twórcom włączenie lub wyłączenie tych nowych aktualizacji zgodnie z potrzebami ich witryny. Pomaga to również twórcom w aktualizowaniu ich witryn, umożliwiając im bardziej ostrożne wdrażanie nowych funkcji.

Tagi zgodności

Rozwój bardzo aktywnej społeczności programistów Elementora był źródłem dumy, ale także stawiał własne wyzwania. Zewnętrzni deweloperzy stworzyli setki rozszerzeń, motywów, zestawów i widżetów, a wszystko to w oparciu o naszą istniejącą technologię.

Aby wesprzeć programistów tych zewnętrznych dodatków, skorzystaliśmy z bloga naszych programistów i naszej listy mailingowej, aby wcześnie powiadomić ich o zmianach, które wprowadzamy w interfejsie API, a także o wycofaniu. Jednak, jak wspomniano powyżej, odkryliśmy, że to nie wystarczy. Wiele problemów, które napotykaliśmy w nowych wydaniach, dotyczyło problemów ze zgodnością z powodu tych dodatków innych firm. Nasza wtyczka była postrzegana jako niestabilna, nie z powodu naszej technologii, ale z powodu niezgodności stron trzecich.

Ponownie przyjrzeliśmy się temu, co robią inni, szukając inspiracji. W tym przypadku WooCommerce i ich podejście do współpracy z programistami zewnętrznymi. Począwszy od naszego wydania 3.1, uruchomiliśmy system, w którym zewnętrzni programiści poświadczają, że ich rozszerzenia są kompatybilne z nową wersją (Dowiedz się więcej). Następnie, gdy użytkownicy mają możliwość uaktualnienia Elementora, otrzymują listę rozszerzeń innych firm, z których korzystają, oraz informację, czy zostały certyfikowane jako zgodne z nową wersją Elementora. W ten sposób użytkownicy mogą podjąć świadomą decyzję o aktualizacji.

W kierunku jeszcze lepszej przyszłości

Nakreślając te wyzwania i wprowadzone przez nas zmiany, mam nadzieję, że dałem Wam wgląd w to, jak to jest rozwijać produkt do użytku na całym świecie, w otwartym i ciągle zmieniającym się środowisku. W ramach tej kultury open source bardzo ważne jest, abyśmy byli przejrzyści w stosunku do naszej społeczności użytkowników i programistów – tym bardziej, gdy firma się rozwija i coraz trudniej jest utrzymać „osobisty kontakt”. Nie tylko dlatego, że ból naszych użytkowników jest naszym bólem, ale dlatego, że jest to najlepszy sposób, aby Elementor pozostał stabilnym narzędziem, otwartym na jak najszerszy zakres użytkowników.

Jesteśmy głęboko przekonani, że wdrożone przez nas zmiany przyczyniły się i będą nadal przyczyniać się do rozwoju i sukcesu Elementora. Jesteśmy jednak również świadomi, że wciąż jest wiele do zrobienia i że komunikacja między Elementorem a społecznością Elementora musi pozostać otwarta, a nawet ulepszona. Na przykład aktualizujemy naszą witrynę z zasobami dla programistów, udostępniając łatwą w użyciu dokumentację, aby pomóc programistom w dostosowywaniu i rozbudowywaniu Elementora.
Ale być może najważniejszym krokiem, jaki podjęliśmy w celu poprawy komunikacji, jest utworzenie centrum społeczności Elementor. Tutaj twórcy stron internetowych na całym świecie mogą się gromadzić, aby wymieniać się pomysłami ze sobą, a także z nami – współpracując ze sobą, aby Elementor był jak najlepszy. W końcu, jak sugeruje stare przysłowie, wypasanie kotów może być prawie niemożliwe, ale kiedy pracują razem, nazywa się to Pride.