Оновлення модулів 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 сайтах з кастомним кодом не рекомендується. Автообновлення допустиме лише на сайтах без кастомних обробників подій, без змінених компонентів та лише з налаштованим моніторингом — щоб піймати проблему негайно.

Часові рамки