Dwa scenariusze prowadzenia migracji funkcjonalności na wersję 2.0 platformy

webini logo

Webini

#softwaremigration #featuresmigration

02.02.2021

Zdarza się, że platforma internetowa nie działa tak efektywnie, jak powinna. Że wstrzymuje rozwój firmy, spowalnia pracę zespołu, generuje wysokie koszty utrzymania. Złe funkcjonowanie systemu może być konsekwencją zaciągnięcia zbyt dużego długu technologicznego i niespłacania go na czas przez prowadzenie refaktoringu kodu źródłowego. Przyczyną mogą być też nieprzemyślane zmiany kierunku rozwoju lub  utrzymywanie platformy w oparciu o przestarzałe, już nie wspierane technologie.

Niezależnie od przyczyny, niekiedy najbardziej opłacalnym sposobem na pozbycie się problemów jest przeniesienie istniejącej platformy na wersję 2.0 – a dokładniej, przeprowadzenie migracji funkcjonalności do nowego, uporządkowanego i stabilnego systemu. W przypadku niektórych firm, inwestycja w platformę 2.0 będzie bardziej intratna niż próby naprawienia istniejącego systemu.

Migrację funkcjonalności oraz samo uruchomienie produkcyjne platformy (rollout) można przeprowadzić na dwa sposoby: skokowo lub stopniowo. Obie te strategie różnią się od siebie nie tylko czasem realizacji, ale też kosztami czy poziomem bezpieczeństwa i stabilności przedsięwzięcia.

Na czym polega migracja funkcjonalności?

W przypadku gdy system generuje straty dla firmy, jednym z pierwszych kroków powinno być przeprowadzenie audytu jakości technologicznej i ocena kondycji kodu źródłowego. W oparciu o przeprowadzony audyt określa się, czy możliwe jest podniesienie jakości w istniejącym systemie, czy już konieczne jest przeprowadzenie migracji funkcjonalności.

Jeśli firma zdecyduje się na przeniesienie systemu na wersję 2.0, pierwszym krokiem będzie przeprowadzenie analizy wymagań. Jest to etap, podczas którego zespół specjalistów prowadzi rozmowy z klientem, poznaje potrzeby firmy, systemu oraz jego użytkowników końcowych. Po zapoznaniu się z wymaganiami, specjaliści przechodzą do opracowania strategii wdrożenia. Prowadzą dogłębną analizę struktury platformy, kodu źródłowego, procesów zachodzących w systemie i wokół niego czy zachowań użytkowników. Zwracają uwagę na każdy obszar i element – od platformy jako całości, przez struktury baz danych, aż do pojedynczych etapów funkcjonalności. Efektem tych działań jest dokument zawierający m.in. specyfikację funkcjonalną i techniczną, projekt architektury, plan realizacji z uwzględnieniem obecnej sytuacji i procesów zachodzących w firmie, opis przebiegu współpracy, harmonogram prac wraz z budżetem czy wspomniany sposób uruchomienia systemu.

Analizę oraz strategię przygotowuje się w celu opracowania jak najbardziej optymalnego sposobu przejścia ze starego systemu na nowy – tak by w bezpieczny i stabilny sposób połączyć potrzeby klienta, firmy i użytkowników z wymaganiami technicznymi oraz dostępnym czasem i budżetem. W zależności od potrzeb oraz wysokości środków, prowadzi się migrację oraz rollout platformy na dwa sposoby.

Sposób 1: migracja funkcjonalności do gotowego systemu i skokowy rollout

W tym przypadku dotychczasowy system jest utrzymywany, w razie potrzeb również rozwijany. Niezależnie od niego powstaje nowy system, który jest poszerzany o zoptymalizowane funkcjonalności i procesy pochodzące z poprzedniej wersji platformy. Nowy system jest rozbudowywany element po elemencie do poziomu starego, jednak nie jest używany do momentu pełnego uruchomienia.

Systemy działają oddzielnie, nie wymieniają się między sobą żadnymi danymi. Wszyscy użytkownicy korzystają z dotychczasowej wersji platformy, chyba że kompozycja systemów bazodanowych umożliwia przeniesienie części odbiorców na nową platformę. Docelowo wszyscy użytkownicy są przenoszeni do systemu 2.0 dopiero po uruchomieniu wersji. Wtedy też poprzedni system jest wyłączany.

Uruchomienie nowej wersji trwa właściwie chwilę. Rollout – przeniesienie użytkowników do nowego systemu i wyłączenie poprzedniego – robi się w okresie, gdy na platformie panuje najmniejszy ruch. Najczęściej są to godziny nocne.

Jakie są plusy takiego rozwiązania?

Plusem z pewnością jest relatywnie niski koszt oraz szybki czas realizacji. Ten sposób nie przewiduje jednoczesnego utrzymywania obu systemów, nie ma potrzeby wdrażania mechanizmów synchronizacji, co wymaga mniej pracy i pozwala zaangażować mniej osób.

Przeniesienie użytkowników odbywa się jeden raz, a przepięcie ruchu i wyłączenie poprzedniego systemu trwa chwilę. Jeśli wszystkie procesy migracji zostały dobrze opracowane, nowa platforma może zostać w pełni uruchomiona w ciągu jednej nocy.

A minusy?

Każdy kij ma dwa końce – niski koszt realizacji działa też na niekorzyść platformy. Największym niebezpieczeństwem wynikającym z prowadzenia migracji tym sposobem jest brak możliwości powrotu do poprzedniej wersji systemu. Właściciel platformy jest skazany na prowadzenie zmian na nowej, już działającej wersji, z tysiącami czy milionami użytkowników na pokładzie.

Każdy kij ma dwa końce – niski koszt realizacji działa też na niekorzyść platformy. Największym niebezpieczeństwem wynikającym z prowadzenia migracji tym sposobem jest brak możliwości powrotu do poprzedniej wersji systemu. Właściciel platformy jest skazany na prowadzenie zmian na nowej, już działającej wersji, z tysiącami czy milionami użytkowników na pokładzie.

Niezależnie od tego, jak duży i doświadczony zespół specjalistów QA będzie prowadził testy, wiele błędów można zauważyć dopiero, gdy z platformy zaczną korzystać użytkownicy. Jeśli okaże się, że system zawiera dużo błędów lub są one krytyczne, zespół będzie prowadził walkę z czasem – albo szybko naprawi błędy, albo platforma straci użytkowników.

Nowa wersja platformy łączy się również z nowymi procesami, scenariuszami użycia czy szatą graficzną. Użytkownik, który jeszcze we wtorek korzystał z dobrze znanego mu portalu, a w środę wchodzi na zupełnie inny serwis, może nie być zadowolony. Albo podejmie próbę zapoznania się i przyzwyczajenia do nowej platformy, albo zrezygnuje i skorzysta z rozwiązania konkurencji.

Gruntowna zmiana i nagły rollout – Digg.com

Niechlubnym przykładem przeprowadzenia (zbyt) gwałtownego rolloutu jest portal Digg. Digg.com to portal służący do agregacji treści, dzielenia się znaleziskami z sieci i prowadzenia dyskusji. Do 2010 roku korzystało z niego ponad 200 milionów użytkowników. W 2010 roku system został przepisany od nowa i odbył się rollout nowej wersji platformy – całkowicie zmienionej. Użytkownicy, zamiast znanego sobie portalu, zastali zupełnie inny UI, inną politykę, zmiany w funkcjonowaniu oraz… sporo błędów. Właściciele platformy, z powodu obranej strategii wdrożenia, nie byli w stanie przywrócić poprzedniej wersji systemu. Ponad ⅓ użytkowników opuściła Digg na rzecz Reddita, co doprowadziło do znacznego spadku popularności serwisu.

W przypadku jakiej platformy takie rozwiązanie się sprawdzi?

Budowa osobnego systemu i jednorazowy rollout mają swoje plusy, ale są też obarczone dużym ryzykiem. Można przeprowadzić migrację funkcjonalności tym sposobem, jeśli właściciel platformy nie przewiduje znacznych zmian po stronie użytkownika. Im większe zmiany będą wprowadzane w nowym systemie, tym większe jest prawdopodobieństwo, że użytkownik nie będzie zadowolony – że będzie musiał poświęcić dużo czasu na zapoznanie się z nową odsłoną lub po prostu zrezygnuje z korzystania z platformy.

Testy wśród użytkowników

To, że systemy nie wymieniają się danymi, nie oznacza, że z prowadzeniem testów wśród użytkowników trzeba czekać na pełne uruchomienie nowej wersji i przepięcie całego ruchu. Jeśli umożliwia to kompozycja systemów bazodanowych, można przeprowadzić segmentację użytkowników – uruchomić nową platformę i przekierować na nią część odbiorców. To pozwoli sprawdzić odbiór wśród grupy użytkowników, przyjrzeć się działaniu systemu, wyłapać i naprawić ewentualne błędy. Należy jednak pamiętać, że tacy użytkownicy nie będą mieli możliwości powrotu na poprzednią wersję, ponieważ wszystkie dane z ich działań zapisują się już w nowym systemie.

Błędy towarzyszą zmianie – Facebook

Jeszcze kilka lat temu wewnętrzne motto Facebooka brzmiało “move fast and break things”. To pogląd, który zakłada, że wprowadzaniu zmian i innowacji zawsze będą towarzyszyły błędy. Facebook, by nie powstrzymywać kreatywności, pozwalał pracownikom tworzyć i publikować na wersjach produkcyjnych różne funkcjonalności – oczywiście, po przeprowadzeniu wewnętrznych testów. Pracownicy monitorowali procesy, działanie funkcjonalności oraz ich odbiór wśród użytkowników. Na tej podstawie wprowadzali zmiany lub wycofywali usługę. Facebook w 2014 roku zmienił motto na “move fast with stable infrastructure”.

Sposób 2: jednoczesne utrzymywanie dwóch systemów i stopniowy rollout

Drugi sposób prowadzenia migracji funkcjonalności łączy się z równoległym utrzymywaniem dwóch systemów – starego i nowego. Funkcjonalności są kopiowane ze starej platformy, poddawane optymalizacji i publikowane w nowym systemie. Po przeprowadzeniu testów, nowa wersja platformy jest aktualizowana, a część ruchu kierowana na nowy segment w drugim systemie. Użytkownicy korzystają częściowo ze starego, a częściowo z nowego systemu, jednak nie odczuwają żadnych negatywnych zmian z tego tytułu. Z ich perspektywy wciąż jest to jedna platforma, którą znają – może w trochę innej odsłonie wizualnej lub o większej prędkości.

Zespół monitoruje procesy zachodzące na platformie oraz zachowania użytkowników. W razie potrzeby deweloperzy wprowadzają zmiany lub przekierowują odbiorców z powrotem do starego systemu. Obie wersje platformy synchronizują się między sobą i na bieżąco wymieniają danymi, więc nie ma problemu z przenoszeniem użytkowników między obszarami.

Jeśli dana funkcjonalność nie posiada błędów, a jej odbiór jest pozytywny, stopniowo zwiększa się liczbę użytkowników obszaru w nowym systemie. W momencie gdy przekieruje się cały ruch do nowej platformy, dany segment w starym systemie ulega wyłączeniu. I tak, element po elemencie, funkcjonalność po funkcjonalności, rozbudowywany jest nowy system, a stary wygaszany – aż do momentu całkowitego wyłączenia. Proces trwa najczęściej od kilku do kilkunastu miesięcy.

Dotychczasowy system – utrzymanie czy rozwój?

W trakcie procesu migracji funkcjonalności, w starym systemie prowadzi się jedynie prace utrzymaniowe. Tylko w przypadkach, gdy potrzebne jest pilne wdrożenie nowego elementu (na przykład wynikającego z norm prawnych), zmianę wprowadza się w starym systemie i równolegle w nowym. Jeśli jest możliwość, rozbudowy prowadzi się jedynie w nowym systemie i tam kieruje ruch. Rozwijanie wersji platformy, która chyli się ku wyłączeniu, byłoby marnotrawieniem budżetu, dlatego takie działania podejmuje się tylko, jeśli są konieczne.

Plusy rozwiązania

Jest to bardzo bezpieczna strategia prowadzenia migracji i uruchamiania platformy. Pozwala sprawdzić dokładnie każdy obszar pod kątem funkcjonowania procesów w systemie. Daje możliwość obserwacji odbioru przez użytkowników oraz stopniowo przyzwyczajać ich do zmian. Stary i nowy system są synchronizowane między sobą, więc bez problemu można przenosić ruch między dwoma wersjami, co jest przydatne w momencie wystąpienia trudnych do naprawienia błędów w nowym systemie.

Minusy stopniowej migracji

Wykonanie stopniowego rollout’u jest kosztowne. Wymaga utrzymania równolegle dwóch systemów, w tym stworzenia, wdrożenia i monitorowania procesów wymiany danych między wersjami. Projekt angażuje więcej osób i zajmuje więcej czasu niż w przypadku tworzenia osobnego systemu, do którego migruje się całość ruchu.

Często w trakcie prowadzenia prac okazuje się, że niektóre zaplanowane działania zajmują kilka razy więcej czasu – najczęściej dotyczy to kwestii, w których platforma jest zależna od zewnętrznych partnerów, na przykład Facebooka, Instagrama czy YouTube. Ale zdarza się również, że realizacja niektórych zadań, na które planowano poświęcić dużo czasu, zajmuje chwilę. Estymacje często są życzeniowe i o ile ustalenie budżetu nie sprawia problemów, z wyznaczeniem dokładnego terminu może być ciężej.

Jaka firma powinna prowadzić migrację funkcjonalności tym sposobem?

Prowadzenie stopniowej migracji i utrzymywanie dwóch systemów jest polecane firmom, które mają świadomość, że popełnienie błędu może przekreślić ich działalność. To bardzo stabilne i bezpieczne rozwiązanie, które jest polecane w przypadku wprowadzania dużych zmian na platformie.

Utrzymanie dwóch systemów – Reddit

Reddit – portal służący agregacji treści i prowadzeniu dyskusji – posiada ponad 330 milionów użytkowników. Po 10 latach, podczas których nie były wprowadzane żadne poważne zmiany w wyglądzie czy funkcjonalnościach, właściciele serwisu podjęli decyzję o odświeżeniu UI i UX. Wszystkie działania były podjęte dogłębną analizą zachowań użytkowników. Specjaliści pracowali nad redesignem, prowadząc po drodze testy na niewielkich grupach użytkowników.

W 2018 roku odbył się rollout nowej wersji. Ale Reddit do dziś utrzymuje dwa rodzaje platformy – nową i starą. Użytkownicy sami mogą decydować, z którego rodzaju serwisu chcą korzystać. Reddit nie planuje im tej możliwości zabierać i deklaruje, że wciąż będzie utrzymywać dwie kompatybilne wersje.

Na to zwróć uwagę

Migracja systemu na wersję 2.0 to duże przedsięwzięcie, które powinno być poprzedzone dogłębną analizą, przygotowaniem odpowiedniego planu i strategii wdrożenia. Niezależnie od sposobu migracji i rollout’u, należy zwrócić uwagę nie tylko na techniczne aspekty, takie jak budowa platformy czy proces migracji funkcjonalności, ale też na odbiór nowej wersji wśród użytkowników. Równie ważne jest skomponowanie zespołu specjalistów odpowiedzialnych za wdrożenie, na czele którego stanie stanowczy i świadomy lider.