Променяйте безопасно съществуваща система

Определете договорите между компонентите около промяната

Съществуващият софтуер има извикващи компоненти, съхранени данни, планирани задачи и процедури за експлоатация. Някои зависимости не се виждат във файла, който искате да редактирате. Агент може да създаде локално правилна промяна, която нарушава един от тези договори.

Преди реализацията определете компонентите, които четат и записват засегнатите данни. Прегледайте маршрутите, фоновите задачи, отчетите и външните интеграции. Проверете дали други екипи или стари версии на клиентски софтуер зависят от текущото поведение.

Поискайте агентът да покаже доказателствата за тази карта. Резултат от търсене е полезна отправна точка, но динамичните извиквания и външните софтуерни потребители могат да изискват потвърждение от отговорник.

Направете текущото поведение наблюдаемо

За слабо документиран модул добавете целеви проверки на поведение, което трябва да остане стабилно. Тези проверки описват текущия договор. Те не установяват, че всяко съществуващо поведение е желано.

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

Използвайте реалистични тестови данни без чувствителна информация. Включете стари форми на данните и непълни записи, когато са възможни. Нова схема, тествана само с новосъздадени данни, може да скрие проблеми при миграция.

Прегледайте прехода между версиите

Разгледайте измислено преименуване от customer_name на display_name. Незабавно преименуване може да наруши работата на стара инстанция на приложението по време на внедряване. Обновяването на двата файла в един pull request не прави внедряването атомарно.

Поетапен подход може да запази съвместимостта:

1. Добавете новото поле, без да премахвате старото.
2. Определете как новите операции за запис ще поддържат необходимите стойности съгласувани.
3. Попълнете новото поле в съществуващите записи чрез процес, който може да продължи след прекъсване.
4. Проверете пълнотата и поведението на четящите компоненти.
5. Прехвърлете четящите компоненти към новото поле.
6. Премахнете старото поле едва когато вече няма компоненти, които го използват.

Точният метод зависи от базата данни и начина на запис. Двойният запис може да създаде несъгласуваност, ако единият запис се провали. Може да е нужна транзакция в базата данни или друг изричен метод за синхронизация. Не прилагайте примера, без да проверите гаранциите на системата.

Martin Fowler описва този общ преход като parallel change, наричан още expand-and-contract. Основната идея е съвместим преход преди премахване.

Планирайте възстановяването отделно от rollback

Rollback на кода възстановява по-ранна версия на приложението. Той не отменя автоматично миграция на данни. Старата версия може да не разбира новите данни. Разрушителна миграция може да премахне информация, която rollback на кода не може да възстанови.

Определете действието за възстановяване за всяка стъпка. Попълване на съществуващи записи, проектирано за продължаване след прекъсване, може да се възобнови безопасно. Погрешно преобразуване може да изисква поправка от запазени изходни данни. Разрушителна операция може да изисква проверена процедура за възстановяване.

Попитайте кой отговаря за решението за възстановяване и колко време може да отнеме. Не приемайте „имаме резервни копия“ като доказателство, че възстановяването изпълнява изискването на услугата.

Пазете промяната удобна за преглед

Отделете несвързаното почистване на кода от функционалната промяна. Предоставете плана за съвместимост, резултатите от проверките и условията за премахване в pull request-а. Отбележете момента, след който rollback изисква допълнителна работа.

Агент може да помогне да се прегледат компонентите, които използват данните, и да се подготви кодът за миграция. Отговорният собственик на системата все още трябва да приеме плана за преход и възстановяване. Крайният проект е само една част от безопасната промяна.