Jak uruchomić nową wersję swojego produktu, łamiąc wsteczną kompatybilność?

Kilka dni temu moi koledzy z Nelio i ja omawialiśmy przyszłość naszej wtyczki Nelio A/B Testing oraz jej nadchodzące funkcje i ulepszenia. Jako platforma do testów A/B, wtyczka wymaga ciągłych aktualizacji, aby nadążyć za nowymi wersjami WordPressa i upewnić się, że wszystko działa tak, jak powinno. Należy pamiętać, że jest to pierwsza wtyczka, którą uruchomiliśmy dla WordPressa pod koniec 2013 roku i od tego czasu podlega ciągłej ewolucji.

Pojawienie się Gutenberga w WordPressie otworzyło nowe możliwości dla testów dzielonych. I to zrodziło ciekawe pytanie: czy powinniśmy stopniowo ulepszać nasz produkt, czy lepiej zacząć od zera i wprowadzić coś zupełnie nowego, w pełni wykorzystującego bloki WordPressa?

Nie zdecydowaliśmy jeszcze, którą drogą iść, ale pomyślałem, że byłoby interesujące omówić problemy z uruchomieniem nowej wersji bez wstecznej kompatybilności i jak możemy je złagodzić lub wyeliminować.

Dlatego dzisiaj wyjaśnię dwa rozwiązania, które pozwolą uruchomić nową wersję Twojej usługi, łamiąc kompatybilność z poprzednimi wersjami w taki sposób, aby Twoi klienci nie ucierpieli na tej decyzji.

Uwaga dotycząca wstecznej kompatybilności

Jak Chris Lema powiedział jakiś czas temu na swoim blogu, „kompatybilność wsteczna jest mocno utrzymywaną i akceptowaną przez projekt WordPress. (…) [To] to wartość nie tylko dla deweloperów. To wartość dla użytkowników końcowych. A [jeśli jest zepsuta], to użytkownik końcowy otrzyma komunikat, że jego witryna już nie działa”.

Więc co dokładnie oznacza złamanie wstecznej kompatybilności? Jak możemy to złamać? Oto kilka przykładów:

1. Zmiana API, za pomocą którego można rozszerzyć naszą wtyczkę (funkcje, hooki itp.).
2. Modyfikacja struktury bazy danych.
3. Zmiana API naszej chmury (jeśli nasza wtyczka korzysta z jednego).
4. Przejście do nowego modelu biznesowego, a tym samym przejście do nowego paradygmatu aktualizacji, funkcji itp.

Rozważmy na przykład naszą usługę testów A/B. Z grubsza tak to działa:

• Użytkownik może tworzyć testy A/B na swojej stronie internetowej. Zasadniczo test A/B składa się ze strony, którą chcesz przetestować, co najmniej jednego wariantu tej strony oraz celów konwersji, które staramy się poprawić. Wszystkie te informacje są przechowywane w WordPress.
• Komponent chmury odpowiada za śledzenie wizyt na stronie internetowej, która korzysta z testów Nelio A/B. Podobnie jak Google Analytics, ten komponent zbiera informacje, przetwarza je i generuje podsumowanie przetrawionych wyników. I dokładnie tak, jak robi to GA, te dane są wysyłane za pomocą skryptu śledzenia.
• Wreszcie we wtyczce znajduje się widok, który łączy się z tą chmurą za pośrednictwem interfejsu API. Widok pobiera przetrawione wyniki i pokazuje użytkownikowi niektóre statystyki i grafiki.

Wtyczka taka jak Nelio A/B Testing może się zmieniać na wiele sposobów i jeśli nie będziemy ostrożni, jedna z tych zmian może spowodować „uszkodzoną wtyczkę”. Załóżmy na przykład, że chcemy/musimy zaktualizować API naszej chmury. W tym przypadku również jesteśmy zmuszeni zaktualizować naszą wtyczkę, ponieważ skrypt śledzenia i widok wyników zależą od tego interfejsu API. Dlatego nowe API wymaga nowej wtyczki. Ale tu pojawia się problem: ten nowy interfejs API oznacza również, że nasi użytkownicy są teraz zmuszeni do uaktualnienia, ponieważ poprzednie wersje naszej wtyczki nie będą w stanie komunikować się z nowym interfejsem API.

Teraz załóż buty swoich użytkowników: wtyczka, która działała płynnie i bezbłędnie, nie działa już z powodu aktualizacji, którą wykonałeś w swojej chmurze. Nie fajnie. Wcale nie fajnie

Możliwe rozwiązania

Złamanie wstecznej kompatybilności nie jest trywialnym problemem. To coś, co wymaga starannego rozważenia. A w każdym razie najważniejsze jest, aby wybrać rozwiązanie, które nie pozostawi obecnych użytkowników z niedziałającą wtyczką. Zwłaszcza tym, którzy płacą ci za twoją usługę.

Jeśli jesteśmy pewni, że jako freelancer lub jako firma, z jakiegokolwiek powodu, najbardziej odpowiada nam rozpoczęcie od zera z zupełnie nową wersją naszego produktu i pozbycie się kompatybilności wstecznej, mamy dwa rozwiązania. Dzięki nim będziemy mogli zrobić czyste konto, jednocześnie upewniając się, że nasi użytkownicy nadal będą mogli korzystać z tego, co mieli wcześniej.

Uruchom nowy produkt (opt-in)

Pierwszym rozwiązaniem, które musimy uruchomić, aby uruchomić wersję, która nie jest wstecznie kompatybilna, jest niewykonanie tego. Zamiast tego uruchom nowy produkt! !

Gwarantuje to, że obecni użytkownicy mają działającą wtyczkę , która działa jak zwykle. W rzeczywistości nigdy nie będą mogli uaktualnić do wersji, która „psuje rzeczy”, po prostu dlatego, że ta nowa wersja nigdy nie będzie istnieć; uruchamiasz zupełnie nową wtyczkę i wkładasz wysiłki w aktualizację tej nowej wtyczki, co oznacza, że ​​są „zamrożone w przeszłości”.

To oczywiście rodzi kilka poważnych problemów, którymi należy się zająć:

1. Użytkownicy, których już mamy, nie będą wiedzieć, że pojawiła się nowa wersja naszego produktu, chyba że im o tym powiemy. Oznacza to, że musimy promować naszą „nową wtyczkę/usługę” w starej, co wygląda dziwnie… ale działa dobrze.
2. Wprowadzenie na rynek nowego produktu jest bardzo trudne . Cały wysiłek, który włożyłeś w poprzedni produkt (stworzenie marki, pozycjonowanie, zbieranie recenzji, aktywne instalacje…) przepada i jesteś zmuszony zacząć od zera.

Jest to rozwiązanie opcjonalne: wprowadzamy nowy produkt i zachęcamy do zaprzestania korzystania ze starego i uzyskania nowego. To właśnie zrobił WordPress (w pewnym sensie) kilka miesięcy temu, kiedy wypuścili Gutenberga jako wtyczkę: to Ty zdecydowałeś, czy chcesz użyć Gutenberga w swojej witrynie, instalując wtyczkę na swojej stronie.

Uruchom aktualizację, która łamie wsteczną kompatybilność (rezygnacja)

Inną opcją jest podejście odwrotne lub rozwiązanie rezygnacji: wypuść aktualizację produktu, która łamie wsteczną kompatybilność i równolegle uruchom nowy produkt ze starą wersją . W ten sposób, nawet jeśli nowa wersja nie jest kompatybilna wstecz, oferujemy naszym użytkownikom alternatywę, aby wszystko działało tak, jak do tej pory.

Ta metoda rozwiązuje dwa problemy, które podnieśliśmy w poprzednim rozwiązaniu. Z jednej strony wszyscy użytkownicy już od pierwszego dnia będą wiedzieć, że pojawiła się nowa wersja naszego produktu/usługi i będą mogli zobaczyć i wypróbować nowości.

Z drugiej strony (co może ważniejsze) nadal czerpiemy korzyści z całej dotychczasowej pracy, ponieważ po prostu wprowadziliśmy nową wersję dobrze ugruntowanego produktu. Zachowasz markę, recenzje, statystyki… nic się nie zmieni, ponieważ nie zaczynasz od zera.

Jak możesz sobie wyobrazić, jest to rozwiązanie rezygnacji: za każdym razem, gdy użytkownik zaktualizuje swoją wtyczkę, zobaczy nową wersję (nawet jeśli nie podoba mu się to, że łamie ona wsteczną kompatybilność). Ale dajesz im również możliwość powrotu do starej wersji, instalując nowy produkt. Tak właśnie zrobił WordPress w grudniu ubiegłego roku, kiedy wprowadził edytor bloków w swojej najnowszej aktualizacji i zaoferował użytkownikom możliwość korzystania ze starego edytora poprzez zainstalowanie wtyczki Classic Editor .

W podsumowaniu

Złamanie wstecznej kompatybilności nie jest trywialne, ponieważ może mieć duże implikacje dla użytkowników. Generalnie nie polecamy tego robić. Ale czasami to jedyna opcja, jaką masz.

Jeśli musisz to zrobić, sugeruję wdrożenie jednego z dwóch rozwiązań, które widzieliśmy dzisiaj. Dzięki nim upewnisz się, że Twoi użytkownicy będą mieli plan tworzenia kopii zapasowych, aby „wszystko działało tak, jak dawniej” i nikt nie będzie narzekał, że „rzeczy są zepsute”. Oczywiście jako odpowiednik będziesz musiał utrzymywać dwa produkty (nawet zakładając, że „stara” wersja wymaga minimalnej konserwacji), ale to już temat na inny post.

A teraz powiedz mi, czy kiedykolwiek spotkałeś się z takim problemem? Jak to rozwiązałeś? Co byś zrobił?

Polecane zdjęcie Dietmara Beckera w Unsplash.