Nasze podejście
Wprowadzamy zmiany w aplikacji tak, aby kluczowe procesy, dane i integracje nadal działały.
Zmiana w działającej aplikacji nie kończy się na wdrożeniu kodu. Może dotknąć zamówień, płatności, faktur, uprawnień, integracji i pracy zespołu. Dlatego najpierw ustalamy, który proces ma pozostać nieprzerwany i kiedy jego zmiana byłaby najbardziej ryzykowna.
Ważny proces biznesowy
↓
Mała, jasno opisana zmiana
↓
Testy i kontrolowane wdrożenie
↓
Sprawdzenie wyniku lub poprawkaŁączenie aktualizacji frameworka, migracji bazy, nowego interfejsu i integracji płatności w jednym wydaniu utrudnia znalezienie przyczyny problemu. Wolimy dzielić pracę na mniejsze etapy. Przy zmianie operatora płatności można najpierw zachować obecny checkout, dodać wydzielony moduł płatności i uruchomić nową ścieżkę dla ograniczonej grupy transakcji.
To nie eliminuje ryzyka, ale ogranicza jego zasięg i pozwala szybciej ocenić, co faktycznie się wydarzyło.
Testy powinny obejmować zachowanie ważne dla firmy: kto ma dostęp do danych, czy zamówienie powstaje tylko raz, czy faktura jest wygenerowana i co dzieje się po błędzie usługi zewnętrznej. W starszym systemie testy mogą najpierw opisać obecne zachowanie, zanim je zmienimy.
Po wdrożeniu patrzymy także na rzeczywistą pracę systemu. Zużycie procesora nie powie, czy płatności są potwierdzane, kolejka nie rośnie i użytkownik może ukończyć zamówienie.
Integrację z płatnościami, ERP, CRM czy kurierem warto odseparować od reszty aplikacji. Dzięki temu zmiana dostawcy nie wymaga zmian w zamówieniach, fakturach i panelu klienta.
Zmiany w bazie planujemy tak, aby przez krótki czas mogły współpracować stare i nowe wersje aplikacji. Dotyczy to również workerów, importów i powiadomień. Jeśli ten sam komunikat płatniczy przyjdzie dwa razy, system musi rozpoznać powtórkę i nie utworzyć drugiego zamówienia. Błąd powinien być widoczny, a ponowienie bezpieczne.
Gdy to możliwe, zaczynamy od użytkowników wewnętrznych, jednej organizacji lub wybranego rodzaju transakcji. Rozszerzamy zmianę dopiero po sprawdzeniu jej działania.
Przed wdrożeniem ustalamy też drogę wyjścia. Czasem wystarczy wrócić do poprzedniej wersji kodu. Jeśli dane zostały już zmienione albo zewnętrzny system otrzymał nową informację, bezpieczniejsza będzie kontrolowana poprawka w działającym systemie.
Pomagamy określić zakres zmiany, sprawdzić krytyczne procesy, przygotować testy i sygnały do obserwacji oraz zaplanować wdrożenie. Celem jest rozwój aplikacji bez niepotrzebnego zakłócania codziennej pracy, a nie obietnica braku każdego incydentu.