Szybkie uruchomienie platformy i wejście na rynek jest niekiedy kluczowe i stanowi o być lub nie być startupu technologicznego. Prędkość wdrożenia nie zawsze idzie w parze z jakością kodu źródłowego. Ale ten pośpiech można wybaczyć, jeśli później prowadzi się refaktoring (wracanie do już zapisanych linijek, by uporządkować kod).
Zdarza się, że firmy nie prowadzą refaktoringu ani nie przykładają wystarczająco dużej wagi do tworzenia od samego początku wysokojakościowego kodu źródłowego. Pośpiech sprzyja robieniu skrótów, które prowadzą do zaciągnięcia długu technologicznego. A ten, w pewnym momencie, znacznie ogranicza możliwości rozwoju platformy.
Czasem jedynym możliwym wyjściem z takiej sytuacji jest przeniesienie funkcjonalności na wersję 2.0 platformy. Ale jak zrobić to w przypadku platformy, z której korzystają tysiące, jak nie setki użytkowników? Platformy, która przetwarza dane klientów, obsługuje codziennie miliony procesów i musi zapewniać 100% SLA?
Przenieśliśmy niejedną platformę na wersję 2.0. Opowiemy Wam, jak prowadziliśmy migrację funkcjonalności, utrzymując równocześnie stary i nowy system.
Czynniki, które powinny skłonić do przejścia na platformę 2.0
Zdarza się niestety, że platforma nie jest prawidłowo zbudowana lub utrzymana. Zwłaszcza po stronie back-endu, czyli warstwie niewidocznej na pierwszy rzut oka, ale kluczowej dla całego systemu – to w niej zachodzi większość akcji i procesów. Platforma może być oparta się o starą, już niewspieraną technologię lub posiadać dług technologiczny tak duży, że inwestowanie w jego spłatę na obecnej wersji systemu nie będzie intratne.
Podjęcie decyzji o przeprowadzeniu migracji funkcjonalności nie jest łatwe – ale niekiedy konieczne. Warto, żebyś zastanowił się nad zleceniem dogłębnego audytu jakości kodu źródłowego (i w zależności od jego wyników – przeniesieniem systemu na wersję 2.0), jeśli zauważasz poniższe problemy:
- na utrzymanie platformy firma przeznacza wyższy budżet niż na jej rozwój,
- wprowadzenie nawet najmniejszej zmiany w systemie generuje problemy w innych miejscach,
- platforma zamiast wspierać, spowalnia rozwój firmy,
- implementacja nowych funkcjonalności zajmuje relatywnie dużo czasu,
- platforma działa nieefektywnie, przez co spowalnia działania pracowników.
Płynne przejście ze starej wersji systemu na nową
Chyba żadna firma nie chce pozwolić sobie na przestój spowodowany prowadzeniem migracji funkcjonalności. Prace wdrożeniowe muszą być prowadzone sprawnie, tak by nie miały wpływu na stabilność czy tempo rozwoju platformy. Oto przepis, według którego przenieśliśmy na nową wersję jedną z największych platform, z jakimi mieliśmy do czynienia – system płatności internetowych, obsługujący dziennie miliony transakcji i setki tysięcy użytkowników.
Poznanie potrzeb klienta
Pierwszym etapem na drodze do przeniesienia systemu było poznanie potrzeb – właściciela platformy, ale też użytkowników, czyli pracowników firmy czy klientów końcowych. Przeprowadziliśmy rozmowy, sesje brainstormingowe, analizy zachowań na platformie. Określiliśmy, jakie obszary koniecznie powinny zostać zachowane, a które elementy można zmodyfikować lub usunąć przy okazji prowadzenia migracji funkcjonalności.
Strategia i określenie wymagań nowego systemu
Po zapoznaniu się z wymaganiami klienta oraz potrzebami użytkowników, przeszliśmy do analizy technicznej. W przygotowanie planu migracji byli zaangażowali specjaliści z każdego obszaru: CTO platformy, analitycy biznesowi, architekci systemów informatycznych, administratorzy serwerów oraz deweloperzy.
Wyznaczony zespół specjalistów prowadził dogłębną analizę kodu źródłowego po stronie back-endowej, sposobu działania systemu jako całości oraz poszczególnych jego elementów.
Oto, na co zwróciliśmy szczególną uwagę podczas analizy:
- jak dotychczas był utrzymywany i rozwijany system – przyjrzeliśmy się, jak wyglądały prace poprzedniego zespołu deweloperów oraz jaki miały one wpływ na funkcjonowanie platformy,
- procesy zachodzące na platformie oraz wokół niej – przeanalizowaliśmy, jakie akcje zachodziły w systemie oraz jaki miały przebieg; zwróciliśmy również uwagę na działania wewnątrz firmy dotyczące bezpośrednio platformy,
- architektura baz danych – przyjrzeliśmy się dotychczasowej strukturze baz danych; postanowiliśmy na dalszym etapie usunąć duplikacje oraz poddać modyfikacji architekturę systemów bazodanowych, by zwiększyć wydajność platformy,
- podzielenie systemu na mniejsze serwisy oraz określenie odpowiedzialności każdego mikroserwisu – zaplanowane działanie miało zwiększyć stabilność platformy oraz dać możliwość szybszego rozwoju przy mniejszym ryzyku,
- budowa funkcjonalności – postanowiliśmy “prześwietlić” wszystkie funkcjonalności – rozpisać każdą z nich na etapy, poddać optymalizacji i dopiero w ulepszonej formie migrować do nowego systemu.
Efektem tych działań było przygotowanie dwóch dokumentów: analizy przedwdrożeniowej, która zawierała schemat architektury, specyfikację techniczną i funkcjonalną oraz strategii wdrożenia, uwzględniającej plan realizacji oraz koordynacji procesów między zespołem klienta a deweloperami Webini. Przeprowadzenie analizy wymagań oraz opracowanie strategii pozwoliło też wyznaczyć etapy prac, określić czas trwania i budżet potrzebny do realizacji projektu. Zgodnie z założeniami, płynna migracja zaawansowanego systemu miała zająć 12 miesięcy.
Budowa nowego systemu przy utrzymaniu systemy poprzedniego
Nasi specjaliści, w oparciu o przygotowany plan wdrożenia oraz strategię, rozpoczęli tworzenie struktury nowego systemu. Już po miesiącu uruchomiony został panel administracyjny z podstawowymi funkcjonalnościami. Każdy pracownik mógł się zalogować i zapoznać się ze szkieletem platformy 2.0.
Zgodnie z ustalonym planem, deweloperzy rozłożyli cały dotychczasowy system na części pierwsze. Stopniowo poddawali analizie i optymalizacji każdy element – w tym blisko 500 funkcjonalności.
Dopiero ulepszone funkcjonalności były przenoszone do nowego systemu. Działania były prowadzone zgodnie z harmonogramem migracji. W każdym dwutygodniowym sprincie prowadziliśmy również prace Quality Assurance. Nowy system, po dodaniu funkcjonalności, przejściu testów oraz naprawie ewentualnych błędów, był aktualizowany na wersji produkcyjnej. Dla niektórych użytkowników wyłączaliśmy opcję korzystania z danej funkcjonalności na starej wersji, kierując ruch do danego obszaru na nowej platformie. Zachowaliśmy przy tym możliwość przepięcia użytkownika z powrotem pod poprzedni system. Obserwowaliśmy zachowania użytkowników i systemu, monitorując ewentualne problemy czy błędy. Te, jeśli zaistniały, poprawialiśmy i aktualizowaliśmy wersję. Z każdą kolejną zmianą, gdy nabieraliśmy pewności, że dany obszar działa stabilnie i bezproblemowo, kierowaliśmy coraz większy ruch na nową platformę. Finalnie, funkcjonalność na nowej platformie obsługiwała 100% użytkowników, dany obszar w starym systemie ulegał wygaszeniu.
Ponieważ oba systemy musiały działać równolegle i wymieniać się danymi, zaprojektowaliśmy i wdrożyliśmy proces umożliwiający dwustronną synchronizację baz danych. Jeśli użytkownik wykonał akcję w nowym systemie, zmiana zapisywała się też w starym – i na odwrót. Proces synchronizacji danych funkcjonował aż do momentu całkowitego wyłączenia starego systemu.
A poprzedni system?
Na etapie prowadzenia analizy i przygotowania strategii ustaliliśmy razem z klientem, że nie będziemy prowadzić prac rozwojowych w starym systemie, a jedynie prace utrzymaniowe. Tylko na początkowym etapie, gdy nowa wersja była w bardzo wczesnej fazie, wprowadzaliśmy modyfikacje w dotychczasowym systemie (potrzeba wynikała na przykład ze zmieniających się wymogów prawnych).
Przez cały czas trwania realizacji reagowaliśmy na bieżące kwestie i problemy oraz wprowadzaliśmy konieczne zmiany w poprzedniej wersji systemu. Wszystkie nowe oraz zmodyfikowane funkcjonalności implementowaliśmy jedynie w nowym systemie
Stopniowe wygaszanie starego systemu
Po rozdzieleniu każdej funkcjonalności, przeprowadzeniu jej optymalizacji, przeniesieniu do nowego systemu oraz przeprowadzeniu testów, kierowaliśmy część ruchu na nową platformę. Stopniowo zmniejszaliśmy liczbę użytkowników danego obszaru w starym systemie, kierując ich do nowego. Dopiero gdy wszyscy użytkownicy zostali przeniesieni, funkcjonalność w starym systemie była wygaszana.
Prace były prowadzone zgodnie z harmonogramem ustalonym na początku realizacji usługi.
W przypadku widocznych zmian, o stopniowym przechodzeniu na nową wersję systemu swoich klientów informował właściciel platformy.
Przejście na nową wersję systemu z perspektywy użytkownika
Zadbaliśmy o to, by użytkownicy nie odczuli żadnych nagłych czy negatywnych skutków przejścia na nowy system. Platforma była aktualizowana element po elemencie, a użytkownicy stopniowo przenoszeni do nowego systemu dopiero po sprawdzeniu jakości rozwiązania.
Przy okazji prowadzenia zmian w back-endzie platformy, klient zdecydował się odświeżyć również UX oraz UI (wygląd serwisu oraz ścieżkę podejmowanych akcji). Użytkownicy z pewnością mogli zauważyć zmianę – jednak na lepsze. Podobnie jak w przypadku ulepszania warstwy back-endowej, zmiany w wyglądzie też były wprowadzane stopniowo. Użytkownik, który na co dzień korzystał z serwisu, mógł zauważyć, że wygląd poszczególnych podstron jest inny.
Użytkownicy z pewnością zauważyli też pozytywną zmianę w kwestii prędkości serwisu. Niektóre widoki ładowały się dotychczas około pół minuty. Po całkowitym przejściu na nową wersję, ten sam widok, z tymi samymi danymi, wczytywał się mniej niż sekundę. Platforma dużo szybciej wykonywała procesy w warstwie back-endowej, dzięki czemu była w stanie zaserwować użytkownikowi informacje właściwie natychmiast.
Podsumowanie, CTA
Jeśli zauważasz, że możesz mieć problemy ze swoją platformą – że generuje ona zbyt duże koszty utrzymania, spowalnia rozwój firmy lub codzienne działania pracowników – zastanów się nad zleceniem audytu jakości technologicznej lub przeprowadzeniem migracji funkcjonalności. Możesz również skontaktować się z naszymi ekspertami, którzy razem z Tobą ocenią potrzebę przejścia na nową wersję systemu.
