Обновление модулей 1С-Битрикс

Обновление модулей 1С-Битрикс

Обновление ядра и обновление модулей — разные операции с разными рисками. Ядро обновляется редко и требует тщательного тестирования. Модули обновляются чаще и теоретически безопаснее. На практике именно обновление модуля sale или catalog ломает корзину в самый неподходящий момент — потому что кто-то повесил обработчик события на внутренний метод, который изменился.

Как устроено обновление модулей

В Битриксе каждый модуль — это каталог в /bitrix/modules/{module_name}/. Обновление модуля заменяет файлы в этом каталоге. Скрипт install/updater.php (или install/db/mysql/update_{version}.php) выполняется при обновлении и вносит изменения в базу данных.

Обновить модуль можно двумя способами:

• Через панель управления: Настройки → Обновление системы → раздел «Обновления модулей»
• Через консоль: php -f /bitrix/bin/console module.update --module=catalog

Консольный способ предпочтительнее на production: нет ограничений по времени PHP-скрипта, нет зависимости от состояния браузера.

Стандартные модули с высоким риском при обновлении

sale (интернет-магазин). Один из самых часто обновляемых и самых рискованных модулей. При обновлении могут измениться: логика расчёта скидок, порядок вызова событий в процессе создания заказа, поведение методов CSaleOrder::Add() при нестандартных условиях. Любой кастомный код, который использует события OnSaleOrderBeforeSaved, OnBeforeSaleOrderAdd, OnSaleBasketItemAdd — потенциальный источник проблем.

catalog (каталог товаров). Изменения в логике применения цен, фасетной индексации, работе с торговыми предложениями. Если реализован кастомный провайдер цен — проверять совместимость интерфейса.

iblock (инфоблоки). Обычно обратно совместим, но изменения в методах выборки иногда влияют на кеширование и производительность.

main (главный модуль). Обновляется синхронно с ядром. Изменения в ядре авторизации, работе с файлами, ORM — всё здесь.

Модули из Маркетплейс

Сторонние модули из Маркетплейс обновляются независимо от ядра. Проблемы возникают, когда:

• Разработчик выпустил обновление с breaking change и не задокументировал это
• Модуль давно не обновлялся и теряет совместимость при обновлении ядра
• Несколько модулей одновременно слушают одно событие и после обновления одного из них порядок обработчиков меняется

Перед обновлением стороннего модуля — читаем changelog в Маркетплейс. Если changelog отсутствует или краткий — это тревожный сигнал.

Процедура безопасного обновления модулей

Для production с ненулевым трафиком обязателен такой порядок:

1. Бэкап базы данных и файлов модуля (/bitrix/modules/{name}/)
2. Staging — воспроизводим обновление на копии production
3. Тестирование критических сценариев на staging: оформление заказа, добавление в корзину, применение скидок, авторизация — в зависимости от того, какой модуль обновлялся
4. Проверка error log: tail -f /var/log/php_errors.log или лог в панели Битрикса — /bitrix/admin/event_log.php
5. Обновление production в тихое время (ночь, минимальный трафик), в maintenance mode

Откат модуля при проблемах

Если обновление модуля сломало что-то критическое — откат:

1. Остановить сайт (maintenance mode)
2. Восстановить файлы модуля из бэкапа
3. Если скрипт обновления изменил базу данных — восстановить из дампа БД (сделанного до обновления)
4. Проверить, что сайт работает

Откат изменений в базе данных без дампа — практически невозможен: скрипты updater.php редко включают rollback-логику. Именно поэтому бэкап БД перед обновлением — не рекомендация, а обязательное условие.

Автоматическое обновление

Битрикс предоставляет опцию автоматических обновлений по расписанию. На production сайтах с кастомным кодом не рекомендуется. Автообновление допустимо только на сайтах без кастомных обработчиков событий, без модифицированных компонентов и только с настроенным мониторингом — чтобы поймать проблему немедленно.

Сроки