PHP и Laravel
Laravel возвращает 500 после деплоя
После публикации новой версии Laravel возвращает 500. Объясняем, какие части развёртывания нужно сверить и как отличить ошибку кода от окружения.
Что происходит и с чего начать
Публикация приложения включает не только загрузку файлов. Важны установленные зависимости, настройки, структура базы, права записи и процессы очередей. Если эти части обновились несогласованно, новая версия может не запуститься или ломаться лишь в отдельных действиях. Поэтому сначала сохраните ошибку и отметьте, что именно изменилось. Главная страница иногда работает из готового кеша, пока реальный запрос уже падает. Проверять нужно конкретный сценарий и журнал приложения за время его выполнения.
Что можно проверить самостоятельно
- Запишите время публикации, версию кода и первое неработающее действие. Уточните, проходит ли чтение страниц и возникают ли ошибки только при сохранении или фоновой обработке.
- Сохраните безопасную часть записи из журнала без паролей, токенов и персональных данных. Не включайте публичный режим подробной отладки для посетителей рабочего сайта.
- Проверьте наличие плана отката и свежих данных после публикации. Возврат кода и возврат базы — разные действия, их совместимость нужно оценить до восстановления.
Как понять результаты проверки
Специалист сверяет зависимости с зафиксированными версиями, настройки окружения и применённые изменения базы. Миграция — контролируемое изменение её структуры, а не обязательное удаление данных. Очистка кеша может быть частью восстановления, но не заменяет отсутствующую таблицу или нужное расширение PHP. Если предлагается откат, важно показать, совместим ли старый код с текущей базой. В отчёте полезно фиксировать конкретный пропущенный шаг и способ сделать следующую публикацию воспроизводимой.
Что проверяет разработчик
Для этой части понадобятся доступ к настройкам, журналам ошибок или коду. Её можно передать специалисту вместе с результатами предыдущих шагов.
- Проверьте настроенный канал журналирования: ошибка может записываться в файл, stderr или централизованный сборщик. Не предполагайте единственный путь для всех проектов.
- Сверьте окружение релиза, доступность базы и состояние миграций. Убедитесь, что веб-сервер направлен в public нужной версии приложения.
- Проверьте запись в storage и bootstrap/cache, наличие зависимостей и согласованность кешей. Не выдавайте всем каталогам права 777.
На что обратить внимание
После переключения релиза приложение может использовать старую конфигурацию или недоступный каталог хранения. Ошибка миграции также способна проявиться только на маршруте, который обращается к новому полю.
Как исправляют причину
Исправьте подтверждённую причину и примените процедуру деплоя с проверкой готовности. Откат кода выполняйте с учётом совместимости схемы базы. APP_DEBUG на публичном сайте не должен раскрывать окружение.
Как убедиться, что проблема решена
Проверьте ключевые маршруты, запись данных и фоновые задачи. Убедитесь, что веб и воркеры используют согласованный релиз и новые ошибки не продолжают появляться.
После исправления проверьте чтение, запись, вход, очередь и расписание в рамках функций проекта. Сверьте журналы контрольного запроса и убедитесь, что фоновые процессы используют нужную версию. Если ошибка затронула незавершённые операции, их состояние проверяют отдельно. Приёмка развёртывания должна подтверждать рабочие сценарии, а не только успешный ответ главной и отсутствие ошибки у одного разработчика.