Менувајте постоен систем безбедно

Утврдете ги договорените правила околу промената

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

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

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

Направете го тековното однесување видливо

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

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

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

Прегледајте го преминот меѓу верзиите

Разгледајте измислено преименување од customer_name во display_name. Непосредно преименување може да расипе стара инстанца на апликацијата за време на распоредувањето. Ажурирање на двете датотеки во едно барање за спојување код не го прави распоредувањето атомско.

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

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

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

Martin Fowler го опишува овој општ премин како паралелна промена, наречена и expand-and-contract. Клучната идеја е компатибилен премин пред отстранувањето.

Планирајте го обновувањето одделно од враќањето на кодот

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

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

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

Задржете ја промената погодна за преглед

Одделете го неповрзаното чистење на кодот од функционалната промена. Во барањето за спојување код приложете ги планот за компатибилност, резултатите од проверките и условите за отстранување. Означете ја точката по која враќањето на претходната верзија бара дополнителна работа.

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