В данной статье речь пойдет об альтернативном быстром способе обновления конфигурации и базы данных 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
- 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
- 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
- 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
- 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 выложен в приложенных файлах. Но вы можете использовать любой способ запуска и контроля данных команд.
- 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-файлов. Что попало грузить не будет. Если находит в файлах ошибки, обязательно об этом скажет в логах - на это обязательно стоит обращать внимание перед обновлением рабочей базы. Например:
