Мастер обновлений тиражного решения

Обновления тиражного решения в 1С-Битрикс — это не «залить новый архив», а последовательное применение версий через папки updater и объект $updater. Разберём, как это работает, как писать скрипты обновления и как их тестировать.

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

Система обновлений Маркетплейс построена на сравнении версий. У клиента установлена версия из install/version.php, а сервер обновлений (updates.bitrix.info) знает актуальную версию вашего решения. Модуль SiteUpdate на стороне клиента запрашивает разницу и применяет недостающие версии по порядку.

Ключевая идея — обновления инкрементальные и последовательные. Если клиент на 1.0.0, а вышла 1.0.3, система применит скрипты 1.0.1, 1.0.2, 1.0.3 строго друг за другом. Поэтому каждая версия должна быть самодостаточным шагом от предыдущей.

• клиент инициирует обновление из Marketplace → Обновление решений;
• SiteUpdate скачивает архив обновлений и распаковывает скрипты updater;
• каждый updater-скрипт применяется в порядке возрастания версий;
• после успешного применения версия в version.php повышается.

Номер версии в version.php

Отправная точка любого обновления — корректная версия в install/version.php:

<?php $arModuleVersion = array("VERSION" => "1.0.3", "VERSION_DATE" => "2026-01-01 00:00:00");

Правила версионирования, без которых обновления не применятся корректно:

• версия должна строго возрастать — система не применит «пониженную» или равную версию;
• каждой новой версии соответствует свой каталог обновления с тем же номером;
• VERSION_DATE обновляется вместе с версией и не должна быть из будущего.

Структура каталога обновления

Обновления живут внутри установщика модуля, в каталоге updater. Каждая версия — это отдельная папка, названная по номеру версии, а внутри неё — исполняемый скрипт обновления и файлы, которые нужно доставить клиенту.

Упрощённая структура выглядит так:

/bitrix/modules/partner_code.module_name/install/updater/1.0.1/updater.php

/bitrix/modules/partner_code.module_name/install/updater/1.0.2/updater.php

/bitrix/modules/partner_code.module_name/install/updater/1.0.3/updater.php

Рядом со скриптом размещаются каталоги с новыми или изменёнными файлами (например, компоненты, шаблоны, файлы модуля), которые updater-скрипт копирует в целевые пути. Файл .last_version в служебной структуре решения указывает системе на актуальный доступный номер версии.

Объект $updater и его методы

Внутри updater-скрипта доступен объект $updater. Через него выполняются все операции: копирование файлов, вызов установки/удаления сущностей и вывод сообщений о ходе обновления. Наиболее используемые методы:

Пример скрипта updater

Типовой updater-скрипт делает две вещи: доставляет обновлённые файлы и, при необходимости, запускает миграцию данных. Каркас для версии 1.0.3:

<?php
if (!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED !== true) die();

if ($updater->CanUpdateKernel()) {
  $updater->CopyFiles("install/components", "components");
  $updater->CopyFiles("install/js", "js");
}

if ($updater->CanUpdateDatabase()) {
  // миграция БД для этой версии
  $updater->Query("...");
  $updater->AddMessage("Схема данных обновлена до 1.0.3");
}

Обратите внимание: копирование ядра/файлов и изменения БД разделены проверками возможностей обновления. Это защищает от применения части шага в неподходящем окружении.

Миграции БД и безопасность

Изменения структуры данных — самая рискованная часть обновления. Их нельзя откатить «одной кнопкой», поэтому пишите миграции максимально безопасно:

• Идемпотентность. Проверяйте существование таблицы/колонки перед созданием, чтобы повторный прогон не падал.
• Без разрушающих операций «вслепую». Удаление колонок и данных — только с явной проверкой и, по возможности, с сохранением бэкапа значений.
• Отделяйте данные от кода. Копирование файлов и миграцию данных держите в разных проверяемых блоках.

Тестирование обновления

Обновление тестируется не «на новой установке», а именно как переход между версиями. Воспроизведите путь клиента:

1. установите предыдущую версию решения на чистый стенд;
2. наполните её реальными данными (инфоблоки, настройки, таблицы модуля);
3. примените обновление через SiteUpdate и проверьте отчёт;
4. убедитесь, что версия в version.php поднялась, файлы скопированы, миграция прошла;
5. проверьте «длинный» переход — сразу через несколько версий (1.0.0 → 1.0.3), чтобы отловить нарушенную последовательность.

Отдельно проверяйте сценарий, когда у клиента модифицированы файлы: CopyFiles перезаписывает целевые пути, и это должно быть ожидаемым поведением, а не сюрпризом.

Итог

Мастер обновлений тиражного решения работает на трёх принципах: монотонная версия в install/version.php, каталоги updater по номерам версий и последовательное применение скриптов через объект $updater. Безопасные идемпотентные миграции, разделение файлов и данных, а также тестирование именно перехода между версиями избавляют клиентов от сломанных обновлений.

Если ваше решение растёт, а обновления затрагивают сложную схему данных и интеграции — мы помогаем выстроить надёжный процесс релизов, миграций и поддержки тиражных решений на 1С-Битрикс, от архитектуры updater до автоматизации выкладки.