Migracja schematu w jednym kroku

Kod, dane i usunięcie starego kontraktu trafiają do jednego wdrożenia, więc wersje nie mogą współistnieć, a rollback kończy się na niezgodnym schemacie.

Fikcyjny przykład edukacyjny. Nie opisuje konkretnej organizacji ani incydentu.

Sytuacja

Zespół zmienia nazwę i znaczenie kolumny używanej przez kilka instancji aplikacji. Ten sam pakiet wdrożeniowy dodaje nowe pole, przepisuje wszystkie rekordy, przełącza kod i usuwa stare pole. Plan zakłada, że wszystkie kroki zakończą się przed uruchomieniem ruchu.

Gdzie powstaje antywzorzec

Wdrożenie traktuje kod, schemat i wielomilionową migrację danych jak jedną chwilę. W praktyce instancje aplikacji zmieniają się stopniowo, migracja może trwać długo, a jeden krok może wymagać wycofania niezależnie od pozostałych. Destrukcyjne usunięcie starego pola odbiera starej wersji możliwość działania i może zamknąć drogę do rollbacku.

Sygnały ostrzegawcze

migracja zawiera DROP lub zmianę znaczenia pola przed wycofaniem wszystkich jego konsumentów;
plan nie określa macierzy zgodności wersji kodu i schematu;
backfill musi zakończyć się w jednym oknie serwisowym i nie można go bezpiecznie wznowić;
rollback opisuje tylko obraz aplikacji, a pomija dane zapisane po zmianie;
zakończenie migracji oznacza „skrypt wykonał się bez błędu”, bez pomiaru kompletności i zgodności.

Lepsza decyzja

Rozszerz schemat w sposób zgodny ze starą wersją.
Wprowadź jawny mechanizm zgodności dla zapisów w okresie przejściowym. Nie ukrywaj kosztu podwójnego zapisu: wskaż właściciela transformacji i mierz rozbieżności.
Migruj dane partiami za pomocą procesu idempotentnego i wznawialnego. Kontroluj blokady, obciążenie, postęp i rekordy pominięte.
Przełącz odczyt dopiero po spełnieniu mierzalnych kryteriów. Przetestuj wdrożenie mieszane i rollback.
Usuń stary kontrakt w osobnym wdrożeniu, gdy telemetria potwierdzi brak konsumentów, a okno wycofania zostało zamknięte.

Koszt kompromisu

Zmiana równoległa wydłuża migrację i przez pewien czas zwiększa złożoność. W zamian ogranicza promień błędu, pozwala obserwować kolejne kroki i oddziela zmianę odwracalną od destrukcyjnego sprzątania. Nie każda tabela wymaga skomplikowanej automatyzacji, ale każda destrukcyjna zmiana potrzebuje jawnej analizy zgodności.

Reguła do zapamiętania

Destrukcyjne sprzątanie nie powinno być pierwszym krokiem zmiany, której powodzenie dopiero trzeba potwierdzić.