Безбедно мењајте постојећи систем

Утврдите уговоре интерфејса око промене

Постојећи софтвер има позиваоце, сачуване податке, заказане послове и оперативне поступке. Неке зависности нису видљиве у датотеци коју желите да измените. Агент може да направи локално исправну промену која нарушава неки од ових уговора.

Пре имплементације утврдите које компоненте читају и уписују погођене податке. Испитајте руте, позадинске послове, извештаје и спољне интеграције. Проверите да ли други тимови или старије верзије клијената зависе од тренутног понашања.

Затражите да агент покаже доказе за овај преглед зависности. Резултат претраге корисна је полазна тачка, али за динамичке позиве и спољне системе који користе податке може бити потребна потврда одговорне особе.

Учините тренутно понашање видљивим

Код слабо документованог модула додајте усмерене провере понашања које мора да остане стабилно. Оне описују тренутни уговор. Не доказују да је свако постојеће понашање пожељно.

Ако је тренутно понашање супротно захтеву, забележите сукоб. Не чувајте безбедносну грешку само зато што ју је тест забележио. Прибавите одлуку потребну да се намеравано понашање разликује од грешке.

Користите реалистичне тестне податке без осетљивих информација. Укључите старе структуре података и непотпуне записе тамо где могу да се појаве. Нова шема тестирана само на новим подацима може да сакрије проблеме миграције.

Прегледајте прелаз између верзија

Размотримо измишљено преименовање customer_name у display_name. Непосредно преименовање може да поквари стару инстанцу апликације током постављања нове верзије. Измена обе датотеке у једном pull request захтеву не чини постављање атомичним.

Поступан приступ може да сачува компатибилност:

1. Додајте ново поље без уклањања старог.
2. Дефинишите како нови уписи одржавају потребне вредности усклађеним.
3. Допуните постојеће записе поступком који може да се поново покрене после прекида.
4. Проверите потпуност и понашање компоненти које читају податке.
5. Пребаците те компоненте на ново поље.
6. Уклоните старо поље тек када га више ниједна компонента не користи.

Тачан метод зависи од базе и образаца уписа. Двоструки упис може да створи неусклађеност ако један упис не успе. Можда је потребна трансакција базе података или други изричити метод синхронизације. Не примењујте овај пример без провере гаранција система.

Martin Fowler овакав прелаз описује као parallel change, познат и као expand-and-contract. Главна идеја је компатибилан прелаз пре уклањања.

Планирајте опоравак одвојено од враћања верзије

Враћање кода обнавља претходну верзију апликације. Не поништава аутоматски миграцију података. Стара верзија можда не разуме нове податке. Деструктивна миграција може да уклони информације које враћање кода не може да обнови.

Утврдите радњу опоравка за сваки корак. Допуну података која подржава поновно покретање можда је безбедно наставити. Погрешна трансформација може да захтева исправку из сачуваних изворних података. Деструктивна операција може да захтева проверен поступак враћања података.

Питајте ко је одговоран за одлуку о опоравку и колико он може да траје. Не третирајте „имамо резервне копије” као доказ да опоравак испуњава захтев сервиса.

Омогућите поуздан преглед промене

Раздвојите неповезано сређивање кода од функционалне промене. У pull request захтеву наведите план компатибилности, резултате провере и услове уклањања. Означите тачку после које враћање претходне верзије захтева додатни рад.

Агент може да помогне да испитате системе који користе податке и припремите код миграције. Одговорна особа и даље мора да прихвати план прелаза и опоравка. Коначни дизајн је само један део безбедне промене.