Безпечно змінюйте наявну систему

Визначте контракти навколо зміни

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

До реалізації визначте компоненти, які читають і записують відповідні дані. Перевірте маршрути, фонові задачі, звіти та зовнішні інтеграції. З’ясуйте, чи залежать інші команди або старіші клієнтські версії від поточної поведінки.

Попросіть агента показати докази для цієї карти залежностей. Результат пошуку — корисна відправна точка, але динамічні виклики та зовнішні програмні споживачі можуть потребувати підтвердження залежності відповідальним.

Зробіть поточну поведінку спостережуваною

Для погано задокументованого модуля додайте цільові перевірки поведінки, яка має залишатися сталою. Вони описують чинний контракт. Вони не доводять, що вся наявна поведінка бажана.

Якщо поточна поведінка суперечить вимозі, зафіксуйте суперечність. Не зберігайте дефект безпеки лише тому, що тест його зафіксував. Отримайте рішення, потрібне для відокремлення запланованої поведінки від дефекту.

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

Перегляньте перехід між версіями

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

Поетапний підхід може зберегти сумісність:

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

Точний метод залежить від бази даних і схем запису. Подвійний запис може створити неузгодженість, якщо одна операція не вдасться. Може знадобитися транзакція бази даних або інший явний метод синхронізації. Не застосовуйте цей приклад без перевірки гарантій системи.

Martin Fowler описує цей загальний перехід як parallel change, також відомий як expand-and-contract. Основна ідея — сумісний перехід перед видаленням.

Плануйте відновлення окремо від відкату

Відкат коду відновлює попередню версію застосунку. Він не скасовує автоматично міграцію даних. Стара версія може не розуміти нових даних. Руйнівна міграція може видалити інформацію, якої відкат коду не відновить.

Визначте дію відновлення для кожного кроку. Продовження процесу заповнення старих записів із підтримкою перезапуску може бути безпечним. Неправильне перетворення може потребувати виправлення зі збережених вихідних даних. Руйнівна операція може потребувати перевіреної процедури відновлення.

Запитайте, хто відповідає за рішення про відновлення та скільки часу воно може зайняти. Не сприймайте «у нас є резервні копії» як доказ того, що відновлення відповідає вимогам сервісу.

Зберігайте зміну придатною для перегляду

Відокремлюйте не пов’язане із задачею очищення коду від функціональної зміни. Надайте в pull request план сумісності, результати перевірок і умови видалення. Позначте момент, після якого відкат потребує додаткової роботи.

Агент може допомогти дослідити компоненти-споживачі й підготувати код міграції. Відповідальна особа все одно має прийняти план переходу та відновлення. Остаточний дизайн — лише одна частина безпечної зміни.