Обновление PHP и движка можно отдать агентам: с тестами и проверенным откатом

Как обновить PHP сайта и не потерять заказы? Сначала выяснить, что вместе с ним должно работать. PHP исполняет код на сервере; движок сайта и его дополнения требуют совместимых версий.

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

PHP меняет и правила работы кода. При переходе на PHP 8.0 вызов нестатического метода как статического перестал поддерживаться: это указано в руководстве PHP. Такой вызов приходится исправлять по смыслу.

Общее лечение старого кода разобрано в статье о техническом долге. Здесь задача уже: сохранить работу сайта при смене версий и подготовить проверяемый возврат.

Можно оставить старую версию, раз всё работает? После окончания поддержки команда PHP перестаёт выпускать для неё исправления. Работающая форма не продлевает этот срок.

Минимальная версия тоже требует следующего обновления. На 7 октября 2026 «1С-Битрикс: Управление сайтом» указывает минимум PHP 8.2, а поддержка безопасности этой ветки PHP заканчивается 31 декабря 2026.

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

В инструкции для коробочного Битрикс24 вендор просит до смены PHP обновить ядро, модули и сторонние решения. Для сайта порядок уточняют по его установленным версиям: слепо нажать «обновить всё» на работающем сайте не заменяет обследование.

Что делать, если тестов нет? Первым результатом заказа должны стать проверки работающего сайта. Агент фиксирует, что происходит сейчас; владелец подтверждает, какое поведение нужно сохранить.

Проверять стоит путь денег и заявки. Для магазина проверяют заказ и его статус, для услуг проверяют форму и запись в CRM. Если тест видит только страницу, пропавшее письмо останется за его пределами.

На живой /open 7 октября указан гейт из 2 685 тестов на каждом пуше плюс ревью. Это число проверок нашей машины; оно не означает, что ими покрыт любой пользовательский сценарий.

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

Что меняют агенты в этой работе? Можно поручить им поиск устаревших вызовов, подготовку тестов и повторяющиеся правки. Инженер проверяет смысл изменения и выбирает порядок перехода.

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

Задачу агенту записывают через результат: сохранить сценарии на целевой версии, показать отличия, подготовить возврат. Шаблон такой постановки задачи уже разобран отдельно; «обновить всё до последнего» критериев не содержит.

У проекта с Composer есть отдельная проверка check-platform-reqs: она сверяет требования пакетов с настоящим PHP и расширениями. Сборка без ошибок полезна, но результат заказа всё равно подтверждают сценарии сайта.

Что означает «есть откат»? Исполнитель должен показать, как вернёт совместимые код, окружение и данные. Архив, который никто не восстанавливал, этого не доказывает.

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

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

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

Что ещё остаётся, когда копия прошла тесты? Проверка на рабочем адресе и наблюдение за фоновой работой. Копия могла отличаться настройкой почты или версией PHP для команд по расписанию.

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

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

Исправленный сбой закрывают проверкой, которая ловит его повторение. Правила для агентов становятся исполнимыми, когда ошибка останавливает выпуск. Переписка «больше так не делать» следующий переход не защищает.

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

Нет человека, который умеет принять такой план? Тест для руководителя поможет оценить процесс разработки. Совместимость вашего PHP и модулей всё равно проверяют в отдельном обследовании.

Если задачи по сайту идут постоянно, обновление версий можно поставить в очередь подписки на разработку. На 7 октября тариф «Один проект» стоит 250 000 ₽ в месяц: один продукт, один поток, одна задача в работе.

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

1. Выбирайте совместимую связку PHP, движка и дополнений со сроком поддержки.

2. До правки закрепите сценарии, по которым сайт приносит заказы и заявки.

3. Агент работает на копии, инженер принимает изменения и разрешает выпуск.

4. Репетируйте возврат вместе с сохранением новых записей. После выпуска повторите проверки и дождитесь фоновых задач.