Měňte existující systém bezpečně

Určete kontrakty v okolí změny

Existující software má volající komponenty, uložená data, naplánované úlohy a provozní postupy. Některé závislosti nejsou v souboru, který chcete upravit, viditelné. Agent může vytvořit lokálně správnou změnu, která jeden z těchto kontraktů poruší.

Před implementací určete komponenty, které dotčená data čtou a zapisují. Prozkoumejte cesty požadavků, úlohy na pozadí, sestavy a externí integrace. Ověřte, zda na současném chování závisejí jiné týmy nebo starší verze klientů.

Požádejte agenta, aby tuto mapu podložil důkazy. Výsledek hledání je užitečný začátek, ale dynamická volání a externí systémy mohou vyžadovat potvrzení závislosti od odpovědné osoby.

Zajistěte pozorovatelnost současného chování

U špatně zdokumentovaného modulu přidejte cílené kontroly chování, které musí zůstat stabilní. Tyto kontroly popisují současný kontrakt. Neprokazují, že je každé existující chování žádoucí.

Pokud současné chování odporuje požadavku, rozpor zaznamenejte. Nezachovávejte bezpečnostní chybu jen proto, že ji zachytil test. Získejte rozhodnutí potřebné k odlišení zamýšleného chování od chyby.

Použijte realistická testovací data bez citlivých informací. Zahrňte staré datové struktury a neúplné záznamy tam, kde se mohou vyskytovat. Nové schéma testované pouze s nově vytvořenými daty může skrýt problémy migrace.

Posuďte přechod mezi verzemi

Představte si fiktivní přejmenování customer_name na display_name. Okamžité přejmenování může během nasazování rozbít starou instanci aplikace. Aktualizace obou souborů v jednom pull requestu nezajistí atomické nasazení.

Postupný přechod může zachovat kompatibilitu:

1. Přidejte nové pole bez odstranění starého.
2. Definujte, jak nové zápisy udrží potřebné hodnoty v souladu.
3. Doplňte existující záznamy procesem, který lze po přerušení znovu spustit.
4. Ověřte úplnost a chování komponent, které data čtou.
5. Přepněte tyto komponenty na nové pole.
6. Staré pole odstraňte až poté, co je přestanou používat všechny komponenty.

Přesný postup závisí na databázi a způsobu zápisu. Dvojí zápis může způsobit nekonzistenci, pokud jeden zápis selže. Může být nutná databázová transakce nebo jiný výslovný způsob synchronizace. Příklad nepoužívejte bez ověření záruk systému.

Martin Fowler popisuje tento obecný přechod jako parallel change, také nazývaný expand-and-contract. Podstatou je kompatibilní přechod před odstraněním.

Obnovu plánujte odděleně od rollbacku

Rollback kódu obnoví dřívější verzi aplikace. Automaticky nevrátí datovou migraci. Stará verze nemusí novým datům rozumět. Destruktivní migrace může odstranit informace, které rollback kódu neobnoví.

Pro každý krok určete postup obnovy. V přerušeném doplňování dat může být bezpečné pokračovat, pokud lze proces znovu spustit. Nesprávná transformace může vyžadovat opravu ze zachovaných zdrojových dat. Destruktivní operace může vyžadovat ověřený postup obnovení.

Ptejte se, kdo odpovídá za rozhodnutí o obnově a jak dlouho může trvat. Tvrzení „máme zálohy“ nepovažujte za důkaz, že obnova splňuje požadavek služby.

Udržujte změnu zkontrolovatelnou

Oddělte nesouvisející úklid kódu od funkční změny. V pull requestu uveďte plán kompatibility, výsledky ověření a podmínky odstranění. Označte bod, po kterém rollback vyžaduje další práci.

Agent může pomoci prozkoumat komponenty využívající data a připravit migrační kód. Odpovědná osoba stále musí přijmout plán přechodu a obnovy. Konečný návrh je jen jednou součástí bezpečné změny.