Налаштування оновлень Bitrix24 On-Premise
Оновлення розповсюджуваного Bitrix24 — не кнопка «Оновити» й готово. Без підготовки оновлення може зламати кастомні доробки, порушити роботу модулів або займати кілька годин на production-сервері. Процес потрібно вистроїти як процедуру.
Як працює система оновлень
Bitrix24 On-Premise отримує оновлення через «Маркетплейс» й вбудований updater. Компонент системи оновлень — /bitrix/updates/. При запуску перевіряє доступні патчі на сервері оновлень dev.1c-bitrix.ru, завантажує пакети й застосовує зміни до файлів і БД.
Оновлення двох типів:
- Patch — точкове виправлення, торкається окремих файлів
-
Release — мажорне оновлення зі змінами структури БД (
b_*таблиці)
Релізи небезпечніше: вони містять міграції БД через \Bitrix\Main\Application::getConnection()->queryExecute(). Якщо кастомний код використовує нестандартні поля в системних таблицях, міграція може зламати дані.
Налаштування автооновлень
У /bitrix/admin/update_system_partner.php можна включити автоматичне отримання й застосування оновлень за розписанням. Це зручно, але ризиковано для production без тестування.
Розумна стратегія: автооновлення включаються тільки для патчів безпеки (SECURITY = Y). Мажорні оновлення — тільки вручну після тестування на staging.
Налаштування через агент у b_agent:
// Агент перевірки оновлень запускається кожні 24 години
CAgent::AddAgent(
"CUpdateClient::CheckUpdates();",
"main",
"N",
86400,
"",
"Y"
);
Процедура оновлення на production
Крок 1: Резервна копія. Перед будь-яким оновленням — бекап файлів і БД. Вбудований модуль резервного копіювання (/bitrix/admin/backup.php) або mysqldump + tar:
mysqldump -u bitrix -p bitrix24_db > /backup/bitrix24_$(date +%Y%m%d_%H%M).sql
tar czf /backup/bitrix24_files_$(date +%Y%m%d_%H%M).tar.gz /var/www/html --exclude=/var/www/html/upload
Крок 2: Тест на staging. Якщо є staging-сервер (а він повинен бути) — застосовуєте оновлення там, прогоняєте функціональне тестування. Перевіряєте:
- Кастомні компоненти в
/local/components/ - Кастомні обробники в
/local/php_interface/init.php - Модулі з
/local/modules/ - Інтеграції з зовнішніми системами (1С, CRM)
Крок 3: Режим обслуговування. Перед оновленням на production — режим технічного обслуговування. У Bitrix'і це реалізується через /bitrix/.maintenance.php:
<?php
// /bitrix/.maintenance.php
header('HTTP/1.1 503 Service Unavailable');
header('Retry-After: 3600');
include '/path/to/maintenance_page.html';
exit;
І в nginx перехоплюєте всі запити й показуєте сторінку обслуговування.
Крок 4: Застосування оновлення. Через /bitrix/admin/update_system.php або через консольний обробник оновлень (у BitrixVM є bitrix-env).
Крок 5: Перевірка після оновлення. Список критичних сторінок: головна, каталог, карточка товару, кошик, оформлення замовлення, особистий кабінет, адміністративна панель. Перевіряєте логи php-fpm й nginx на нові помилки.
Оновлення кастомних модулів з Маркетплейсу
Модулі з Маркетплейсу оновлюються окремо від ядра. У /bitrix/admin/partner_modules.php список установлених модулів із доступними оновленнями. Перед оновленням стороннього модуля — читайте changelog: деякі модулі при оновленні скидають параметри.
Кастомні модулі в /local/modules/ поза зоною оновлень Маркетплейсу — оновлюєте вручну або через свій CI/CD.
Контроль версій кастомного коду
Основна проблема при оновленні: розробники часто модифікують файли ядра Bitrix (/bitrix/modules/) замість використання /local/. При оновленні ядра такі зміни перезаписуються.
Перевірте перед оновленням: немає чи змінених файлів у /bitrix/ (не в /local/). Через Git це просто: якщо /bitrix/ під версійним контролем, git diff покаже зміни. Якщо ні — порівнюєте хеші файлів з еталонним дистрибутивом.
Правильна практика: все кастомне — тільки в /local/. Тоді оновлення ядра безпечне.