Как программно определить версию или факт обновления конфигурации 1С без поломки БСП

← На главную

В процессе построения непрерывной интеграции и доставки (CI/CD), а также при централизованном обслуживании распределенного парка информационных баз (файловых и клиент-серверных) разработчики часто сталкиваются с необходимостью программно проверять, обновлена ли конфигурация, и получать точный идентификатор или номер текущей сборки. При этом стандартное изменение свойства Метаданные.Версия приводит к нежелательным последствиям: встроенные механизмы Библиотеки стандартных подсистем (БСП) инициируют регламентные процедуры обновления базы данных, блокируют сеансы пользователей или вызывают критические ошибки при отсутствии предопределенных обработчиков обновления.

Разберем причины такого поведения платформы и БСП, а также рассмотрим надежные технические способы фиксации и чтения версии сборки конфигурации.

Почему нельзя просто менять свойство «Метаданные.Версия»

Проанализируем архитектуру БСП. Механизм обновления информационной базы жестко привязан к значению свойства Метаданные.Версия и записям в служебном регистре сведений ВерсииПодсистем. При запуске конфигурации БСП сравнивает текущую версию метаданных с версией, сохраненной в базе данных:

Если версия в метаданных увеличилась, БСП запускает длительные монопольные или фоновые процедуры обновления данных (включая блокировку работы пользователей).
Если для новой версии не зарегистрированы обработчики обновления в модулях подсистем, система выдаст ошибку несовместимости версий или зациклит процедуру обновления.
Если версию понизить или изменить случайным образом (например, записать туда хеш Git-коммита, не соответствующий формату X.X.X.X), работа конфигурации будет аварийно остановлена.

Кроме того, платформа 1С:Предприятие изолирует внутренние таблицы базы данных (такие как таблица Config в СУБД или внутренняя структура файла .1CD), поэтому обращаться к ним через стандартный язык запросов 1С невозможно.

Способ 1. Автоматическая генерация версионного модуля или макета в CI/CD (Рекомендуемый подход)

Рассмотрим наиболее правильный подход при использовании современных процессов разработки и сборки. Вместо ручной правки метаданных или попыток парсинга конфигурации на лету, фиксация версии, номера билда или хеша Git-коммита выносится на этап сборки дистрибутива (до формирования файла .cf).

В пайплайне сборки скрипт автоматически перезаписывает тело служебного общего модуля или заполняет текстовый макет конфигурации актуальными данными сборки:


// Пример функции в специализированном общем модуле "СлужебныйМодульСборки"
// Тело функции автоматически генерируется скриптом сборки
Функция ПолучитьСведенияОСборке() Экспорт

    Сведения = Новый Структура;
    Сведения.Вставить("НомерСборки", 1042);
    Сведения.Вставить("ХешКоммита", "a1b2c3d4e5f67890");
    Сведения.Вставить("ДатаСборки", '20240415120000');
    
    Возврат Сведения;

КонецФункции

Преимущества данного метода:

Метод работает одинаково быстро и надежно как в клиент-серверном, так и в файловом варианте информационной базы.
Свойство Метаданные.Версия остается нетронутым, что полностью исключает сбои в логике БСП.
Исключается человеческий фактор: при срочных хотфиксах номер билда всегда обновляется автоматически.

Способ 2. Регистрация собственной подсистемы в механизме БСП

Разберем штатную возможность БСП, если необходимо вести независимое версионирование доработок конфигурации без изменения версии конфигурации поставщика:

В дереве метаданных создаем отдельную подсистему (например, ДоработкаСистемы).
В общем модуле ПодсистемыКонфигурацииПереопределяемый в процедуре ПриДобавленииПодсистем регистрируем подсистему и указываем ее модуль обновления.
При обновлении доработок меняем номер версии только для нашей подсистемы. БСП корректно запишет ее версию в регистр ВерсииПодсистем и выполнит только назначенные обработчики, не затрагивая типовую конфигурацию.

Способ 3. Отслеживание событий изменения конфигурации через журнал регистрации

Если требуется зафиксировать сам факт обновления базы на уровне платформы без внедрения внешних скриптов сборки, можно использовать системное событие журнала регистрации. Чтобы не создавать избыточную нагрузку на высоконагруженных базах и узлах РИБ, настроим журнал только на фиксацию изменений конфигурации.

Посмотрим на пример включения отслеживания нужного события встроенным языком:


// Включение регистрации только события изменения конфигурации
ИспользованиеСобытия = Новый ИспользованиеСобытияЖурналаРегистрации(Истина);
УстановитьИспользованиеСобытияЖурналаРегистрации("_$InfoBase$_.ConfigUpdate", ИспользованиеСобытия);

Для программного чтения даты и параметров последнего обновления выполним выборку записей журнала регистрации:


ФильтрЖурнала = Новый Структура;
ФильтрЖурнала.Вставить("Событие", "_$InfoBase$_.ConfigUpdate");

ВыгрузкаЖурнала = Новый ТаблицаЗначений;
ВыгрузитьЖурналРегистрации(ВыгрузкаЖурнала, ФильтрЖурнала, "Дата, Пользователь, ПредставлениеСобытия", , 1);

Если ВыгрузкаЖурнала.Количество() > 0 Тогда
    ДатаПоследнегоОбновления = ВыгрузкаЖурнала[0].Дата;
КонецЕсли;

Способ 4. Получение контрольной суммы конфигурации через сообщение обмена

Выясним, как платформа 1С определяет различия в конфигурациях в механизме распределенных информационных баз (РИБ). При формировании заголовка сообщения обмена через план обмена платформа автоматически вычисляет контрольные суммы метаданных (Digest1 и Digest2) и помещает их в заголовок XML-файла.

Сформировав служебный заголовок пакета обмена без выгрузки данных, можно программно извлечь дайджест и использовать его как эталонный хеш для точного сравнения версий конфигураций между несколькими базами без выгрузки конфигурации в файл .cf.