Планирование обновления Bitrix: lifecycle-подход с первого дня

Планирование обновления Bitrix — это не то, о чём думают при запуске проекта. Думают об этом, когда в пятницу вечером приходит уведомление об окончании поддержки версии.

Мы однажды попали именно в эту ситуацию. Проект на Bitrix 18, PHP 7.2. Три года без мажорного обновления. Потом — уязвимость в ядре, клиент позвонил в пятницу в 18:30. Три с половиной дня работы, перетестирование каждого кастомного модуля, откат хостинга дважды. Итого: 28 человеко-часов на то, что можно было сделать за 6 плановых.

С тех пор мы изменили подход. Не «будем обновлять когда припрёт», а «закладываем lifecycle в проект до первого деплоя».

Почему апгрейды Bitrix становятся аварийными

Мажорное обновление Bitrix — это не замена одного пакета. Это миграция ядра, которая затрагивает:

API компонентов (старые D6-шаблоны, шорткоды, кастомные события)
PHP-версию (Bitrix 23+ требует PHP 8.1, а старый код написан под 7.4)
модули из маркетплейса (каждый обновляется своим вендором и со своим сдвигом)

В плановой ситуации вы знаете всё это заранее. Запускаете апгрейд в тестовой среде, исправляете совместимость, накатываете на прод за одно окно обслуживания.

В аварийной — нет тестовой среды под нужную версию PHP, нет списка кастомных зависимостей, нет понимания что именно сломается. Начинается guesswork.

Проблема не техническая. Проблема в том, что на старте проекта никто не задаёт вопрос: «Когда и как мы будем обновлять это через два года?»

Что мы проверяем в день старта проекта

На каждом новом проекте я веду документ «Технический паспорт». Туда входит отдельный раздел: Lifecycle plan.

Четыре строчки, которые мы фиксируем до первого деплоя:

Текущая версия и дата freeze — какая версия Bitrix стоит сейчас, когда заканчивается её официальная поддержка, когда мы считаем её замороженной и не трогаем без планового окна.
PHP-версия и дата конца LTS — PHP 8.1 поддерживается до декабря 2025, PHP 8.2 до декабря 2026. Ставлю напоминание сразу на старте.
Список кастомных модулей и вендоров — каждый модуль из маркетплейса это отдельная точка риска. Фиксируем название, версию, ссылку на changelog вендора. 20 минут сейчас, несколько часов экономии потом.
Дата первого планового ревью — обычно через 12–14 месяцев после запуска, до следующего мажорного релиза.

Ничего сложного. Но этот документ существует с первого дня, а не создаётся в панике.

Как составить dependency map до первого релиза

Dependency map — это список всего, что «сломается» при мажорном обновлении, если его не подготовить заранее.

В Bitrix у нас три категории:

Ядро и D7 API — старые D6-шаблоны, прямые вызовы устаревших методов. Не переписываем сразу, просто фиксируем. При апгрейде это первый список для проверки.
Кастомные модули и обработчики — всё, что написали сами: обработчики событий, агенты, кастомные компоненты. Для каждого короткая заметка: «зависит от API X, при апгрейде проверить совместимость».
PHP-специфика — deprecated функции, которые уйдут в следующей мажорной версии. Прогоняем php -l и PHPStan на минимальном уровне при сдаче кода. 10 минут, но сразу видно что придётся рефакторить.

Суть не в том, чтобы немедленно всё исправить. Суть в том, чтобы список существовал — и обновлялся при каждом деплое.

Триггеры внепланового ревью

Плановое ревью — раз в год. Но есть события, которые автоматически запускают внеплановое.

Три сигнала, которые я мониторю:

Bitrix выпускает security patch уровня critical. Правило: ставим в течение 72 часов, без мажорного рефакторинга.
PHP-версия уходит в End of Life за 6 месяцев. Мы начинаем migration plan, а не ждём дедлайн.
Вендор кастомного модуля дропает поддержку нашей версии. Проверяем changelog при каждом обновлении модуля.

Эти триггеры — тоже часть Технического паспорта. Задача, которая автоматически создаётся в трекере при наступлении события.

Звучит как бюрократия. На деле — это просто три строчки в документе, которые один раз спасут от трёхдневного кризиса.

Наш upgrade checklist (конкретный список)

Когда наступает плановое окно, мы работаем по следующему порядку.

За 4 недели до:

Поднять тестовую среду на целевой версии PHP и Bitrix
Запустить dependency map и отметить что изменилось с прошлого ревью
Связаться с вендорами кастомных модулей (если есть обновления под новую версию — скачать заранее)

За 2 недели до:

Прогнать тесты на тестовой среде (автоматические + ручной smoke)
Исправить критические несовместимости
Договориться с клиентом о maintenance window (обычно 2-3 часа в воскресенье ночью)

В день обновления:

Бэкап базы и файлов
Обновление на проде по checklist
Smoke test прод

После:

Обновить Технический паспорт (новая версия, следующая дата ревью)
Закрыть задачи из dependency map

Всё это занимает 6–8 часов суммарно. Аварийный апгрейд в нашей практике занимал от 3 до 5 рабочих дней.

Что это даёт в цифрах

Три года назад — аварийный апгрейд с Bitrix 18 на 20, PHP 7.2 → 7.4: 28 человеко-часов, включая откаты и перетестирование. Потеря 1.5 рабочих дня для клиента.

Последний плановый апгрейд (Bitrix 22 → 23, PHP 8.0 → 8.1): 6 часов, ни одного отката, maintenance window по расписанию.

Разница — не в том, что мы стали умнее или опытнее. Разница в том, что список зависимостей и план ревью существовали с первого дня проекта.

Если на вашем проекте Bitrix стоит уже больше года и у вас нет ответа на вопрос «когда мы обновляемся в следующий раз и что сломается» — это не техническая проблема. Это отсутствие документа на двух страницах, который занимает 40 минут при старте проекта.

Завести его прямо сейчас — ещё не поздно. Но лучше было в первый день.

*Внутренние ссылки: Bitrix не тормозит. Тормозит то, как с ним работают · PHP-FPM pm.max_children: параметр, который кладёт Bitrix под нагрузкой*