Настройка обновлений Битрикс24 On-Premise
Обновление коробочного Битрикс24 — не кнопка «Обновить» и готово. Без подготовки обновление может сломать кастомные доработки, нарушить работу модулей или занять несколько часов на production-сервере. Процесс нужно выстроить как процедуру.
Как работает система обновлений
Битрикс24 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: Maintenance mode. Перед обновлением на production — режим технического обслуживания. В Битриксе это реализуется через /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/modules/) вместо использования /local/. При обновлении ядра такие изменения перезаписываются.
Проверьте перед обновлением: нет ли изменённых файлов в /bitrix/ (не в /local/). Через Git это просто: если /bitrix/ под версионным контролем, git diff покажет изменения. Если нет — сравниваете хеши файлов с эталонным дистрибутивом.
Правильная практика: всё кастомное — только в /local/. Тогда обновление ядра безопасно.