Что нужно спланировать для перехода с одной версии PHP на другую?

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

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

1. Разведка боем и инвентаризация: что мы вообще ломать собрались? Первым делом — не лезть сломя голову. Нужно понять, насколько наш код — старый пердун, который сдохнет при первом же взгляде на строгую типизацию. Беру PHPCompatibility и запускаю его по всему коду. Эта штука покажет все mysql_* функции, которые уже лет десять как в аду, или create_function, от которой у меня лично волосы дыбом встают. Главное — не охуеть от количества предупреждений, если проект древний.

Потом смотрю на все эти сторонние пакеты через Composer. Команда composer why-not php:8.2 — это мой лучший друг на этом этапе. Она честно скажет, какой пидарас шерстяной тянет за собой старую версию и блокирует всё обновление. Часто оказывается, что какая-нибудь мартышлюшка-библиотека не обновлялась с 2015 года, и её надо выпиливать или искать замену.

Ну и не забываю посмотреть, какие расширения PHP у нас висят (php -m). А то будет смешно: переедем на 8.2, а там окажется, что любимое расширение для работы с MongoDB накрылось медным тазом и его просто нет.

2. Строим полигон для испытаний Теперь нужно место, где можно всё взорвать без последствий. Разворачиваю тестовое окружение на Docker. Вот пример Dockerfile, простой как три копейки:

FROM php:8.2-fpm
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
RUN docker-php-ext-install pdo_mysql

Поднимаю это дело и запускаю ВСЕ тесты. Все до единого. Особенно те, что касаются типов данных, сериализации и работы с датами — в восьмёрке с этим любят выебываться. Если тестов нет — это пиздец и отдельная история, но тогда хотя бы руками прогоняю основные сценарии.

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

3. Внедряем с умом и всегда держим руку на кнопке «Отмена» Когда код более-менее не падает, можно думать о проде. Но ни в коем случае не обновлять всё разом! Сначала staging, потом канареечное развертывание (canary) на production: пускаем 5-10% трафика на новую версию и смотрим, не полетели ли у нас логи ошибок в космос.

Самое главное — подготовить план отката. Чёткий, ясный и протестированный. У меня всегда наготове полные бекапы конфигов, данных и кода старой версии. Плюс скрипты, которые одним махом всё откатывают назад. Доверия к новым версиям PHP, особенно после крупного прыжка, — ебать ноль. Всегда нужно быть готовым сказать: «Всё, нахуй, откатываем».

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

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