Po wadliwym wydaniu samo uruchomienie wcześniejszej wersji aplikacji bywa proste. Problem pojawia się wtedy, gdy razem z kodem zmieniono konfigurację, schemat SQL albo dane przetwarzane przez zadanie w tle, a każda z tych zmian wymaga innego sposobu cofnięcia. Prywatna infrastruktura G2E zapewnia stałe miejsce dla serwerów aplikacji, bazy, prywatnej komunikacji i backupu VM. O czasie usunięcia skutków decyduje jednak zgodność wersji oraz wybór między wcześniejszym kodem, korektą danych i przywróceniem bazy.
Najpierw rodzaj zmiany
Kod, konfiguracja, struktura bazy i dane biznesowe nie tworzą jednego pakietu. Kod można zastąpić poprzednią wersją. Konfiguracja może znajdować się w pliku, sekrecie lub usłudze poza repozytorium. Migracja SQL zmienia tabele albo ich zawartość, a zadanie w tle potrafi przetworzyć wiele rekordów już po uruchomieniu nowej aplikacji.
Opis wydania rozdziela te elementy. Dla kodu podaje poprzednią wersję i jej zgodność z bieżącym schematem. Dla konfiguracji wskazuje miejsce poprzednich ustawień. Przy migracji opisuje zmianę struktury, sposób obsługi obu wersji i wpływ na dane utworzone po wdrożeniu. Zadanie w tle ma określony sposób zatrzymania oraz rozliczenia częściowo wykonanej pracy.
Klasa zmiany wpływa na dopuszczalny czas diagnozy. Korekta tekstu w interfejsie nie ma tego samego znaczenia co zmiana tabeli używanej przy fakturowaniu. Im większy wpływ na zapis danych i proces klienta, tym wcześniej potrzebny jest przygotowany wariant wycofania.
Osobną kategorią są skutki poza aplikacją, na przykład wysłana wiadomość albo dane przekazane do systemu zewnętrznego. Wcześniejszy kod nie cofnie czynności wykonanej po drugiej stronie integracji. Dla takiej zmiany potrzebna jest reguła zatrzymania, uzgodnienia lub korekty przygotowana jeszcze przed wydaniem.
Stałe środowisko na prywatnej infrastrukturze
Aplikację i bazę klient lub integrator może uruchomić na serwerach wirtualnych G2E w prywatnej sieci, z backupem VM zgodnym z zakresem usługi. Daje to znane miejsce dla systemów, reguł dostępu i kopii. Nie tworzy automatycznie zgodności między wersją kodu a SQL i nie wybiera sposobu wycofania wydania.
Aplikacją, schematem bazy, skryptami migracyjnymi oraz kolejnością wdrożenia zarządza klient lub integrator. Administrator infrastruktury obsługuje serwery i kopie w uzgodnionym zakresie. To rozróżnienie wystarczy zapisać raz: podczas incydentu każda strona sięga do informacji dotyczących własnej części i nie reaguje na błąd kodu przypadkową zmianą zasobów.
Środowisko przedprodukcyjne może działać na oddzielnych serwerach tej samej prywatnej infrastruktury. Jego przydatność zależy od zgodności wersji usług, konfiguracji, ról, schematu danych i integracji z produkcją. Nie musi kopiować danych wrażliwych; potrzebuje bezpiecznych przypadków odzwierciedlających krytyczne operacje klienta.
Dane przedprodukcyjne obejmują także trudniejsze przypadki, nie tylko pustą bazę i jedno poprawne konto. Częściowo opłacone zamówienie, różne role użytkowników, przerwane zadanie oraz rekord utworzony przez starszą wersję pokazują, czy nowy kod i migracja zachowują zgodność w miejscach ważnych dla klienta.
Wcześniejszy kod bez cofania danych
Najłagodniejszy wariant polega na uruchomieniu poprzedniej wersji aplikacji przy zachowaniu aktualnej bazy. Jest możliwy, gdy migracja pozostaje zgodna wstecz. Nowe kolumny mogą istnieć, lecz starszy kod nadal rozumie potrzebną część schematu, a funkcję lub zadanie da się wyłączyć.
W takim przypadku nie przywraca się całej maszyny. Integrator uruchamia wcześniejszy kod, przywraca właściwą konfigurację i ocenia podstawowe operacje na rekordach utworzonych już po zmianie. Poprawne zamówienia, dokumenty i inne transakcje pozostają w bazie, więc usunięcie błędu aplikacji nie powoduje utraty transakcji wykonanych po wdrożeniu.
Ta droga wymaga migracji rozłożonej na etapy. Najpierw dodaje się strukturę, z którą mogą współpracować obie wersje. Następnie nowy kod przejmuje użycie pól. Usuwanie starego układu następuje po okresie stabilnej pracy, a nie w tym samym wydaniu, które ma jeszcze zachować możliwość szybkiego cofnięcia.
Jeżeli nowe zadanie zdążyło zmienić dane, sam wcześniejszy kod może nie wystarczyć. Trzeba wtedy ustalić, czy skutki mają ograniczony zakres i nadają się do korekty, czy objęły bazę na tyle szeroko, że potrzebne jest przywrócenie z kopii.
Korekta albo przywrócenie bazy
Korekta jest właściwa, gdy błędne rekordy można jednoznacznie odróżnić od poprawnych. Pomaga identyfikator wydania, znacznik operacji lub wykaz obiektów zmienionych przez zadanie. Integrator dobiera sposób rozpoznania do modelu aplikacji, a skrypt naprawczy działa tylko na opisanym zakresie.
Pełne cofnięcie bazy w takiej sytuacji mogłoby usunąć prawidłowe transakcje wykonane po wdrożeniu. Bezpieczniej pozostawić bieżące dane, uruchomić wcześniejszą wersję kodu i skorygować wyłącznie skutki błędu. Skrypt korekty wymaga tej samej ostrożności co migracja: znanego zakresu, możliwości zatrzymania oraz ochrony przed ponownym przeliczeniem dobrych rekordów.
Przywrócenie z kopii ma sens, gdy uszkodzenie jest szerokie, zawartość bazy przestała być wiarygodna albo korekta niosłaby większe ryzyko. Przed użyciem kopii trzeba znać moment jej wykonania, zakres maszyny i transakcje zapisane później. Utrata tych zmian jest skutkiem biznesowym, którego nie rozwiązuje samo techniczne uruchomienie SQL.
Przed wydaniem zespół ustala, jak długo może trwać odzyskanie działania i jaką utratę najnowszych danych firma może zaakceptować. Te granice pomagają porównać dalszą diagnozę, powrót do wcześniejszego kodu, korektę rekordów i przywrócenie bazy. Sama obecność serwera lub backupu niczego tu nie gwarantuje.
Znajomość kopii oznacza więcej niż widoczny plik. Trzeba rozumieć, czy obejmuje aplikację, bazę oraz konfigurację potrzebną do uruchomienia, a także jak zachowają się integracje po przywróceniu. Próba w odizolowanym środowisku ujawnia brakujące zależności bez naruszania bieżącej produkcji.
Próg wycofania przed wydaniem
Przed wdrożeniem trzeba nazwać objawy, przy których dalsza naprawa na produkcji przestaje być rozsądna. Niedziałające logowanie, zapis zamówienia, płatność lub generowanie dokumentu mogą otrzymać krótki czas na diagnozę. Po jego upływie dalsze eksperymenty na danych klienta zostają przerwane i wybiera się przygotowaną drogę.
Komunikat dla klienta odnosi się do skutku: które operacje są niedostępne, czy zapis danych został zatrzymany i jaki wariant wycofania został uruchomiony. Nie trzeba obiecywać czasu bez oparcia w ustaleniach. Ważniejsze jest odróżnienie awarii infrastruktury od błędu aplikacji oraz jasne wskazanie zmian, które mogą wpłynąć na dane.
Wybór powinien wynikać z rodzaju szkody: wcześniejszy kod przy zachowanej zgodności, ograniczona korekta przy rozpoznawalnych rekordach, przywrócenie bazy przy szerokim uszkodzeniu. Przygotowanie tych trzech dróg przed wydaniem skraca wycofanie bardziej niż improwizowana naprawa prowadzona już pod presją przestoju.