Strategia wdrażania z rollbackiem w PHP nie polega na zachowaniu przycisku umożliwiającego powrót do poprzedniej wersji. To projekt operacyjny, który pozwala wycofać kod bez pozostawiania niekompatybilnych danych, zduplikowanych zadań asynchronicznych ani procesów w toku wykonujących już odrzucone reguły. Rollback musi być opcją przygotowaną przed publikacją, a nie improwizowaną reakcją podczas incydentu.
Małe wdrożenia ograniczają zasięg oddziaływania: wprowadzają mniej zmiennych, ułatwiają zidentyfikowanie zmiany, która spowodowała problem, i skracają czas przywracania. Mimo to niewielka zmiana może wpłynąć na płatności, uwierzytelnianie, uprawnienia, zapasy lub komunikację. Dlatego rozmiar zmiany nie zastępuje kontroli technicznych ani jednoznacznych kryteriów zatrzymania publikacji.
Rollback projektuje się, zanim wystąpi incydent
Wycofanie kodu jest proste tylko wtedy, gdy zmiana nie zmieniła współdzielonego stanu. Na produkcji dana wersja mogła zapisać dane, wysłać wiadomości do kolejki, aktywować zadanie harmonogramowane lub wywołać usługę zewnętrzną. Powrót do wcześniejszego commita bez przeanalizowania tych skutków może ukryć pierwotny błąd i utworzyć inny, trudniejszy do zdiagnozowania.
Przed zatwierdzeniem wdrożenia zespół musi umieć odpowiedzieć na cztery pytania:
- Jaki artefakt zostanie opublikowany: identyfikowalna wersja, zbudowana jeden raz i dostępna do przywrócenia.
- Jaki stan się zmienia: schemat bazy danych, cache, pliki, indeksy wyszukiwania, kolejki, zewnętrzni dostawcy i konfiguracja.
- Która wersja może odczytywać i zapisywać ten stan: nowy kod, poprzedni kod lub oba w trakcie tymczasowego okna.
- Jaki sygnał wymusza działanie: próg błędów, awaria krytycznej ścieżki, opóźnienie w kolejce, pogorszenie latencji lub potwierdzony wpływ funkcjonalny.
Jednostka wycofania musi być zdefiniowana. Może nią być cała aplikacja, usługa, konsument kolejki lub funkcjonalność aktywowana przez konfigurację. Nie należy mylić wdrożenia, które instaluje oprogramowanie, z release'em, który udostępnia określone zachowanie. Ich rozdzielenie pozwala wdrożyć nieaktywny kod i udostępnić go później, po zweryfikowaniu warunków technicznych.
Klasyfikowanie zmian według możliwości wycofania
Nie wszystkie zmiany można traktować tak samo. Korekta prezentacji lub wewnętrzna poprawka bez zmian stanu jest zwykle odwracalna przez przywrócenie poprzedniego artefaktu. Natomiast destrukcyjna migracja, zmiana kontraktu API lub nowa reguła biznesowa, która już wywołała skutki zewnętrzne, wymaga dodatkowej strategii.
Zmiany zwykle odwracalne
- Poprawki logiki zachowujące kontrakty wejścia i wyjścia.
- Zmiany szablonów, o ile nie zależą od usuniętych pól.
- Nowe ścieżki lub endpointy, które nie modyfikują istniejących zasobów.
- Wewnętrzne optymalizacje bez zmian schematu ani semantyki.
Zmiany wymagające tymczasowej kompatybilności
- Zmiana nazw lub zastępowanie kolumn, pól JSON i zdarzeń.
- Zmiany formatu wiadomości w kolejce lub webhooków.
- Nowe ograniczenia walidacji danych już istniejących.
- Modyfikacje uwierzytelniania, uprawnień lub reguł obliczeń.
- Integracje tworzące obciążenia, zamówienia, powiadomienia lub modyfikacje w systemach zewnętrznych.
W przypadku współdzielonych danych najbezpieczniejszym wzorcem jest zwykle rozszerz, zmigruj, ogranicz. Najpierw dodaje się kompatybilną strukturę, następnie kod tymczasowo obsługuje stary i nowy format, migruje lub uzupełnia wymagane dane, a dopiero po definitywnym wycofaniu starej wersji usuwa się elementy przestarzałe. Na przykład dodanie kolumny nullable i zapisywanie obu pól podczas przejścia jest odwracalne; bezpośrednia zmiana nazwy lub usunięcie kolumny używanej przez poprzednią wersję — nie jest.
Migracje należy traktować jako elementy dostarczane niezależnie od kodu. Migracja wyłącznie do przodu może być poprawna, ale wtedy plan musi określać, że rollback aplikacji nie oznacza wycofania schematu. Należy unikać automatycznej migracji w dół, jeśli może usunąć dane wygenerowane po zmianie lub jeśli jej wynik zależy od rzeczywistego stanu produkcji.
Przygotowanie artefaktów, konfiguracji i warunków wstępnych
Ten sam artefakt powinien przechodzić między środowiskami. Kompilowanie zależności lub bezpośrednia modyfikacja kodu na każdym serwerze uniemożliwia ustalenie, która wersja jest uruchomiona, i utrudnia przywrócenie znanej wersji. W aplikacji PHP artefakt może obejmować wersjonowany kod i rozwiązane zależności; wrażliwa konfiguracja specyficzna dla środowiska powinna być wstrzykiwana mechanizmami zewnętrznymi, a nie osadzona w pakiecie.
Należy rejestrować co najmniej identyfikator wersji, datę publikacji, istotną konfigurację funkcjonalną oraz osobę odpowiedzialną za decyzję. Przyspiesza to zarówno dochodzenie, jak i powrót do konkretnej wersji.
Przed wdrożeniem należy automatycznie i w widoczny sposób zweryfikować:
- Testy jednostkowe, integracyjne i kontraktowe proporcjonalne do zmiany.
- Rozwiązanie zależności oraz kompatybilność z wymaganą wersją PHP, rozszerzeniami i usługami.
- Stan migracji, plan rozszerzenia danych i szacowany czas wykonania.
- Kondycję zależności: bazy danych, cache, pamięci masowej, wewnętrznych API i krytycznych dostawców.
- Pojemność i zachowanie workerów, kolejek oraz zadań harmonogramowanych.
- Dostępność poprzedniego artefaktu i przetestowaną procedurę jego przywrócenia.
Kontrole nie powinny ograniczać się do tego, czy proces PHP odpowiada. Ścieżka health check może potwierdzać, że PHP-FPM jest aktywny, a mimo to nie wykrywać błędu autoryzacji, wolnego zapytania ani zablokowanego konsumenta. Należy zdefiniować małe syntetyczne ścieżki reprezentujące krytyczne operacje bez wykonywania nieodwracalnych działań.
Stopniowe publikowanie z jasnymi odpowiedzialnościami i limitami
Stopniowa ekspozycja ogranicza zasięg awarii, lecz działa tylko wtedy, gdy ruch lub instancje można rzeczywiście rozdzielić. Można zaktualizować część instancji, aktywować funkcjonalność dla kontrolowanego segmentu lub skierować część żądań do nowej wersji. Wybór zależy od architektury i rodzaju współdzielonego stanu.
Podczas okna publikacji należy przypisać jednoznaczne role:
- Jedna osoba wykonuje i rejestruje kroki.
- Druga obserwuje istotne metryki, logi i trace'y.
- Osoba odpowiedzialna ma uprawnienia do zatrzymania lub wycofania bez oczekiwania na niejednoznaczne zatwierdzenia.
- Zespół biznesowy lub wsparcia zna oczekiwane skutki, jeśli zmiana dotyczy wrażliwej operacji.
Należy również ustanowić okno obserwacji. Nie wystarczy opublikować zmianę, zobaczyć poprawną odpowiedź HTTP i przejść do kolejnej zmiany. Niektóre defekty pojawiają się podczas przetwarzania kolejki, wygaśnięcia cache, uruchomienia zadania harmonogramowanego lub ukończenia przez użytkownika dłuższego przepływu.
Weryfikacja po wdrożeniu: usługa, dane i skutki biznesowe
Weryfikacja po wdrożeniu powinna łączyć sygnały techniczne i funkcjonalne. Ogólne metryki są przydatne, lecz stabilna średnia latencja może ukryć awarię mniejszościowej, ale krytycznej operacji.
- Krytyczne ścieżki: uwierzytelnianie, główny odczyt i zapis, płatności, tworzenie zamówień lub działania wymagające uprawnień.
- Błędy: wyjątki PHP, odpowiedzi 5xx, nieoczekiwany wzrost 4xx, błędy walidacji i awarie zależności.
- Wydajność: latencja według endpointu, nasycenie workerów, połączenia z bazą danych i zużycie zasobów.
- Przetwarzanie asynchroniczne: rozmiar i wiek kolejki, ponowne próby, nieudane wiadomości i idempotencja.
- Skutki biznesowe: niekompletne transakcje, duplikaty, nieprawidłowe zmiany stanu lub spadki konwersji, które zespół może zweryfikować.
Kryteria decyzyjne muszą być weryfikowalne. Należy kontynuować, jeśli zdefiniowane ścieżki działają, nie występuje trwały wzrost błędów, a kolejki pozostają w granicach dopuszczalnego opóźnienia. Należy zatrzymać ekspansję, jeśli pojawi się anomalia, która nadal wymaga diagnozy. Należy wycofać zmianę, jeśli poprzedni artefakt jest kompatybilny z aktualnym stanem, a przywrócenie wyraźnie ogranicza wpływ. Należy poprawiać do przodu, jeśli wycofanie zerwałoby kompatybilność, nie cofnęłoby skutków zewnętrznych lub trwałoby dłużej niż wdrożenie odizolowanej i zwalidowanej poprawki.
Zarządzanie kolejkami i procesami uruchomionymi przez wycofaną wersję
Workery są częstym źródłem niepełnych rollbacków. Kod webowy może zostać wycofany, gdy pozostają wiadomości utworzone przez nową wersję lub procesy długotrwałe, które nadal wykonują starą logikę. Plan musi wskazywać, jak opróżniać, wstrzymywać, restartować lub izolować konsumentów bez utraty śledzalności.
Rozważmy hipotetyczny przepływ: aplikacja PHP publikuje wiadomość w celu potwierdzenia zamówienia. Nowa wersja dodaje pole do wiadomości i modyfikuje stan zamówienia przed jej wysłaniem. Jeśli trzeba ją wycofać, poprzedni konsument musi bezpiecznie ignorować dodatkowe pole albo wiadomość musi zawierać wersję pozwalającą skierować ją do kompatybilnego konsumenta. Ponadto potwierdzenie musi używać klucza idempotencji, aby ponowna próba nie spowodowała dwóch działań zewnętrznych.
{
"event": "order.confirmation_requested",
"schema_version": 2,
"idempotency_key": "operacion-unica",
"order_id": "identificador"
}Przed wycofaniem należy w razie potrzeby wstrzymać napływ nowych zadań, zidentyfikować wiadomości w tranzycie i potwierdzić, którzy konsumenci mogą je przetwarzać. Następnie należy w kontrolowany sposób przeanalizować niepowodzenia i ponowne próby. Nie należy usuwać kolejki, aby szybciej odzyskać sprawność: może to usunąć potrzebne dowody lub pozostawić operacje biznesowe w połowie ukończone.
Przekształcenie planu w powtarzalną praktykę
Dojrzała strategia nie zależy od indywidualnej pamięci. Dla każdej usługi należy utrzymywać krótki runbook z zatwierdzonymi poleceniami, lokalizacją logów, panelami obserwacyjnymi, osobami odpowiedzialnymi, warunkami zatrzymania i znanymi ograniczeniami wycofania. Procedurę należy przećwiczyć w reprezentatywnym środowisku, szczególnie po zmianach infrastruktury, kolejek, migracji lub integracji.
Po każdym incydencie lub rollbacku należy sprawdzić, czy zawiodło wykrywanie, kompatybilność, automatyzacja czy decyzja. Celem nie jest uniknięcie każdego wycofania; jest nim możliwość wyboru między wycofaniem a poprawą do przodu przy wystarczających informacjach, bez przekształcania lokalnego incydentu w utratę danych lub większą przerwę w działaniu.
