Каталог решений - Быстрое обновление базы 1С из XML-файлов конфигурации (EDT-GIT)

В данной статье речь пойдет об альтернативном быстром способе обновления конфигурации и базы данных 1С, вместо долгого обновления из EDT (1C:Enterprise Development Tools) при использовании хранилища GIT. При желании можно его использовать и в случае работы с конфигуратором. Данный способ заключается в непосредственном обновлении базы данных на сервере баз данных (минуя сервер 1С) из файлов конфигурации XML.

После внедрения новой среды разработки столкнулись с проблемой очень долгого обновления информационной базы из EDT по сравнению с Конфигуратором. Для общего понимания, связка систем разработки у нас такая: EDT — bitbucket – GIT. Итоговое решение можно разделить на три шага и для каждого их них используется свой инструмент. Но у вас может быть вместо bitbucket, например, GitLab, и тогда первый шаг можно решать другими инструментами. Из данной статьи вы можете почерпнуть для себя что-то полезное из каждого пункта и/или выбрать для себя что-то отдельное или все в совокупности. Итак, данные шаги и инструменты:

• Клонирование (получение файлов) необходимой ветки из удаленного репозитария в локальный каталог для дальнейшей работы с ними: Jenkins (программная система предназначенная для обеспечения процесса непрерывной интеграции программного обеспечения — из Википедии)
• Конвертация файлов формата EDT в формат XML- файлов конфигурации: ring (утилита EDT, устанавливается вместе с EDT)
• Быстрое обновление базы данных из XML- файлов конфигурации непосредственно через СУБД MS SQL (минуя Конфигуратор и EDT): ibcmd (утилита автономного сервера 1С, устанавливается вместе с сервером 1С)

Эти шаги можно выстроить в одну цепочку и выполнять последовательно от выгрузки проекта конкретной ветки до обновления конкретной информационной базы или выполнять независимо, например, третий шаг непосредственного обновления с выбором базы и выбором ветки. Второй и третий шаги можно завернуть в любые скрипты, вызывающие командную строку, я же завернул их выполнение в Jenkins, т.к. если он есть, то и используем его возможности по полной. Разберем каждый шаг подробнее. Перед этим распишу переменные данного решения, чтобы при анализе скриптов было проще понять, что это за пути и т.д.:

Настройка окружения / переменные

• Рабочий каталог Jenkins: C:/jenkinsSlave/workspace/
• Рабочий каталог задания и он же локальный каталог проекта EDT, загруженный из удаленного репозитария: C:/jenkinsSlave/workspace/MASTER_XML_FILES_FROM_GIT
• Каталог проекта EDT основной конфигурации: C:/jenkinsSlave/workspace/MASTER_XML_FILES_FROM_GIT/AVC_DU
• Каталог проекта EDT расширения: C:/jenkinsSlave/workspace/MASTER_XML_FILES_FROM_GIT/AVC_DU._скРасширение
• Каталог XML файлов основной конфигурации: C:/1c/EDT/GIT_ORIGIN_MASTER/CF_XML
• Каталог XML файлов расширения: C:/1c/EDT/GIT_ORIGIN_MASTER/CFE_XML
• Версия EDT (ring): edt@2021.2.0:x86_64
• Имя сервера MS SQL: SRV_SQL
• Имя базы MS SQL: TST_TEY
• Имя пользователя MS SQL: user_SQL
• Пароль пользователя MS SQL: pass_SQL
• Имя пользователя базы 1С: user_1C
• Пароль пользователя базы 1С: pass_1C
• Имя расширения конфигурации: _скРасширение
• Каталог лога утилиты ibcmd: C:/jenkinsSlave/workspace/UNI_DB_UPDATE_IBCMD/DATA

1. Jenkins: Получение файлов необходимой ветки из удаленного репозитария в локальный каталог

Как установить и запустить Jenkins, можно найти на просторах интернета, информации по этому поводу довольно много. Самое главное это то, что данный инструмент абсолютно бесплатный. Здесь же я покажу непосредственно само задание, как оно настроено у нас. Создается задача (item) свободной конфигурации, назовем ее к примеру «MASTER_XML_FILES_FROM_GIT» и выделим соответствующим тип (задача со свободной конфигурацией).

Пишем небольшое описание и сразу ставим флаг «Удалять устаревшие сборки» для того, чтобы ограничить хранение истории выполнения данного задания до 5-ти:

Далее – Управление исходным кодом. В моем случае — bitbucket server, credentials – учетная запись в  bitbucket (надо завести отдельно), instance – BITBUCKET (единственный выбор), Project name – имя проекта в GIT, Repository name – имя репозитория  в GIT, Clone from – Primary Server (единственный выбор), Branch Specifier — */master (по умолчанию, если ветка другая, то аналогично ее путь в репозитории).

Триггеры сборки — ставим флаг «Опрашивать SCM об изменениях» и указываем расписание. Указанные настройки говорят о том, что каждый час с 6-ти утра до 23-х вечера (расписание можете указать свое, формат расписания можно посмотреть, нажав знак вопроса), задание будет опрашивать ветку master удаленного репозитария на изменение и, если она изменилась, – обновлять локальный каталог на машине (на котором крутится Jenkins).

На этом в принципе настройку первого пункта можно считать завершенной. Сохраняем и видим наше задание.

Как видно на скриншоте, кроме ветки master, настроены аналогичные задания на другие рабочие ветки (под каждого разработчика). Выгруженные файлы проекта из удаленного репозитария будут выгружены в рабочий каталог Jenkins в папку с именем наименования задания. В нашем случае это C:/jenkinsSlave/workspace/MASTER_XML_FILES_FROM_GIT

2. EDT ring: Конвертация файлов формата EDT в формат XML файлов конфигурации

2.1 Сначала подготовим каталоги XML файлов конфигурации и расширения, куда будут выгружены файлы из локального проекта EDT —  удалим их полностью (можно вместо удаления каталогов очищать вместо rd использовать del, но это дольше), чтобы не было конфликтов и наложений при выгрузке. Далее ring снова создаст эти каталоги

   rd "C:/1c/EDT/GIT_ORIGIN_TEY/CF_XML" /S /Q

   rd "C:/1c/EDT/GIT_ORIGIN_TEY/CFE_XML" /S /Q 

1. 2.2 Выгружаем конфигурацию проекта EDT в XML файлы конфигурации

>CALL ring edt@2021.2.0:x86_64 workspace export —project           C:/jenkinsSlave/workspace/MASTER_XML_FILES_FROM_GIT/AVC_DU —configuration- files "C:/1c/EDT/GIT_ORIGIN_MASTER/CF_XML" —workspace-location C:/jenkinsSlave/workspace/MASTER_XML_FILES_FROM_GIT/AVC_DU

1. 2.3 Выгружаем расширение проекта EDT в XML файлы конфигурации

>CALL ring edt@2021.2.0:x86_64 workspace export —project C:/jenkinsSlave/workspace/MASTER_XML_FILES_FROM_GIT/AVC_DU._скРасширение —configuration-files "C:/1c/EDT/GIT_ORIGIN_MASTER/CFE_XML" —workspace-location C:/jenkinsSlave/workspace/MASTER_XML_FILES_FROM_GIT/AVC_DU._скРасширение

Если настроить эти скрипты в Jenkins в pipeline, то выглядит как на рисунке ниже (информативно, структурировано и красиво). Текст задания данного скрипта в Jenkins выложен в приложенных файлах. Но вы можете использовать любой способ запуска и контроля данных команд.

3. Ibcmd: Быстрое обновление базы данных из XML файлов конфигурации непосредственно через СУБД (MS SQL)

3.1. Импорт конфигурации

>ibcmd infobase config import —dbms=MSSQLServer —db—server=SRV_SQL —db—name=TST_TEY —db—user=user_SQL —db—pwd="pass_SQL" —u user_1C —P pass_1C C:/1c/EDT/GIT_ORIGIN_MASTER/CF_XML —data=C:/jenkinsSlave/workspace/UNI_DB_UPDATE_IBCMD/DATA

3.2. Обновление конфигурации

>ibcmd infobase config apply —dbms=MSSQLServer —db—server=SRV_SQL —db—name=TST_TEY —db—user=user_SQL —db—pwd="pass_SQL" —u user_1C —P pass_1C —data=C:/jenkinsSlave/workspace/UNI_DB_UPDATE_IBCMD/DATA —force

3.3. Импорт расширения

>ibcmd infobase config import —dbms=MSSQLServer —db-server=SRV_SQL —db-name=TST_TEY —db-user=user_SQL —db-pwd="pass_SQL" -u user_1C -P pass_1C C:/1c/EDT/GIT_ORIGIN_MASTER/CFE_XML —extension=_скРасширение —data=C:/jenkinsSlave/workspace/UNI_DB_UPDATE_IBCMD/DATA

3.4. Обновление расширения

>ibcmd infobase config apply —dbms=MSSQLServer —db—server=SRV_SQL —db—name=TST_TEY —db—user=user_SQL —db—pwd="pass_SQL" —u user_1C —P pass_1C —extension=_скРасширеие —data=C:/jenkinsSlave/workspace/UNI_DB_UPDATE_IBCMD/DATA —force

В Jenkins данное задание выглядит так (текст задания данного скрипта в Jenkins выложен в приложенных файлах):

Результат, выводы и дополнения

Время на обновление базы данных сократилось примерно в 10 раз. Если раньше в EDT приходилось синхронизировать ветку, запускать обновление, ждать, подтверждать принятие изменений, опять ждать… И на все это уходило примерно около часа. То теперь это занимает 5-6 минут одной кнопкой, в том числе, включает в себя подтверждение принятия изменений. В расчет не беру первые два шага, т.к. они автоматически обновляют XML-файлы конфигурации ежечасно (можно и чаще настроить). Но даже если нужно обновить базу сразу после внесения изменений в GIT, то в нашем случае это добавляет 15 минут. В любом случае получается 20 минут против 60-ти (быстрее в 3 раза).

Настоятельно рекомендую обкатать данную схему в тестовом окружении и даже перед обновлением рабочей базы обновлять тестовую из тех же XML-файлов. С предварительным архивом – мало ли, механизм новый и еще не обкатанный.

Утилита ibcmd содержит в себе проверки корректности XML-файлов. Что попало грузить не будет. Если находит в файлах ошибки, обязательно об этом скажет в логах — на это обязательно стоит обращать внимание перед обновлением рабочей базы. Например: