Wdrożenie kodu i zmiana bazy nie dzieją się jednocześnie
Podczas aktualizacji część procesów może już działać na nowym kodzie, a część nadal kończyć zadania w starej wersji. Jeśli usuniesz kolumnę przed zakończeniem tych prac, stary proces przestanie rozumieć bazę. Problem dotyczy również kolejek, raportów i integracji, nie tylko publicznego formularza. Dlatego zaplanuj okres współistnienia wersji. Zmiana schematu jest umową między wszystkimi klientami danych, a nie wyłącznie plikiem wykonywanym przy publikacji.
W przykładowym programie proste pole „aktywne” ma zostać zastąpione kilkoma stanami obsługi. Bezpośrednia podmiana może utracić znaczenie dawnych wartości lub zepsuć raport. Najpierw opisz mapowanie: co stanie się z każdym istniejącym przypadkiem, także wartością pustą. Ustal, czy nowe stany da się przedstawić w starym modelu. Gdy odpowiedź brzmi „nie”, cofnięcie kodu po rozpoczęciu używania nowych funkcji wymaga dodatkowej decyzji, a nie samego przycisku rollback.
Etap rozszerzenia pozostawia stare interfejsy działające
Dodaj nową strukturę bez natychmiastowego usuwania poprzedniej. Następnie wdrażaj kod, który potrafi z nią współpracować, ale nie wymusza od razu zmiany wszystkich odczytów. Taki podział pozwala osobno ocenić poprawność schematu i logiki aplikacji. Samo dodanie kolumny nie gwarantuje jednak braku blokad. Koszt zależy od silnika, wersji, rozmiaru tabeli, wartości domyślnej i rodzaju ograniczeń. Sprawdź plan na reprezentatywnym środowisku.
Jeżeli w okresie przejściowym zapisujesz dane w dwóch miejscach, zadbaj o ich spójność. Dwa niezależne zapisy bez kontroli błędu mogą pozostawić różne wartości. Ustal, która reprezentacja jest nadrzędna i jak naprawisz rozbieżność. Nie ukrywaj przejściowego długu w kodzie bez terminu usunięcia. W dokumentacji wydania wskaż kompatybilne wersje aplikacji, kolejność kroków i warunek, po którym wolno przejść do następnego etapu.
Przenoszenie istniejących danych powinno dać się wznowić
Dla dużej tabeli jednorazowa aktualizacja wszystkich wierszy może być zbyt kosztowna. Przetwarzanie partiami pozwala ograniczyć obciążenie i obserwować wynik. Zapisuj postęp według stabilnego klucza, kontroluj czas partii i przewidź ponowienie po awarii. Operacja wznowiona nie powinna zmieniać danych drugi raz w inny sposób. Sprawdź również rekordy dopisywane w trakcie migracji; historyczne dane i bieżące zapisy muszą spotkać się w jednym, spójnym modelu.
Nie zastępuj wszystkich niezrozumiałych wartości arbitralnym stanem „inne” tylko po to, aby licznik doszedł do końca. Zapisz wyjątki do oceny i ustal kryteria akceptacji. W przykładzie zmiany statusów istotne jest nie tylko przeniesienie liczby wierszy, lecz zachowanie ich biznesowego znaczenia. Porównaj sumy według kategorii, próbki rekordów i zachowanie raportów. Liczba przetworzonych pozycji nie dowodzi, że mapowanie było prawidłowe.
Przełączenie odczytów wymaga obserwacji działania
Gdy nowe dane są gotowe, przełącz wybrane odczyty i porównuj wynik z poprzednią reprezentacją. Zacznij od procesu, dla którego łatwo rozpoznać rozbieżność, zamiast jednocześnie zmieniać każdy ekran. Sprawdź nie tylko brak wyjątków, ale również kompletność wyników, sortowanie, filtrowanie i czas odpowiedzi. Nowa kolumna bez odpowiedniego indeksu może być poprawna logicznie, a jednocześnie spowolnić najczęściej używaną listę.
Przydatny jest jawny punkt zatrzymania wdrożenia. Jeśli porównanie pokaże niezgodność, zespół powinien wiedzieć, czy wrócić do starego odczytu, poprawić mapowanie czy wstrzymać nowe zapisy. Nie podejmuj takiej decyzji dopiero w czasie awarii. Określ również, jak długo utrzymasz możliwość powrotu. Kompatybilność ma granice: gdy użytkownicy zaczną tworzyć stany nieobsługiwane przez stary kod, prosty powrót może przestać być bezpieczny.
Usuwanie starej struktury jest oddzielnym wydaniem
Przed usunięciem kolumny upewnij się, że nie czyta jej żaden aktywny proces, raport, eksport ani zadanie uruchamiane raz w miesiącu. Szukanie nazwy wyłącznie w głównym repozytorium nie wykryje ręcznego skryptu pozostawionego na hostingu. Ustal właścicieli integracji i potwierdź zakończenie przejścia. Etap porządkowania powinien mieć osobny przegląd, ponieważ właśnie wtedy kończy się część możliwości prostego cofnięcia.
Nie pozostawiaj starej struktury na zawsze bez decyzji. Podwójny model zwiększa koszt rozwoju i ryzyko, że ktoś zacznie ponownie używać niewłaściwego pola. Po zakończeniu okresu obserwacji usuń zbędny kod, testy przejściowe i flagi. Zachowaj natomiast historię migracji oraz opis mapowania. Osoba diagnozująca dane po kilku miesiącach powinna wiedzieć, skąd wziął się nowy status i jak interpretować informacje utworzone przed zmianą.
Odbiór obejmuje przerwanie i powtórzenie procesu
Na kopii testowej przejdź całą sekwencję ze starą i nową wersją kodu. Przerwij przenoszenie w połowie, wznow je i sprawdź zgodność wyników. Uruchom stare zadanie kolejki po rozszerzeniu schematu. Przetestuj blokady oraz limity czasu przy obciążeniu zbliżonym do produkcyjnego. Mała, pusta baza nie ujawni problemu, który wystąpi dopiero przy dużej tabeli i równoczesnej pracy użytkowników. W planie zostaw także kontrolę kopii przed nieodwracalnym etapem.
Zapisz listę warunków zakończenia: brak wyjątków mapowania, zgodne wyniki porównań, akceptowalny czas zapytań i brak klientów starego interfejsu. Unikaj określenia „migracja zakończona”, jeśli jedynie wykonano pierwszy skrypt. Całość kończy się dopiero wtedy, gdy kod, dane i utrzymanie korzystają z nowego modelu. Etapowe podejście nie usuwa ryzyka, ale pozwala wykrywać problem przed krokiem, którego cofnięcie kosztowałoby najwięcej.