Wyzwanie
Aplikacja miała płacących użytkowników i szybko rosła, a poprzedni wykonawca odchodził. Audyt pokazał 8 przestojów backendu w pół roku bez żadnego alertu, brak kopii zapasowych bazy, brak testów i automatycznych wdrożeń oraz brak trwałych logów, więc błędów serwera nie dało się zbadać. Nie było nawet pewności, która wersja kodu działa na produkcji.
Użytkownicy zgłaszali, że skaner i wyszukiwarka nie znajdują jedzenia, a dostępy do infrastruktury wciąż mieli byli wykonawcy.
Podejście
Zaczęliśmy od audytu tylko do odczytu: kod aplikacji, backend, serwer i płatności. Na tej podstawie ułożyliśmy pakiety prac w kolejności ryzyka. Każdą tezę z audytu sprawdzaliśmy przed napisaniem kodu. Jedna z nich, o brakującej obsłudze zwrotów, okazała się nieprawdziwa, więc nie powstał zbędny moduł.
Na produkcji obowiązuje prosta zasada: każda zmiana ma ścieżkę powrotu i kopię danych, a każdą operację zatwierdzamy osobno. Pomiary na żywej bazie robimy wyłącznie w transakcjach tylko do odczytu.
Wdrożenie
Odcięliśmy dostępy byłych wykonawców, przejęliśmy repozytorium wdrożeniowe i naprawiliśmy kilkanaście problemów bezpieczeństwa serwera i API. Audyt płatności i logowania dał 24 zgłoszenia, z których po weryfikacji 6 było prawdziwych. Wśród nich: rejestracja w jednostkach imperialnych była w praktyce niemożliwa, a błąd sieci wylogowywał opłacone konto.
Katalog produktów zbudowaliśmy od nowa jako własny indeks łączący otwarte bazy żywności i tabele referencyjne, z polską lematyzacją, synonimami i poprawą literówek. Lokalizację na 47 języków przygotowaliśmy z twardą walidacją kluczy, zmiennych i liczby mnogiej.
Wyniki
Wyszukanie produktu, które wcześniej trwało ponad 2 s i dawało błędny wynik, zajmuje teraz 77 ms. Aplikacja działa w 47 językach. Przejście produkcji na nowe wydanie w sierpniu kosztowało 11 s przerwy, a po wydaniu z października serwer nie zanotował ani jednego błędu 5xx.
Backend ma 859 testów, aplikacja 2530. W tym czasie baza urosła z ok. 700 użytkowników w maju do ponad 10 tys. kont na początku października.
