Как согласовать миграцию данных с релизом сайта

Статический сайт можно вернуть на предыдущий каталог за секунды. Сайт с базой данных сложнее: новый релиз способен изменить таблицы и записи так, что старый код перестанет их понимать. Поэтому миграция данных — часть релиза со своим порядком, проверкой и способом восстановления, а не служебная команда между git pull и перезапуском.

Разделите изменение на совместимые шаги

Предположим, приложению нужно заменить поле full_name двумя полями first_name и last_name. Немедленное удаление старого поля делает возврат прежнего кода невозможным. Переход лучше разделить:

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

Эту схему называют expand-and-contract: сначала структура расширяется, затем устаревшая часть удаляется. Название менее важно, чем совместимый промежуток, в котором старая и новая версии могут работать с одной базой.

Выпишите условия до начала работ

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

• сколько минут сайт может быть недоступен;
• сколько последних данных допустимо потерять при восстановлении копии;
• кто принимает решение об остановке и откате;
• совместим ли старый код с новой схемой;
• можно ли прервать и продолжить задачу преобразования;
• где находится проверенная резервная копия.

В эксплуатации эти два ограничения часто называют RTO и RPO. RTO — допустимое время восстановления работы. RPO — допустимый интервал потери новых данных. Если значения неизвестны, нельзя осмысленно выбрать между быстрым исправляющим релизом и восстановлением базы.

Подготовьте миграцию как часть исходников

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

Не составляйте миграцию вручную в production-консоли без сохранённого файла. Такой шаг трудно повторить на тестовой базе и невозможно проверить обычным review.

Сначала примените миграцию к копии реальных по структуре и объёму данных. Измерьте время, проверьте блокировки, размер дополнительного индекса и свободное место. Маленькая пустая база не показывает поведение таблицы с миллионами строк.

Создайте и восстановите копию до релиза

Штатный инструмент СУБД должен создать согласованную копию. Контрольная сумма обнаруживает повреждение при передаче, а тестовое восстановление подтверждает, что формат читается и содержит нужные объекты. Копия хранится вне VPS или хотя бы вне рабочего диска до завершения проверки релиза.

Запишите момент начала копии. Если после него сайт продолжает принимать изменения, восстановление вернёт состояние именно к этому времени и потеряет более новые записи. Это допустимо только в пределах заранее принятого RPO.

Выполняйте релиз в известном порядке

Общий порядок выглядит так:

1. Проверить коммит, сборку и свободные ресурсы.
2. Создать и проверить копию базы.
3. Подготовить новый код или образ без переключения пользователей.
4. Выполнить совместимую миграцию одним процессом.
5. Проверить версию схемы и ключевые запросы.
6. Переключить приложение.
7. Выполнить публичный smoke-тест и прикладную проверку данных.
8. Наблюдать ошибки и длительность запросов.

Конкретная команда миграции зависит от приложения. Используйте штатный интерфейс проекта и указывайте в инструкции точную версию: например, команду Django нельзя заменять похожей командой Prisma. До запуска прочитайте режимы просмотра плана и проверки статуса, если они доступны.

Проверяйте данные, а не только HTTP-код

После миграции подтвердите:

• служебная таблица содержит ожидаемую версию;
• приложение читает старую запись;
• новая запись сохраняется и читается повторно;
• обязательные ограничения и индексы существуют;
• фоновые задачи используют тот же формат;
• журнал не содержит ошибок преобразования;
• задержка ключевых запросов не выросла неприемлемо.

Тестовая запись должна иметь понятный признак и процедуру удаления. На рабочем сайте не создавайте фиктивный заказ или письмо клиенту ради smoke-теста.

Отличайте возврат кода от восстановления данных

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

Возможны три разных действия:

• вернуть предыдущий код, сохранив совместимую новую схему;
• выпустить небольшое исправление вперёд;
• восстановить базу из копии и принять потерю записей после момента копирования.

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

Не удаляйте старую схему сразу после успеха

Отложите разрушительную часть до отдельного релиза. За период наблюдения проверьте, что все экземпляры приложения, фоновые workers, отчёты и административные инструменты перешли на новый формат. Только затем удаляйте устаревшее поле или таблицу и создавайте новую точку восстановления.

Что записать в журнал релиза

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

Для контейнерного варианта используйте порядок обновления Compose. Резервное копирование volumes и базы разобрано в отдельной инструкции, а переключение кода — в материале об атомарной публикации.

Источники

• PostgreSQL: transactional DDL
• PostgreSQL: pg_dump
• Django migrations
• Prisma: expand and contract pattern