27.11.2025 06:21
badcasedaily1 0 2300 Источник

Привет, Хабр! Поговорим о том, как принципы GitOps можно применить к разработке конфигураций 1С:Предприятия.

Классическая разработка на 1С:Предприятии подразумевает использование встроенного хранилища конфигурации. Все подключаются к одному хранилищу, выкачивают изменения, закачивают своего рода централизованный VCS от 1С. Но у такого подхода есть масса недостатков. Во-первых, в хранилище версионируется сразу вся конфигурация целиком, а не отдельные файлы или модули. Если команда большая, конфигурация объёмная, слияния создают трудности код-ревью затруднён. Во-вторых, нет нормального ветвления, обычно на каждый контур поднимают своё раздельное хранилище, и изменения переносятся между ними вручную или скриптами. В-третьих, интеграция с современными CI-системами отсутствует, хранилище 1С живёт своей жизнью.

Современная альтернатива – это хранить исходники конфигурации в Git-репозитории. Причём последние версии 1С:Предприятие предлагают два пути к этому:

  • Использовать 1С:EDT, новую среду разработки на основе Eclipse. EDT работает напрямую с Git, в нём поддержка веток, коммитов и прочих радостей распределённой системы версий. Код конфигурации хранится в виде множества текстовых файлов (модули, формы в формате XML и т.д.), что подходит для Git.

  • Для тех, кто пока сидит на старом добром конфигураторе, есть промежуточный вариант, выгружать конфигурацию в файлы (через выгрузку в XML), а потом эти файлы коммитить в Git. Это можно делать вручную, а можно автоматизировать какими-нибудь утилитами, например, 1C:GitConverter.

Конечно, переход на EDT+Git наиболее адекватный путь. EDT сразу решает множество проблем, в нём есть и ветки, и параллельная работа, и возможность видеть разницу в коде. Но реальность такова, что некоторые проекты ещё требуют использования конфигуратора. Поэтому расскажу о GitOps-подходе применимо к обоим сценариям.

GitOps для 1С: общий конвейер

Набросаем общие шаги такого конвейера:

  1. Разработка: программисты делают изменения либо в EDT-проекте, либо в конфигураторе. В случае EDT они сразу коммитят изменения в Git. В случае конфигуратора, они сохраняют изменения в центральном хранилище 1С.

  2. Экспорт в Git: если работаем через EDT, этот шаг уже выполнен. Если через конфигуратор, то нужна промежуточная синхронизация, с определённой периодичностью или по триггеру выгружаем конфигурацию в файлы и делаем коммит в репозиторий. Тут поможет 1С:GitКонвертер, который умеет из хранилища конфигурации выгружать изменения в XML-файлы и коммитить их в Git. Можно настроить её запуск по расписанию.

  3. CI-сервер замечает новые коммиты в репозитории и запускает pipeline сборки. Например, настроили Jenkins или GitLab CI, неважно, принцип похожий.

  4. Сборка конфигурации: на выделенном агенте запускается процесс сборки. Если у нас EDT, то выполняется экспорт EDT-проекта в формат, понятный конфигуратору (утилита EDT CLI). Дело в том, что сам EDT не умеет собирать cf-файл или базу. EDT CLI экспортирует исходники в .cf или непосредственно в XML для конфигуратора. А затем в ход идёт пакетный режим конфигуратора, запускается 1cv8.exe DESIGNER /LoadConfigFromFiles ... /UpdateDBCfg ... на пустой базе. Получаем обновлённую конфигурацию в файловой базе на сервере. Если используем конфигуратор + GitConverter, то шаг с EDT скипается

  5. Статический анализ: после сборки можно запустить проверку качества кода. Здесь два варианта:

    • АПК (Автоматическая проверка конфигурации) – встроенный инструмент от 1С, который анализирует конфу на типовые ошибки, неинициализированные переменные, неиспользуемый код, потенциальные проблемы и т.д. АПК работает без запуска приложения, просто по структуре метаданных и модулей.

    • SonarQube. Можно конвейером выгрузить исходники и прогнать через sonar-scanner, используя плагины для BSL (языка 1С).

    В идеале, использовать оба подхода в связке.

  6. Автоматизированное тестирование: следующий этап, прогоним наши модификации через тесты. В экосистеме 1С сейчас доступны по крайней мере два варианта:

    • 1С:Сценарное тестирование. Встроенный фреймворк, позволяющий писать тесты на самом 1С. Запускается через TestManager. Хорош для регрессионных модульных тестов.

    • BDD-тестирование (Behavior Driven). Скорее про интеграционные тесты, пользовательские сценарии. Здесь на помощь приходит опенсорс Vanessa Automation. С ее помощью пишут фичи на Gherkin и запускают их, проверяя поведение системы.

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

    Для запуска проще всего воспользоваться утилитой vanessa-runner, которая умеет разворачивать базу, запускать сценарные тесты или Vanessa Automation, а потом гасить базу. Фактически, vrunner обёртывает запуск клиента 1С с нужными параметрами. Команда может выглядеть так (псевдо-пример):

oscript vrunner.epf xunit \
    --ibconnection "/F ./build/TestBase" \
    --run-tests *.json \
    --report-junit "./reports/xunit.xml" \
    --v8version "8.3.20"

Уутилита запускает 1С:Предприятие в режиме TestClient, прогоняет все тесты и складывает отчет в JUnit-формате. Аналогично и для BDD, Vanessa Automation тоже можно запускать через vrunner или отдельным скриптом. Если без OneScript, то пришлось бы городить вызов 1cv8 ENTERPRISE /TestManager с указанием файла тестов и базы, но там уже много нюансов.

Если тесты провалились, то конвейер останавливается, ответственный разработчик получает письмо с отчётом, это тоже легко настроить, Jenkins умеет отправлять уведомления.

7. Деплой на контур: вот мы и добрались до финала. Предположим, код прошёл проверки качества и все тесты зелёные. Значит, изменения можно выкатить. В GitOps идеологии обычно делают merge в основную ветку, и автодеплой на прод. В случае 1С это обновление базы до новой конфигурации. Здесь уже обычно решается гибко, у кого-то деплой в прод автоматизирован, у кого-то полуавтомат. Часто финальное обновление делают вручную в регламентное время, особенно если система критичная. Но элементы автоматизации всё равно можно задействовать:

  • можно настроить ночной сборочный сервер, чтобы он сам формировал файлы обновления на основе свежей конфигурации.

  • для управляемых форм возможен автоматический запуск обновления базы через пакетный режим.

  • либо хотя бы подготовить скрипт, который ответственный человек запустит, и он обновит через тонкий клиент все базы.

В нашем пайплайне пока последним шагом будет формирование готового релизного пакета, мы сохраняем полученный .cf файл новой конфигурации и публикуем его как артефакт. Также генерируем инструкцию по обновлению. А уже непосредственно выкладку на продуктив делают специалисты по релизам вручную, потому что у нас довольно строгие требования к процедуре. Но технически ничто не мешает автоматизировать и сам деплой. GitOps подразумевает, что при коммите, скажем, тега production-release может сработать джоб, который возьмёт этот .cf и применит его к прод-базе.

Итак, получился конвейер: код -> Git -> CI/CD -> результат в виде обновлённой 1С-базы. Теперь обсудим некоторые нюансы, упомянутые выше.

Инструменты

Если вы не используете EDT, а хотите всё же подключить Git, рекомендую обратить внимание на официальную утилиту 1С:ГитКонвертер. Она предназначена для односторонней синхронизации хранилища конфигурации с Git-репозиторием. Т.е. разработчики продолжают работать через конфигуратор и централизованное хранилище, а GitConverter по расписанию выгружает свежие версии в файлы и делает коммит. Это хороший временный шаг, чтобы начать использовать плюсы Git.

Конечно, лучший путь, сразу разрабатывать в EDT с Git. Созаем новую ветку прямо в IDE, делаем изменения, коммитим и можно тут же отправить merge request. Конвейер CI подхватит эти изменения и соберёт. У EDT есть CLI, который мы используем. Например, команда экспорта EDT-проекта может выглядеть так:

"C:\Program Files\1C\EDT\edtlite.exe" export \
    --project "C:\Work\My1CProject" \
    --configuration-files "C:\CI\src" \
    --format DistributionFiles

Команда выгрузит проект EDT в набор файлов конфигурации. Дальше по скрипту запускаем конфигуратор:

"C:\Program Files\1cv8\8.3.20.1710\bin\1cv8.exe" DESIGNER \
    /F "C:\CI\Build\TmpBase" \
    /LoadConfigFromFiles "C:\CI\src" \
    /UpdateDBCfg \
    /DisableStartupDialogs \
    /Out "build.log" \
    /Exit

За один вызов мы загрузили конфигурацию из файлов в пустую инфобазу и обновили ее. Запускать всё это дело желательно на отдельной базе.

Далее, тестирование, как мы обсудили, можно выполнить, например, так:

oscript vrunner.os test --reports "./reports" \
    --ibconnection "/F ./CI/Build/TstBase" \
    --additional "/C КонтролироватьЗавершениеРаботы=Истина"

С параметрами test vrunner сам найдёт тесты, запустит 1С в режиме TestClient и сформирует отчеты. Параметр КонтролироватьЗавершениеРаботы=Истина заставляет 1С закрыться по окончании тестирования, что удобно для CI.

Отчёты можно сохранить, и CI-сервер их подхватит и отобразит в удобном виде. В Jenkins, например, тестовый этап завершается загрузкой отчёта Allure и отправкой письма, если есть упавшие тесты.

Выводы

Напоследок, начинайте с малого. Можно сначала просто наладить выгрузку конфигурации в файлы под Git. Потом автоматизируйте сборку ночью, чтобы каждое утро была свежая тестовая база. Затем подтяните авто-тесты... Шаг за шагом вы придёте к полной CI/CD цепочке.

Спасибо за внимание!

Если вы хотите системно прокачать навыки автоматизации разработки и доставки решений на 1С, в OTUS есть профильный курс DevOps 1С. Программа глубже раскрывает практики CI/CD, мониторинга и интеграций на платформе, помогая собрать цельный инженерный стек вокруг процессов, описанных в статье. Такой подход заметно снижает операционные риски и повышает эффективность команд, работающих с 1С в реальных продакшн-средах. Пройдите входной тест, чтобы узнать, подойдет ли вам программа.

Чтобы узнать больше о формате обучения и познакомиться с преподавателями, приходите на бесплатные демо-уроки:

  • 1 декабря: «1С и RabbitMQ». Записаться

  • 8 декабря: «Поговорим про Kafka». Записаться

  • 15 декабря: «Автоматизация процессов команды разработки. Интегрируем 1Сников». Записаться

Комментарии (0)