Бяспечна змяняйце наяўную сістэму

Вызначце кантракты вакол змены

Наяўная праграма мае код і сістэмы, якія яе выклікаюць, захаваныя даныя, запланаваныя задачы і эксплуатацыйныя працэдуры. Некаторыя залежнасці не бачныя ў файле, які вы хочаце рэдагаваць. Агент можа стварыць лакальна правільную змену, якая парушае адзін з гэтых кантрактаў.

Перад рэалізацыяй вызначце, хто чытае і хто запісвае закранутыя даныя. Вывучыце маршруты, фонавыя задачы, справаздачы і знешнія інтэграцыі. Праверце, ці залежаць іншыя каманды або старыя версіі кліентаў ад бягучых паводзін.

Папрасіце агента паказаць доказы для гэтай схемы залежнасцей. Вынік пошуку — карысны пачатак. Але для дынамічных выклікаў і знешніх спажыўцоў можа спатрэбіцца пацверджанне залежнасці адказным.

Зрабіце бягучыя паводзіны назіральнымі

Для слаба задакументаванага модуля дадайце мэтанакіраваныя праверкі паводзін, якія павінны застацца нязменнымі. Гэтыя праверкі апісваюць бягучы кантракт. Яны не пацвярджаюць, што ўсе наяўныя паводзіны пажаданыя.

Калі бягучыя паводзіны супярэчаць патрабаванню, зафіксуйце супярэчнасць. Не захоўвайце дэфект бяспекі толькі таму, што яго зафіксаваў тэст. Атрымайце рашэнне, патрэбнае для адрознення задуманых паводзін ад дэфекту.

Выкарыстоўвайце рэалістычныя тэставыя даныя без канфідэнцыяльнай інфармацыі. Уключайце старыя структуры даных і няпоўныя запісы там, дзе яны могуць сустракацца. Новая схема даных, правераная толькі на нядаўна створаных даных, можа схаваць праблемы міграцыі.

Правярайце пераход паміж версіямі

Разгледзім выдуманае перайменаванне customer_name у display_name. Імгненнае перайменаванне можа парушыць працу старога асобніка праграмы падчас разгортвання. Абнаўленне абодвух файлаў у адным pull request не робіць разгортванне атамарным.

Паэтапны падыход можа захаваць сумяшчальнасць:

1. Дадайце новае поле, не выдаляючы старое.
2. Вызначце, як новыя аперацыі запісу захоўваюць узгодненасць неабходных значэнняў.
3. Запоўніце новае поле ў наяўных запісах працэсам, які можна перазапусціць.
4. Праверце паўнату і паводзіны кампанентаў, якія чытаюць даныя.
5. Перавядзіце гэтыя кампаненты на новае поле.
6. Выдаляйце старое поле толькі пасля таго, як яго спажыўцы перастануць ад яго залежаць.

Дакладны метад залежыць ад базы даных і спосабаў запісу. Двайны запіс можа стварыць неўзгодненасць, калі адна аперацыя запісу не атрымаецца. Можа спатрэбіцца транзакцыя базы даных або іншы яўны метад сінхранізацыі. Не ўжывайце гэты прыклад без праверкі гарантый сістэмы.

Марцін Фаўлер апісвае такі агульны пераход як parallel change, таксама вядомы як expand-and-contract. Асноўная ідэя — сумяшчальны пераход перад выдаленнем.

Плануйце аднаўленне асобна ад адкату

Адкат кода вяртае ранейшую версію праграмы. Ён не адмяняе аўтаматычна міграцыю даных. Старая версія можа не разумець новыя даныя. Разбуральная міграцыя можа выдаліць інфармацыю, якую адкат кода не адновіць.

Вызначце дзеянне для аднаўлення на кожным кроку. Можа быць бяспечна працягнуць запаўненне наяўных запісаў, калі адпаведны працэс падтрымлівае перазапуск. Няправільнае пераўтварэнне можа патрабаваць выпраўлення з захаваных зыходных даных. Разбуральная аперацыя можа патрабаваць праверанай працэдуры аднаўлення.

Спытайце, хто адказвае за рашэнне аб аднаўленні і колькі часу яно можа заняць. Не лічыце «ў нас ёсць рэзервовыя копіі» доказам таго, што аднаўленне адпавядае патрабаванню сэрвісу.

Захоўвайце змену прыдатнай для праверкі

Аддзяляйце не звязанае з задачай упарадкаванне ад функцыянальнай змены. Дадайце ў pull request план сумяшчальнасці, вынікі праверкі і ўмовы выдалення. Пазначце момант, пасля якога адкат патрабуе дадатковай працы.

Агент можа дапамагчы вывучыць спажыўцоў і падрыхтаваць код міграцыі. Адказны ўсё роўна павінен прыняць план пераходу і аднаўлення. Канчатковая канструкцыя — толькі адна частка бяспечнай змены.