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

Найдите контракты, связанные с изменением

У существующего ПО есть вызывающие компоненты, сохранённые данные, задачи по расписанию и эксплуатационные процедуры. Некоторые зависимости не видны в файле, который вы хотите изменить. Агент может сделать локально правильное изменение, которое нарушит один из этих контрактов.

До реализации определите, кто читает и записывает затронутые данные. Изучите маршруты, фоновые задачи, отчёты и внешние интеграции. Проверьте, зависят ли от текущего поведения другие команды или старые версии клиентов.

Попросите агента подтвердить эту карту зависимостей. Результат поиска — полезная отправная точка. Но для динамических вызовов и внешних потребителей может потребоваться подтверждение зависимости от ответственного.

Сделайте текущее поведение наблюдаемым

Для плохо документированного модуля добавьте целевые проверки поведения, которое должно оставаться стабильным. Эти проверки описывают текущий контракт. Они не доказывают, что всё существующее поведение желательно.

Если текущее поведение противоречит требованию, зафиксируйте противоречие. Не сохраняйте дефект безопасности только потому, что его закрепил тест. Получите решение, которое отделяет предусмотренное поведение от дефекта.

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

Проверьте переход между версиями

Рассмотрим вымышленное переименование customer_name в display_name. Немедленное переименование может сломать старый экземпляр приложения во время развёртывания. Обновление обоих файлов в одном pull request не делает развёртывание атомарным.

Поэтапный переход помогает сохранить совместимость:

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

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

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

Планируйте восстановление отдельно от отката

Откат кода возвращает предыдущую версию приложения. Он не отменяет автоматически миграцию данных. Старая версия может не понимать новые данные. Миграция с удалением данных может уничтожить информацию, которую откат кода не восстановит.

Для каждого шага определите действие восстановления. Возобновляемое заполнение данных может быть безопасно продолжить. Неверное преобразование может потребовать исправления на основе сохранённых исходных данных. Для разрушительной операции может понадобиться проверенная процедура восстановления.

Выясните, кто отвечает за решение о восстановлении и сколько времени оно может занять. Не считайте фразу «у нас есть резервные копии» подтверждением того, что восстановление отвечает требованиям сервиса.

Сохраняйте обозримый объём изменения

Отделяйте постороннюю чистку кода от функционального изменения. В pull request включите план совместимости, результаты проверки и условия удаления. Отметьте момент, после которого для отката нужна дополнительная работа.

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