Bezpiecznie zmieniaj istniejący system

Wskaż kontrakty wokół zmiany

Istniejące oprogramowanie ma wywołujących, zapisane dane, zaplanowane zadania i procedury operacyjne. Część zależności nie jest widoczna w edytowanym pliku. Agent może stworzyć lokalnie poprawną zmianę naruszającą jeden z tych kontraktów.

Przed implementacją wskaż komponenty czytające i zapisujące dotknięte dane. Sprawdź ścieżki, zadania w tle, raporty i integracje zewnętrzne. Ustal, czy inne zespoły lub starsze wersje klientów zależą od obecnego zachowania.

Poproś agenta o dowody dla tej mapy. Wynik wyszukiwania jest przydatnym początkiem, ale wywołania dynamiczne i zewnętrzni odbiorcy mogą wymagać potwierdzenia zależności przez właściciela.

Zapewnij obserwowalność obecnego zachowania

Dla słabo udokumentowanego modułu dodaj ukierunkowane kontrole zachowania, które musi pozostać stabilne. Opisują obecny kontrakt. Nie dowodzą, że każde istniejące zachowanie jest pożądane.

Jeśli obecne zachowanie koliduje z wymaganiem, zapisz konflikt. Nie zachowuj błędu bezpieczeństwa tylko dlatego, że utrwalił go test. Uzyskaj decyzję potrzebną do odróżnienia zamierzonego zachowania od defektu.

Używaj realistycznych danych testowych bez informacji wrażliwych. Uwzględnij stare struktury danych i niepełne rekordy, gdy mogą wystąpić. Nowy schemat testowany tylko na nowych danych może ukryć problemy migracji.

Przejrzyj przejście między wersjami

Rozważ fikcyjną zmianę nazwy z customer_name na display_name. Natychmiastowa zmiana może uszkodzić starą instancję aplikacji podczas wdrożenia. Aktualizacja obu plików w jednym pull requeście nie czyni wdrożenia atomowym.

Podejście etapowe może zachować zgodność:

1. Dodaj nowe pole bez usuwania starego.
2. Określ, jak nowe zapisy zachowają spójność wymaganych wartości.
3. Uzupełnij istniejące rekordy procesem możliwym do wznowienia.
4. Sprawdź kompletność i zachowanie odczytów.
5. Przenieś odczyty na nowe pole.
6. Usuń stare pole dopiero wtedy, gdy żaden komponent już z niego nie korzysta.

Dokładna metoda zależy od bazy i wzorców zapisu. Podwójne zapisy mogą wprowadzić niespójność, jeśli jeden się nie powiedzie. Może być potrzebna transakcja bazy lub inna jawna metoda synchronizacji. Nie stosuj przykładu bez sprawdzenia gwarancji systemu.

Martin Fowler opisuje to ogólne przejście jako parallel change, nazywane też expand-and-contract. Główna zasada to zgodne przejście przed usunięciem.

Zaplanuj odzyskiwanie osobno od rollbacku

Rollback kodu przywraca wcześniejszą wersję aplikacji. Nie cofa automatycznie migracji danych. Stara wersja może nie rozumieć nowych danych. Destrukcyjna migracja może usunąć informacje, których rollback kodu nie odzyska.

Wskaż działanie odzyskiwania dla każdego kroku. Wznawialne uzupełnianie danych może bezpiecznie kontynuować pracę. Błędne przekształcenie może wymagać poprawki z zachowanych danych źródłowych. Operacja destrukcyjna może wymagać zweryfikowanej procedury odtwarzania.

Zapytaj, kto odpowiada za decyzję o odzyskiwaniu i ile może ono potrwać. Nie traktuj stwierdzenia „mamy kopie zapasowe” jako dowodu spełnienia wymagania usługi.

Zachowaj możliwość review zmiany

Oddziel niezwiązane porządki od zmiany funkcjonalnej. Umieść plan zgodności, wyniki weryfikacji i warunki usunięcia w pull requeście. Oznacz punkt, po którym rollback wymaga dodatkowej pracy.

Agent może pomóc zbadać odbiorców i przygotować kod migracji. Odpowiedzialny właściciel nadal musi zaakceptować plan przejścia i odzyskiwania. Projekt końcowy to tylko część bezpiecznej zmiany.