Обновлять боевой сайт напрямую рискованно. Правильный порядок — накатить и проверить апдейты на тестовой копии, а затем перенести проверенный результат на прод контролируемо и с возможностью отката.
Зачем нужен тестовый контур
Прямое обновление боевого сайта через SiteUpdate опасно: апдейт может изменить структуру таблиц, шаблоны компонентов и поведение модулей. На активном проекте это чревато простоем магазина и потерей заказов.
Тестовый контур — это отдельная копия сайта (файлы + база данных), где вы:
- устанавливаете обновления и смотрите, не сломались ли ключевые сценарии;
- проверяете доработки и кастомные компоненты на совместимость;
- фиксируете точный перечень изменений, которые предстоит перенести на прод.
Тестовый сайт должен быть максимально идентичен боевому по версиям PHP, СУБД и составу модулей — иначе результаты проверки будут недостоверными.
Подготовка тестовой копии
Копию удобно снимать штатной резервной копией из Настройки → Инструменты → Резервное копирование и разворачивать её на отдельном домене или поддомене.
- Создайте полную резервную копию боевого сайта (файлы и база данных).
- Разверните архив на тестовом окружении с теми же версиями PHP и MySQL.
- Отключите на копии реальные интеграции: боевой SMTP, платёжные и почтовые уведомления клиентам. Проверьте
.settings.phpи почтовые события. - Убедитесь, что тестовая копия проходит проверку в Настройки → Проверка системы.
Отдельно проверьте лицензию: для скачивания апдейтов у копии должна быть активна подписка на обновления. Технический ключ демо-версии обновления не тянет.
Установка обновлений на тесте
Обновления устанавливаются через модуль SiteUpdate.
- Откройте Настройки → Обновление платформы → Обновление платформы (SiteUpdate).
- Дождитесь получения списка доступных апдейтов и нажмите Загрузить и установить обновления.
- Если апдейтов много, ставьте их порциями, а не все разом — так проще локализовать сбой.
- После каждой порции проверяйте Настройки → Инструменты → Журнал событий на предмет ошибок модулей.
Зафиксируйте до и после установки версии ядра и модулей — их видно в Настройки → Обновление платформы → Обновления (столбец с текущими версиями). Этот список версий и есть эталон, к которому нужно привести боевой сайт.
Что именно переносить на прод
Обновление затрагивает несколько уровней. Переносить нужно согласованно — файлы и база должны соответствовать одной версии.
| Что меняется | Где хранится | Как переносить |
|---|---|---|
| Файлы ядра и модулей | /bitrix/modules/, /bitrix/js/, /bitrix/admin/ | Повторно накатить те же апдейты на проде через SiteUpdate |
| Изменения структуры БД | Таблицы модулей | Применяются самим апдейтом при установке (или update-скриптами модуля) |
| Скопированные из дистрибутива компоненты | /bitrix/components/, шаблоны | Перенести вручную сравнением файлов |
| Кастомные доработки | /local/ | Переносятся отдельно, вне механизма обновлений |
Важно: нельзя просто скопировать папку /bitrix/modules/ с теста на прод, не тронув базу. Апдейты модулей часто содержат SQL-миграции, и без них файлы новой версии обратятся к несуществующим полям таблиц.
Два способа переноса на боевой сайт
Способ 1. Повторное обновление через SiteUpdate (рекомендуется)
Самый надёжный путь: не копировать файлы, а установить на боевом сайте те же самые апдейты, которые вы уже проверили на тесте. Механизм сам согласует файлы и структуру БД.
- Сделайте свежую резервную копию боевого сайта.
- Включите режим технических работ (
/bitrix/tmpили заглушку), закройте доступ покупателям. - Откройте на проде Настройки → Обновление платформы (SiteUpdate) и установите те же обновления, тем же порядком, что на тесте.
- Дождитесь завершения и снимите режим технических работ.
Способ 2. Ручной перенос файлов
Применяется только для доработок в /local/ и правок шаблонов, не для ядра. Сравните каталоги теста и прода (по контрольным суммам или через систему контроля версий) и перенесите только изменённые файлы. Обновлять ядро копированием папок не следует.
Проверка после переноса
После обновления боевого сайта пройдите короткий чек-лист:
- Настройки → Проверка системы — без критических ошибок;
- Журнал событий — нет свежих ошибок ядра и модулей;
- версии ядра и модулей совпадают с эталоном, зафиксированным на тесте;
- работают ключевые сценарии: оформление заказа, оплата, регистрация, отправка писем;
- очищен кеш (Настройки → Настройки продукта → Автокеширование и сброс кеша компонентов).
Если что-то пошло не так, разворачивайте резервную копию, снятую непосредственно перед обновлением, — это самый быстрый и предсказуемый откат.
Частые ошибки
- Копируют только файлы модулей, забывая про базу. После этого админка выдаёт ошибки SQL. Обновление должно идти через SiteUpdate, который применит миграции БД.
- Тест и прод на разных версиях PHP/MySQL. Апдейт, прошедший на тесте, падает на проде. Окружения нужно выравнивать заранее.
- Нет свежего бэкапа перед обновлением прода. Откат становится невозможен. Резервную копию делают непосредственно перед установкой.
- Обновляют боевой сайт в часы пиковой нагрузки. Во время миграции БД сайт лучше закрыть режимом технических работ.
- На тесте отключены не все боевые уведомления. Клиенты получают тестовые письма о заказах. Проверьте почтовые события и настройки SMTP на копии.
- Устанавливают все апдейты одной пачкой. При сбое сложно понять, какой именно модуль виноват. Ставьте порциями.
Итог
Безопасный перенос обновлений строится на трёх правилах: сначала проверка на идентичной тестовой копии, затем установка тех же апдейтов на проде через SiteUpdate (а не копирование папок), и обязательный свежий бэкап для отката.
Держите тестовый контур в актуальном состоянии по версиям окружения и составу модулей, ставьте обновления порциями и после каждого переноса сверяйте версии и журнал событий. Такой процесс превращает обновление боевого сайта из риска в рутинную предсказуемую операцию.