Миграции, которые не сломают продакшн

Миграция идеально работает на вашей локальной машине. Вы деплоите её в пятницу в 18:00, потому что она кажется незначительной. Затем деплой зависает. Или, что еще хуже, таблица с 8 миллионами строк блокируется на 40 секунд, и ваш сайт падает.

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

Следуйте этим правилам, чтобы избежать катастроф на продакшене.

  • Всегда пишите рабочий метод down Каждой миграции нужны функции up и down. Функция down должна в точности отменять действие функции up. Если вы не можете написать откат, ваша миграция слишком сложна. Протестируйте её на своей машине с помощью migrate, а затем migrate:rollback, прежде чем отправлять код.

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

  • Используйте nullable или значения по умолчанию Добавление колонки NOT NULL в таблицу с существующими данными вызывает ошибки. База данных не знает, что записать в старые строки.

Вместо этого используйте следующие подходы: • Сделайте новую колонку nullable. • Установите значение по умолчанию. • Если колонка обязательно должна быть заполнена, сделайте это в три этапа: создайте её как nullable, заполните данными, а затем измените на NOT NULL.

  • Потеря данных необратима Команда dropColumn удаляет данные навсегда. Откат может воссоздать колонку, но данные внутри будут потеряны. Перед тем как удалять колонку, проверьте свои бэкапы. Более безопасный способ — сначала перестать использовать колонку в коде, подождать несколько недель, а затем удалить её из базы данных.

  • Отделяйте изменения схемы от обновления данных Выполнение User::all() внутри миграции может загрузить миллионы строк в память и обрушить ваш деплой. Если вам необходимо обновить данные во время миграции, используйте chunkById для обработки записей небольшими порциями.

  • Используйте флаг --force в пайплайнах Автоматизированные пайплайны деплоя зависнут, если Laravel запросит подтверждение. Используйте эту команду в ваших скриптах развертывания: php artisan migrate --force

  • Остерегайтесь блокировок таблиц Изменение колонки или добавление индекса в массивной таблице блокирует эту таблицу. Это приводит к простою. Для очень больших таблиц изучите инструменты онлайн-изменения схем или выполняйте изменения в часы минимальной нагрузки.

Чек-лист перед пушем: • Работает ли метод down? • Протестировал ли я откат локально? • Создаю ли я новую миграцию вместо редактирования старой? • Является ли новая колонка nullable или имеет ли она значение по умолчанию? • Есть ли у меня бэкап перед удалением колонок?

Source: https://dev.to/denisgusto1/migrations-que-nao-quebram-em-producao-o-guia-que-ninguem-te-deu-363o