Отражаем хранилище в репозиторий git, Jenkins'ом. Опять 25

25.05.26

Разработка - DevOps и автоматизация разработки

Одна линия сборки для обработки нескольких конфигураций - выгрузка хранилищ в git, запуск анализа SonarQube.
Достаточно давно опубликовал статью на эту тему - Отражаем хранилище в репозиторий git, Jenkins'ом. Пришлось вернуться к этой теме - переосмыслить и переделать.

По мотивам статьи было реализовано ~10 линий сборки. Ну работали себе. Время от времени ломались из-за новых авторов в хранилище, чинились, работали дальше.

Но вот понадобилось добавить еще ~15 линий (отсюда "Опять 25":) и немного переделать текущие.
Начал заниматься всем этим. Но на 8-й линии уже психанул - ведь работа несложная, но кропотливая и однотипная (!). Поэтому озадачился и решил написать единую линию сборки, где все проекты были бы описаны в отдельном файле и хранились в репозитории - чтобы вообще в Jenkins не лазить. За пару вечеров допилил.

 

Предназначение

Пайплайн выгружает несколько хранилищ в git-репозитории и (опционально) запускает анализ кода sonar scanner'ом.

 
 Код пайплайна (jenkinsfile)

Ключевые возможности

  • Чтение общих и проектных настроек из JSON-файлов.
  • Фильтрация запускаемых проектов через параметр PROJECT_FILTER.
  • Параллельная и последовательная обработка проектов.
  • Опциональный таймаут для каждого проекта.
  • Безопасная работа с секретами (токен SonarQube, учетные данные Git).
  • Обработка ошибок: сбой одного проекта не останавливает весь пайплайн.
  • Использование библиотеки gitsync для переноса коммитов хранилища в Git-репозиторий.
  • Возможность задавать произвольные параметры для gitsync и sonar scanner через переменные окружения.

Большую роль играет то, что и gitsync, и sonar scanner могут параметризоваться переменными окружения. И поэтому любые такие настройки можно задать при описании общих и/или проектных настроек - эти настройки "транслируются" в переменные окружения.

 
 Пример общих настроек, с комментариями (common.json)

 

{
  # Метка Jenkins-агента, где будет происходить сборка
  "agentLabel": "sonar",
  # Кодовая страница для логов gitsync и sonar scanner 
  "codepage": "65001",
  # ID секрета, хранящего раздельно пользователя и пароль для подключения к git-репозиторию
  "gitCredentialsID": "git_token",
  # ID секрета, хранящего токен для подключения к SonarQube
  "sonarqubeTokenID": "sonarqube_token",
  # Настройки проектов "по умолчанию". 
  # Все ключи из default могут быть переопределены непосредственно в объекте проекта (на верхнем уровне).
  "default": {
    # Проект активен
    "active": true,
    # Каталог репозитория, где хранятся сами исходники
    "srcDir": "src", 
    # Запускать анализ SQ
    "useSonar": true,
    # Ветка репозитория исходников. Бывает и main, и master. Указываем, как нам нужно.
    "branch": "main",
    # Запускать параллельно с другими проектами
    "parallel": true,
    # Дополнительные параметры командной строки для gitsync
    "otherGitsyncParams": "",
    # Дополнительные параметры командной строки для sonar scanner
    "otherSonarScannerParams": "",
    # Очищать рабочий каталог перед запуском gitsync.
    "clearDir": true,
    # Можем ограничить таймаутом время сборки проекта
    "timeoutMinutes": 0
  },
  # Переменные окружения "по умолчанию"
  # Здесь и переменные gitsync, и sonar scanner.
  "env": {
    "V8VERSION": "8.3.22.2283",
    "GITSYNC_STORAGE_USER": "user_gitsync",
    "GITSYNC_DOMAIN_EMAIL": "domain.ru",
    "GITSYNC_EMAIL": "domain.ru",
    "GITSYNC_REMOTE_PUSH_N_COMMITS": "2",
    "GITSYNC_LIMIT": "0",
    "GITSYNC_REMOTE_PUSH_TAGS": "true",
    "GITSYNC_REMOTE_PUSH": "true",
    "GITSYNC_SKIP_EXISTS_TAGS": "true",
    "GITSYNC_TASK_PREFIX": "#",
    "SONAR_HOST_URL": "https://sonarqube:9443",
    "SONAR_SOURCE_ENCODING": "UTF-8",
    "SONAR_INCLUSIONS": "**\\*.bsl",
    "SONAR_SCANNER_JAVA_OPTS": "-Xmx2G"
  }
}

* JSON не предусматривает комментарии - удалить.

 
 Пример настроек проектов, с комментариями (projects.json)

 

[
    {
        # Задаем другую основную ветку
        "branch": "master",
        "env": {
            # Это расширение
            "GITSYNC_EXTENSION": "РасширениеВнешниеКонтрагентыДоговоры",
            # Путь к хранилищу
            "GITSYNC_STORAGE_PATH": "//STORAGES-1C/Расширения/РасширениеВнешниеКонтрагентыДоговоры/",
            # URL git-репозитория
            "GITSYNC_REPO_URL": "https://STORAGES-GIT/docflow/ebd-external_data.git",
            # Ключ проекта SonarQube
            "SONAR_PROJECT_KEY": "ebd.external_data"
        }
    },
    {
        # Отключаем параллельность
        "parallel": false,
        "env": {
            "GITSYNC_STORAGE_PATH": "//STORAGES-1C/TechProjects/194_БП/",
            "GITSYNC_REPO_URL": "https://STORAGES-GIT/1c/prom/main_disconnects.git",
            "SONAR_PROJECT_KEY": "Prom_bp_disconnect",
            # Имя проекта SonarQube
            "SONAR_PROJECT_NAME": "Пром (БП Отключения)",
            # Дополнительные java-опции для sonar scanner
            "SONAR_SCANNER_JAVA_OPTS": "-Xmx8G -Xms2G -Dfile.encoding=UTF-8"
      }
    }
]

* JSON не предусматривает комментарии - удалить.

 

Примечания

  • Проектные настройки дополняют и "перекрывают" значения по умолчанию.
  • Конечный запуск cli-утилит выполняется с помощью powershell, т.к. bat как-то неустойчиво ведет себя, именно при использовании в скриптовом pipeline, - может на ровном месте зависнуть. А в freestyle-проектах такой проблемы не наблюдается.
  • Ключ проекта передается не через переменную окружения, дописан через "--define". У меня почему-то из переменной окружения sonar scanner не брал ключ. И через "-Dsonar.projectKey=" тоже не брал. А через "--define" взял.
  • Сначала выполняется параллельная сборка, затем выполняются последовательные сборки.
  • Ключ sonar-проекта (env.SONAR_PROJECT_KEY) нужно задавать, даже если анализ кода отключен. Используется для заголовка шага сборки.
  • Не проработана тема с credentials для доступа к хранилищу для gitsync. Может позже доделаю.
  • Немного озадачился безопасностью для параметров, которые могут быть дописаны в командную строку (см.метод sanitizeParams), чтобы избежать injections. Но тут тема более серьезная. Может и вообще нужно убрать эти доп.параметры командной строки.

 

Дополнительные возможности

Фильтр проектов

При запуске задания в Jenkins можно задать, какие проекты обрабатывать. Для этого нужно линию сборки сделать параметризованной, ввести параметр PROJECT_FILTER с значением по умолчанию "*".

Варианты фильтра:

  • * - все проекты, с учетом их активности
  • cf - обработка основных конфигураций, с учетом активности
  • cfe - обработка расширений
  • Ключи необходимых проектов, через пробел. Настройка активности не учитывается.

Таймауты

Можно задать таймаут в минутах для обработки проекта. Для отключения таймаута - указать 0 (ноль).

Плагины

Требуются плагины Jenkins:

  • Pipeline Utility Steps (для `readJSON`, `readFile` и др.)
  • Git Plugin (для клонирования репозиториев)

 

Итоги

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

Вступайте в нашу телеграмм-группу Инфостарт

Jenkins SonarQube gitsync

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Тестирование QA DevOps и автоматизация разработки Программист Пользователь 1С:Предприятие 8 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.190.11.

5368 руб.

20.01.2022    11701    48    1    

21

DevOps и автоматизация разработки Тестирование QA Программист Пользователь 1С:Предприятие 8 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Зарплата и Управление Персоналом 3 и версии КОРП: 3.1.35.48.

5000 руб.

05.08.2024    6006    36    1    

20

Тестирование QA DevOps и автоматизация разработки Программист 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.22.145.

5000 руб.

04.07.2022    13992    50    6    

39

DevOps и автоматизация разработки Программист Бесплатно (free)

Хватит ограничивать себя родным и уютным стеком 1С. Пора расширять кругозор и осваивать смежные стеки! Разберемся, как Docker может упростить жизнь одинэснику: от сборки и тестирования 1С до запуска инфраструктуры и автоматизации CI/CD, причем быстро, воспроизводимо и без лишнего мусора в системе.

08.05.2026    2652    sleemp    65    

34

DevOps и автоматизация разработки Мониторинг Системный администратор Программист Бесплатно (free)

Практический гайд по применению DevOps-практик в 1С-инфраструктуре: контейнеризация СУБД, инфраструктура как код, мониторинг с алертами, автоматические бэкапы. Разбираю подводные камни и делюсь готовыми конфигами. Для 1С-разработчиков, которые хотят автоматизировать рутину и приблизиться к продакшен-среде.

06.04.2026    10064    vladimir-89    10    

29

DevOps и автоматизация разработки Программист Бесплатно (free)

Если вы думаете, что внедрение CDC конвейера — это геморрой, то вы правы. Но мы уже прошли через все боли: от настройки MSSQL CDC до танцев с Kafka и ClickHouse. Теперь конвейер работает и данные ключевых операций в 1С, от которых зависит бизнес, попадают в ClickHouse, где их можно анализировать и использовать для мониторинга в реальном времени. В этой статье я расскажу, как выглядит архитектура и с какими проблемами можно столкнуться

05.03.2026    1251    NesterTop1    4    

5

DevOps и автоматизация разработки EDT Программист Бесплатно (free)

Разбираемся, почему ручной деплой в 1С все еще жив и сколько времени он на самом деле занимает, несмотря на стремительное развитие CI/CD-подходов. На реальном кейсе показываем, что корень проблемы чаще кроется не в автоматизации, а в ее неэффективной настройке. Событийная модель вместо расписаний, параллельные тесты, использование кеша Gitlab для оптимизаций и правильные настройки для управления репозиториями на раннерах радикально меняют скорость delivery. Объясняем, почему переход на Docker иногда замедляет процесс, как платформенные особенности 1С влияют на пайплайны и какие стратегии позволяют устранить узкие места. Материал будет полезен тем, кто хочет понять реальную стоимость ручного деплоя и сравнить ее с возможностями правильно настроенной автоматизации.

04.03.2026    1434    konst1231    0    

6

DevOps и автоматизация разработки EDT Программист 1С 8.3 Бесплатно (free)

Входные данные - конфигурация 1С в формате EDT, для системы контроля версий используется Git, две базы - рабочая и тестовая. Задача: коммит в ветку должен автоматически обновлять базу. Без ручного запуска конфигуратора, без «сохрани CF и скопируй на сервер». Инструмент - GitHub Actions + PowerShell-скрипты на сервере. Платформа 8.3.27.

27.02.2026    2160    BiLBelarus    2    

11
Для отправки сообщения требуется регистрация/авторизация