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

Как проверить миграцию базы данных перед запуском, если код писал ИИ? Начните с ответа на два вопроса: какие существующие строки изменятся и как приложение прочитает их после изменения схемы. Успешная команда миграции означает, что база приняла операции. Она ещё не гарантирует, что старые клиенты, суммы и связи сохранили смысл. Здесь я разбираю проверку структуры и данных. Правила чистки контактов при импорте есть в статье о базе клиентов, а выбор модели данных до разработки в техническом задании.

Как описать изменение до команды миграции

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

Отдельно проверьте очередь фоновых задач. В Python-проектах с Celery процесс обработки может продолжать работать, пока меняется веб‑приложение. Если новая схема несовместима со старой задачей, при выкладке возникнет окно ошибок. План должен назвать порядок обновления приложения, работника и базы. У проекта без очереди этот пункт можно пропустить после проверки архитектуры, а не по привычке.

Почему важна копия с настоящей историей

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

Вернитесь к старым карточкам из истории выше. Пустая база не покажет, сохранились ли связи со звонками и условия сметы. На копии с существующими строками проверьте и схему, и рабочий экран.

Создайте перечень контрольных запросов до миграции. Зафиксируйте число клиентов, число связей, количество пустых значений в важных полях и денежные итоги за согласованный период. После миграции повторите те же запросы. Если новая схема сознательно меняет подсчёт, заранее запишите ожидаемую разницу. Иначе любое расхождение можно ошибочно объяснить словом «особенность».

Как получить проверяемую копию PostgreSQL

Официальная документация PostgreSQL по pg_dump и pg_restore сверена 25 октября 2026 года: экспорт, восстановление. Команды ниже используют условные имена базы. Выполняйте их на разрешённой копии, под отдельной учётной записью, без пароля в строке команды. Архив должен храниться вне публичной папки сайта.

pg_dump -Fc -d example_db -f /private/backup/example-before.dump
chmod 600 /private/backup/example-before.dump
pg_restore --list /private/backup/example-before.dump | head
createdb example_migration_test
pg_restore --exit-on‑error --no‑owner --no‑acl -d example_migration_test /private/backup/example-before.dump
DATABASE_URL=адрес_тестовой_базы alembic upgrade head
DATABASE_URL=адрес_тестовой_базы alembic downgrade -1

Путь /private/backup и адрес тестовой базы условные: заранее создайте каталог с ограниченными правами и задайте подключение к отдельной копии. alembic upgrade head применяет новые миграции, alembic downgrade -1 проверяет один обратный шаг, если он предусмотрен. Перед каждой командой проверьте адрес подключения. Не применяйте --clean к рабочей базе ради эксперимента. Успех pg_restore проверьте контрольными запросами и запуском приложения против тестовой базы. Архив с клиентскими данными удаляют или хранят по принятому регламенту проекта.

Какие проверки провести после применения на копии

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

Пройдите действие человека от начала до конца. Для CRM это может быть старая заявка, новая запись и отчёт по источникам. Для бота проверьте чтение существующей задачи и сохранение новой. Если числа совпали, но интерфейс показывает чужой статус, техническая миграция завершилась, а продуктовая проверка провалилась. Запишите результат по каждому сценарию и устраните причину до запуска.

Где начинается план отката

До выкладки определите момент, после которого возвращение старого кода уже не прочитает изменённую базу. Иногда обратная миграция возможна, иногда новые данные после неё потеряются. Поэтому «откатить код» и «откатить базу» нужно описывать отдельно. Порядок проверки пригодности копии разбираю в статье о VPS. План отката запишите рядом с планом миграции, чтобы команда не искала его во время сбоя.

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

Перед решением о запуске отметьте каждый результат:

• Восстановите архив в отдельную базу.
• Сравните контрольные итоги до и после изменения.
• Откройте старую карточку со связанными данными.
• Создайте новую запись и проверьте фоновую задачу.
• Запишите, какой код прочитает базу при откате.

Частые вопросы

Достаточно ли команды «миграция прошла успешно»?

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

Можно ли проверять только на пустой базе?

Пустая база полезна для создания схемы и новых записей. Сохранность старых строк она не проверит.

Что делать с персональными данными в копии?

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

Когда требуется окно обслуживания?

Когда изменение несовместимо со старым кодом или блокирует записи. Определите это пробой на копии и порядком обновления сервисов.

Как доказать, что откат возможен?

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

На обучении я разбираю такие задачи через рабочий путь данных: от существующей строки до экрана после обновления. Сначала проба на копии, затем решение о запуске.