Naprawa procesu wydań dla platformy SaaS z Wrocławia
Zredukowaliśmy liczbę krytycznych błędów o 31% w ciągu pierwszych 2 miesięcy współpracy. Wprowadziliśmy automatyczne bramki jakości w CI/CD.
CloudNode z Wrocławia to platforma obsługująca 83 firmy handlowe, która borykała się z niestabilnym kodem. Każda aktualizacja w środy o 14:00 kończyła się nerwowym sprawdzaniem logów i gaszeniem pożarów na produkcji. Pomogliśmy im to wyprostować, bo kod musi zarabiać, a nie sypać błędami.
Wyzwanie
W CloudNode proces testowania niemal nie istniał, a 3 programistów marnowało około 12 godzin tygodniowo na poprawianie regresji. Średnio co drugie wydanie blokowało kluczowe funkcje, takie jak wystawianie faktur czy edycja koszyka. Szczerze: testy manualne w ich wykonaniu to była strata czasu, bo deweloperzy sprawdzali tylko to, co sami napisali, omijając resztę systemu.
Sytuacja była napięta, bo klienci zaczęli zgłaszać pretensje o błędy, które wracały jak bumerang. Zespół liczył 7 osób i brakowało im kogoś, kto spojrzy na architekturę testów z boku. Mieli 47 otwartych zgłoszeń o błędach, których nikt nie potrafił powtórzyć w środowisku lokalnym.
Podejście
Zaczęliśmy od audytu 5 najbardziej wrażliwych punktów w aplikacji, zamiast opisywać cały system. Nie robiliśmy nudnych prezentacji — od razu przeszliśmy do konkretów. W drugim tygodniu TyeVals przejęło konfigurację GitLab CI, aby wyeliminować ręczne wrzucanie kodu na serwer stagingowy.
Postawiliśmy na automatyzację ścieżek krytycznych. Nasz 2-osobowy zespół pracował ramię w ramię z ich deweloperami, pokazując im, jak pisać testy, które faktycznie coś wykrywają. Ustawiliśmy procesy, które działają same: teraz każde wypchnięcie kodu do repozytorium wyzwala serię 47 szybkich testów API.
Rozwiązanie
Wdrożyliśmy solidne bramki jakości oparte na narzędziu Playwright. Jeśli jakikolwiek test regresji nie przejdzie, proces budowania wersji zostaje przerwany — bez żadnych wyjątków. Dodaliśmy też automatyczne powiadomienia na Slacku, które informują zespół o błędach w zaledwie 3.2 sekundy po ich wystąpieniu w środowisku testowym.
Zrezygnowaliśmy z pisania testów dla każdej drobnej funkcji. Skupiliśmy się na tym, co przynosi pieniądze: logowaniu, płatnościach i generowaniu raportów. Dzięki temu pipeline CI/CD nie trwa godziny, a zaledwie 12 minut. Bez zbędnego lania wody i komplikowania tam, gdzie wystarczą proste rozwiązania.
Rezultaty
Platforma stała się przewidywalna. Zespół CloudNode przestał bać się śród, a czas potrzebny na przygotowanie stabilnego wydania skrócił się o ponad połowę. Programiści mogą w końcu skupić się na budowaniu nowych funkcji, a nie na łataniu tych samych dziur po raz czwarty.
Harmonogram
-
Marzec 2024Audyt 5 krytycznych ścieżek użytkownika i naprawa CI/CD.
-
Kwiecień 2024Wdrożenie testów E2E dla modułu płatności i zamówień.
-
Maj 2024Uruchomienie automatycznych powiadomień o błędach na Slacku.
-
Czerwiec 2024Przekazanie dokumentacji i szkolenie wewnętrzne zespołu.
"Byliśmy sceptyczni co do automatyzacji, bo baliśmy się kosztów. Ale TyeVals pokazało nam, że realnie traciliśmy więcej na poprawkach. Teraz wydajemy kod bez stresu i w końcu mamy porządek w procesie."