Bezpečne zmeňte existujúci systém

Určte kontrakty, ktorých sa zmena týka

Existujúci softvér má volajúce komponenty, uložené údaje, naplánované úlohy a prevádzkové postupy. Niektoré závislosti nie sú viditeľné v súbore, ktorý chcete upraviť. Agent môže vytvoriť lokálne správnu zmenu, ktorá poruší niektorý z týchto kontraktov.

Pred implementáciou určte komponenty, ktoré dotknuté údaje čítajú alebo zapisujú. Preskúmajte routes, úlohy na pozadí, reporty a externé integrácie. Overte, či od aktuálneho správania závisia iné tímy alebo staršie verzie klientov.

Požiadajte agenta, aby pre tento prehľad ukázal dôkazy. Výsledok vyhľadávania je užitočný začiatok, ale dynamické volania a externé systémy využívajúce rozhranie môžu vyžadovať potvrdenie závislosti zodpovednou osobou.

Umožnite pozorovať aktuálne správanie

Pri slabo zdokumentovanom module pridajte cielené kontroly správania, ktoré musí zostať stabilné. Tieto kontroly opisujú aktuálny kontrakt. Nepreukazujú, že je každé existujúce správanie žiaduce.

Ak je aktuálne správanie v rozpore s požiadavkou, zaznamenajte rozpor. Nezachovávajte bezpečnostnú chybu iba preto, že ju zachytil test. Získajte rozhodnutie potrebné na rozlíšenie zamýšľaného správania od chyby.

Použite realistické testovacie dáta bez citlivých údajov. Zahrňte staré štruktúry údajov a neúplné záznamy tam, kde sa môžu vyskytnúť. Nová schéma testovaná iba s novovytvorenými údajmi môže skryť problémy migrácie.

Preskúmajte prechod medzi verziami

Zvážte fiktívne premenovanie z customer_name na display_name. Okamžité premenovanie môže počas nasadenia narušiť starú inštanciu aplikácie. Aktualizácia oboch súborov v jednom pull requeste neurobí nasadenie atómovým.

Postupný prístup môže zachovať kompatibilitu:

1. Pridajte nové pole bez odstránenia starého.
2. Určte, ako nové zápisy udržia požadované hodnoty konzistentné.
3. Doplňte existujúce záznamy procesom, ktorý možno po prerušení znova spustiť.
4. Overte úplnosť a správanie čítajúcich komponentov.
5. Presuňte čítajúce komponenty na nové pole.
6. Staré pole odstráňte až vtedy, keď ho už žiadne komponenty nepoužívajú.

Presný spôsob závisí od databázy a vzorov zápisu. Dvojitý zápis môže spôsobiť nekonzistentnosť, ak jeden zápis zlyhá. Môže byť potrebná databázová transakcia alebo iný výslovný spôsob synchronizácie. Tento príklad nepoužívajte bez overenia záruk systému.

Martin Fowler tento všeobecný prechod opisuje ako parallel change, nazývaný aj expand-and-contract. Hlavnou myšlienkou je kompatibilný prechod pred odstránením.

Plánujte obnovu oddelene od rollbacku

Rollback kódu obnoví skoršiu verziu aplikácie. Automaticky však nevráti migráciu údajov. Stará verzia nemusí rozumieť novým údajom. Deštruktívna migrácia môže odstrániť informácie, ktoré rollback kódu nedokáže obnoviť.

Pre každý krok určte spôsob obnovy. Ak je proces dopĺňania údajov navrhnutý na opätovné spustenie, môže byť bezpečné v ňom pokračovať. Nesprávna transformácia môže vyžadovať opravu zo zachovaných zdrojových údajov. Deštruktívna operácia môže vyžadovať overený postup obnovy.

Pýtajte sa, kto rozhoduje o obnove a ako dlho môže trvať. Tvrdenie „máme zálohy“ nepovažujte za dôkaz, že obnova spĺňa požiadavku služby.

Udržujte zmenu preskúmateľnú

Oddeľte nesúvisiace úpravy od funkčnej zmeny. V pull requeste uveďte plán kompatibility, výsledky overenia a podmienky odstránenia. Označte bod, po ktorom rollback vyžaduje ďalšiu prácu.

Agent môže pomôcť preskúmať komponenty využívajúce rozhranie a pripraviť migračný kód. Zodpovedná osoba musí aj tak prijať plán prechodu a obnovy. Konečný návrh je iba jednou časťou bezpečnej zmeny.