Обновление Laravel-проекта стоит начинать с ответа на три вопроса: что именно меняется, как будет проверена работа бизнеса и что произойдёт с данными при неудачном выпуске. Новый номер версии сам по себе не отвечает ни на один из них.
Для владельца сайта результат подготовки — согласованный план перехода: целевые версии, найденные ограничения, проверки, порядок переключения и условия возврата. Он позволяет оценить объём работ до вмешательства в действующий сайт и понять, какие риски остаются.
Laravel, PHP и зависимости обновляются по разным правилам
Laravel — фреймворк, на котором написано приложение. PHP — среда, выполняющая его код. Зависимости — подключённые библиотеки: например, для работы с файлами, почтой или внешними системами. Эти части связаны требованиями совместимости, но замена одной не означает обновления остальных.
| Что меняется | Что нужно выяснить до перехода |
|---|---|
| Версия Laravel | Какие изменения официального руководства по обновлению затрагивают код и конфигурацию проекта |
| Версия PHP | Поддерживают ли её Laravel, все необходимые пакеты и расширения; одинаково ли настроены веб-сервер и фоновые процессы |
| Версии библиотек | Какие пакеты меняются вместе с ними, сохранены ли используемые возможности и совместимость интеграций |
Обновление внутри текущей ветки и переход на следующую основную версию могут иметь разный объём. Для старого проекта нужно разобрать руководства по всем затронутым переходам. Проверять промежуточные состояния можно на тестовом контуре; выпускать каждое из них на действующий сайт автоматически не требуется.
Полезно отделить техническое обновление от новых функций и редизайна. Если в том же выпуске меняются оформление заказа, интеграция и серверное окружение, причину сбоя будет сложнее установить. Когда требуется новая бизнес-логика, её объём стоит описать отдельно как задачу разработки сайта на Laravel, даже если работы выполняет одна команда.
Сначала зафиксировать то, что действительно работает
Инвентаризация должна описывать установленный проект, а не только пожелания в документации. В composer.json записаны требования к пакетам; в composer.lock — точные версии, выбранные для сборки. При наличии lock-файла Composer устанавливает зафиксированный набор зависимостей. Обновление разрешает зависимости заново и меняет этот набор. Поэтому случайное обновление пакетов непосредственно на рабочем сервере не заменяет подготовленный выпуск.
До оценки перехода попросите исполнителя собрать:
- Версию развёрнутого кода, Laravel, Composer и PHP. Отдельно — PHP, которым обслуживаются веб-запросы, запускаются очереди и выполняются задания по расписанию.
composer.json,composer.lock, необходимые расширения PHP, версии базы данных и других реально используемых сервисов. Для клиентской сборки — её зависимости и способ получения готовых файлов.- Перечень важных пакетов и собственных изменений: авторизация, платежи, административная часть, обмен данными. Отметить неподдерживаемые библиотеки и результаты проверки известных уязвимостей.
- Список очередей, заданий по расписанию, входящих уведомлений от внешних систем и исходящих запросов. У каждого процесса должны быть понятны назначение и ответственный.
- Существующие тесты, известные ошибки, способ выпуска, резервные копии базы и файлов, результат пробного восстановления.
Если lock-файла нет или установленный набор с ним расходится, это отдельная неопределённость. Сначала нужно восстановить воспроизводимую исходную сборку и проверить её. Создать новый lock-файл и считать его описанием прежнего сайта нельзя.
Настройка Composer config.platform может задавать условную версию PHP для выбора пакетов. Она не меняет PHP на сервере. Проверка реальных требований платформы и проверка веб-окружения всё равно нужны: результат проверки в консоли не доказывает, что сайт работает на том же PHP с теми же расширениями. Игнорирование требований совместимости не устраняет несовместимость.
Выход этого этапа — список препятствий с решениями: обновить пакет, заменить его, адаптировать собственный код, изменить окружение или пересмотреть маршрут перехода. Без такого списка точная оценка работ преждевременна.
Выбрать целевую версию с учётом срока поддержки
Поддержка версии Laravel бывает двух видов: исправления ошибок и исправления безопасности. Окончание первого периода не означает немедленного прекращения второго. При этом работающий сайт на неподдерживаемой версии не становится безопасным только потому, что его страницы открываются.
На 3 октября 2026 года официальная таблица Laravel содержит следующие сведения:
| Ветка Laravel | Поддерживаемые ветки PHP | Исправления ошибок | Исправления безопасности |
|---|---|---|---|
| 12 | 8.2–8.5 | До 13 августа 2026 года | До 24 февраля 2027 года |
| 13 | 8.3–8.5 | До III квартала 2027 года | До 17 марта 2028 года |
Таким образом, Laravel 12 на дату проверки находится в периоде исправлений безопасности. Для Laravel 13 требуется PHP не ниже 8.3. Laravel 11 завершил период исправлений безопасности 12 марта 2026 года. Это ориентиры для планирования, а не рекомендация установить одну версию на любой проект.
У PHP свой календарь. На ту же дату ветки 8.2 и 8.3 получают только критические исправления безопасности, а 8.4 и 8.5 находятся в активной поддержке. Поддержка безопасности PHP 8.2 заканчивается 31 декабря 2026 года. Поэтому соответствия минимальному требованию Laravel недостаточно: нужно учитывать и срок жизни самого окружения.
Выбирать следует совместимую комбинацию, которую удастся проверить и сопровождать после перехода. Если важный пакет блокирует целевую версию, в плане должны появиться замена или адаптация пакета и их проверка. Промежуточная версия может быть частью маршрута, но её выбор требует отдельного объяснения и следующего шага до окончания поддержки. Перед выпуском сроки и требования нужно сверить заново.
Тестовый контур должен проверять последствия для бизнеса
Сначала запустите проверки на исходной версии и зафиксируйте результат. Иначе давняя ошибка может оказаться приписана обновлению. Затем повторите те же сценарии на новой сборке и добавьте проверки изменившегося поведения.
Нужен отдельный контур с сопоставимыми версиями PHP, расширений, базы данных и сервисов. Если миграция будет работать на большой таблице, несколько учебных записей не покажут её длительность и возможные блокировки. Для такой проверки нужна подготовленная копия подходящего объёма с защищёнными или обезличенными данными.
Контур изолируют от реальных отправок: отдельные учётные данные и очереди, тестовые режимы интеграций, контролируемая почта. Копия сайта не должна случайно отправлять клиентам сообщения или менять заказы в рабочей системе. Секреты и персональные данные не включают в открытые отчёты проверки.
Состав сценариев зависит от сайта. Например, для проекта с заказами можно согласовать такую приёмку:
| Сценарий | Что подтвердить |
|---|---|
| Вход и личный кабинет | Пользователь входит, видит свои данные, не получает чужие права; согласовано поведение существующих сессий |
| Заявка или заказ | Данные сохраняются, пользователь получает ожидаемый результат, обращение доходит до места обработки |
| Оплата, если она подключена | Тестовое подтверждение меняет нужный статус; повторное уведомление не создаёт повторную операцию |
| Административные действия | Сотрудник может обработать обращение, изменить контент и загрузить файл с прежними ограничениями доступа |
| Очереди и расписание | Проверяемая задача выполняется до конечного результата, а не только попадает в очередь |
Автоматические тесты нужны для повторяемой проверки, браузер — для пользовательского поведения, отдельный прогон — для реального обмена с тестовой внешней системой. Подмена интеграции в тесте проверяет реакцию приложения на заданный ответ, но не подтверждает фактическое подключение.
В Laravel настройки автоматических тестов могут отличаться от рабочего окружения, включая драйверы сессий и кеша. Поэтому успешного набора тестов недостаточно без проверки конфигурации выпуска и используемых сервисов. Для каждого критичного сценария сохраните результат и обозначьте проверявшего его человека.
Откат кода и возврат данных — разные задачи
Обновление Laravel не обязательно меняет структуру базы. Однако пакет или собственный код могут потребовать миграций: добавления полей, изменения индексов, преобразования значений. Проверять их нужно по фактическому составу выпуска.
У миграции Laravel есть прямое действие up и обратное действие down. Наличие обратного метода ещё не доказывает восстановление данных. Если поле удалили, последующее создание пустого поля не вернёт прежние значения. Укрупнение или преобразование данных также может потерять информацию, необходимую старому коду.
Учебный пример. В заказе меняется способ хранения статуса. Если сразу удалить прежнее поле и записать только новый формат, старая версия сайта может перестать читать новые заказы. Возможный план — сначала добавить новое поле, перенести и проверить значения, предусмотреть согласованную совместимость чтения и записи, а удаление старого поля вынести в отдельный выпуск после окончания периода возврата. Подходит ли такой порядок, определяет схема конкретного проекта.
Для каждой миграции нужно ответить: сколько данных она затрагивает, какие блокировки возможны, что произойдёт при частичном выполнении, допускается ли повторный запуск и смогут ли прежние код и фоновые задачи работать с получившейся базой. Длительность и возврат проверяют на подготовленном контуре до переключения.
В плане должны быть раздельно описаны возврат предыдущей сборки и восстановление данных. Для последнего нужны проверенная копия, процедура восстановления и согласованный способ работы с изменениями после момента копирования. Допустимый простой и возможная потеря данных — решение владельца бизнеса, а не скрытое допущение исполнителя.
Переключение: кто принимает решение и что проверяется сразу
К выпуску готовят именно проверенный набор кода, зависимостей и клиентских файлов. Повторный подбор версий пакетов при переключении создаёт новую сборку, для которой прежние результаты тестов могут оказаться неприменимы.
Порядок действий согласуют для конкретной инфраструктуры. В нём должны присутствовать:
- Условия начала. Пройдены критичные сценарии, доступна проверенная процедура восстановления, назначены ответственные за выпуск и решение об откате. Выбрано допустимое окно работ.
- Работа с текущими операциями. Определено, принимаются ли новые обращения, как завершаются выполняемые задачи и обрабатываются входящие уведомления. Ограничение доступа к сайту само по себе не останавливает все внешние процессы.
- Переключение и миграции. Зафиксированы последовательность изменений окружения, базы и сборки, промежуточные проверки и действия при сбое каждого шага.
- Фоновые процессы. Предусмотрен корректный перезапуск долгоживущих процессов. Проверена совместимость уже ожидающих задач с новым кодом; старые и новые обработчики не должны случайно выполнять несовместимые операции одновременно.
- Проверка результата. Пройдены короткие критичные сценарии, подтверждены сохранение данных, обработка очередей и обмен с внешними системами. Назначено наблюдение после переключения.
Обработчики очередей Laravel могут продолжать работать с кодом, загруженным до выпуска. Поэтому открывающаяся страница ещё не подтверждает завершённое обновление. Нужно проверить, что новые процессы действительно запущены, задачи выполняются, ошибки не накапливаются и очередь не растёт без обработки.
Также проверяют повторные попытки: сбой или задержка внешней системы не должны приводить к неконтролируемому повторению важных действий. Нельзя автоматически перезапускать все неудачные задачи, не выяснив, какие последствия уже наступили.
Условия отката задают заранее: например, подтверждённая потеря заказов, нарушение доступа или остановка критичной интеграции. Отдельно указывают, до какого момента достаточно вернуть код, а после какого требуется решение по новым данным. Для контроля после выпуска полезно заранее определить, что проверять кроме доступности главной страницы.
Что должно остаться у владельца после обновления
Приёмка заканчивается подтверждением нужных бизнес-сценариев и передачей сведений для дальнейшего сопровождения. В отчёте должны быть исходные и итоговые версии, изменённые пакеты, результаты проверок, выполненные миграции, состояние резервного восстановления и оставшиеся ограничения. Отдельно — срок поддержки выбранной комбинации и следующая точка пересмотра.
Если автоматических проверок раньше не было, в объём работ стоит включить защиту критичных сценариев. Если препятствием оказался заброшенный пакет, важно зафиксировать решение по нему. Ни скрытая несовместимость, ни обещание «проверить позже» не должны исчезать из согласованного результата.
Чтобы подготовить задачу по поддержке сайта на Laravel, передайте сведения о текущих версиях, важных процессах, интеграциях и допустимом простое. Доступы согласуют отдельно по защищённому каналу. Содержательное предложение на обновление должно объяснять маршрут и способ проверки именно вашего проекта; срок и стоимость определяются после изучения его состояния.
