Рабочее место 1С на Linux через WSL. Часть 10 - Локальный CI/CD конвейер (Непрерывная интеграция)

6 сентября 2026 · infolimp.ru

Теоретическая часть

Что такое CI/CD в контексте 1С? CI/CD (Continuous Integration / Continuous Delivery) - это методология автоматизации процесса интеграции кода, его тестирования и развертывания. В экосистеме 1С классический ручной подход («сохранить в файл .cf, обновить конфигурацию вручную») часто приводит к досадным ошибкам: забытая синтаксическая ошибка в редко используемом общем модуле может «уронить» критические процессы у клиентов только в момент вызова этой процедуры. Автоматизированный конвейер при каждом коммите (пуше) разработчика в Git выполняет цепочку проверок (пайплайн):

1. Синтаксический контроль (Syntax Check) - проверка корректности программного кода.
2. Автоматическое тестирование (Unit-тесты) - запуск сценариев проверки бизнес-логики.
3. Сборка поставки и подготовка дистрибутивов для обновления рабочих баз. Опасная ловушка пакетного запуска 1С (DESIGNER) При автоматизации сборки и проверок 1С на Linux через скрипты разработчики часто вызывают Конфигуратор в пакетном режиме с ключом /DumpIB или /UpdateDBCfg. Однако пакетный запуск Конфигуратора таит в себе опаснейшую ловушку: при критических ошибках утилита выполнения DESIGNER может завершиться с кодом возврата 0 («всё хорошо»). Это классическая проблема False Success (ложный успех) в скриптах автоматизации 1С:

• Платформа сталкивается с ошибкой несовместимости, блокировкой базы или повреждением метаданных.
• Выводит сообщение об ошибке во внешний файл лога.
• Но сам процесс Linux завершается с системным кодом выхода 0.
• В результате CI/CD-система (GitLab Runner или GitHub Actions) считает шаг успешно пройденным, и дефектный код беспрепятственно уходит на продуктивный конвейер. Борьба с False Success и проект 1C:SRE-Suite Для построения по-настоящему надежного и «неубиваемого» конвейера на Linux необходимо использовать специализированные инструменты и методики. Открытый проект 1C:SRE-Suite (DevOps & Stability Suite для 1С на Linux) предлагает готовые паттерны и скрипты для обхода этой проблемы:
• Пятислойный сборочный скрипт: защита от False Success за счет обязательного сквозного парсинга файлов журналов (логов), проверки сигнатур BOM (Byte Order Mark), кодировок, lock-файлов и сверки разницы (diff) с Git.
• Headless-режим: запуск платформы 1С без виртуального кадрового буфера (без X-сервера) с корректной обработкой системных сигналов Linux.
• Изоляция сборок через RUN_ID: предотвращение конфликтов при параллельном запуске нескольких проверок на одном сервере за счет уникальных идентификаторов сессий и динамических портов.

Пошаговая инструкция

Для простоты и универсальности мы настроим пайплайн на примере локального раннера, который будет запускать проверки непосредственно в нашем Linux-окружении WSL при фиксации изменений в Git.

Шаг 1. Подготовка сборочной базы в СУБД PostgreSQL

Для проведения синтаксического контроля раннеру необходима временная («холодная») база данных, в которую будет загружаться код конфигурации из Git.

1. Создайте базу данных CI_Template в СУБД PostgreSQL: # Переключимся на пользователя postgres и создадим чистую базу данных для сборки

sudo -u postgres createdb -E UTF8 CI_Template

1. Зарегистрируйте базу в кластере 1С с помощью утилиты rac (используя навыки из Лабораторной работы №4): # Создаем информационную базу CI_Template в кластере 1С

rac ib --cluster=1541 create --name=CI_Template --dbms=PostgreSQL --db-server=localhost
--db-name=CI_Template --db-user=postgres --db-pwd=1111 --create-database=n

Шаг 2. Написание отказоустойчивого скрипта синтаксической проверки

Чтобы обойти ловушку False Success, мы напишем Bash-скрипт ci-syntax-check.sh, который принудительно анализирует файл лога 1С на наличие ключевых слов ошибок, даже если код завершения процесса равен 0.

1. Создайте файл скрипта в каталоге репозитория:

nano ~/ci-syntax-check.sh

1. Поместите в него следующее содержимое (с учетом особенностей обработки логов 1С): #!/bin/bash # Включаем режим немедленного выхода при ошибках системных утилит (кроме запуска 1С, который мы обработаем сами) set -u DB_NAME="CI_Template" LOG_FILE="/tmp/1c_syntax_log.txt" ERR_FILE="/tmp/1c_errors.txt" # Очищаем старые логи перед запуском

rm -f $LOG_FILE $ERR_FILE

echo "=== Запуск синтаксической проверки конфигурации в Headless-режиме ===" # Запускаем Конфигуратор 1С в пакетном режиме для синтаксического контроля всех модулей # Используем путь к платформе (измените версию на актуальную для вашего стенда) /opt/1cv8/x86_64/8.3.16.1148/1cv8 DESIGNER \

  /S "localhost\\$DB_NAME" \

/N "Администратор" /P "" \

  /CheckModules -Server -ClientRegularApplication -ThickClientOrdinaryApplication \
  /Out "$LOG_FILE" -NoTruncate

# Сохраняем реальный код возврата платформы (хотя он может быть 0 при ошибках!) EXIT_CODE=$? echo "Процесс 1С завершился с кодом: $EXIT_CODE" # Конвертируем лог-файл 1С из кодировки UTF-16LE (BOM) в стандартный UTF-8 для корректного поиска утилитой grep if [ -f "$LOG_FILE" ]; then

    iconv -f UTF-16LE -t UTF-8 "$LOG_FILE" > /tmp/1c_syntax_log_utf8.txt
else

echo "Критическая ошибка: Файл лога не был создан!"

    exit 1
fi

# Ищем маркеры ошибок в лог-файле с помощью ripgrep или grep grep -E "Ошибка|Error|Конфигурация не обновлена|Синтаксический контроль завершился с ошибками" /tmp/1c_syntax_log_utf8.txt > $ERR_FILE if [ -s "$ERR_FILE" ]; then echo "=== ОБНАРУЖЕНЫ СИНТАКСИЧЕСКИЕ ОШИБКИ ==="

    cat $ERR_FILE
    echo "========================================"

exit 1 # Возвращаем ошибку конвейеру, предотвращая дефектную сборку fi if [ $EXIT_CODE -ne 0 ]; then echo "Критическая системная ошибка выполнения Конфигуратора 1С!"

    exit $EXIT_CODE
fi

echo "Синтаксический контроль пройден успешно!" exit 0

1. Сделайте скрипт исполняемым:

chmod +x ~/ci-syntax-check.sh

Шаг 3. Конфигурирование декларативного пайплайна

Если вы используете GitHub Actions или GitLab CI/CD, конфигурация пайплайна описывается в специальном декларативном файле YAML в корне вашего Git-репозитория. Для GitLab CI/CD создайте файл .gitlab-ci.yml: stages:

  - test
syntax_check_job:
  stage: test
  tags:

- 1c-linux-runner # Раннер, запущенный на нашем Linux-хосте

  variables:

RUN_ID: $CI_PIPELINE_ID # Изолируем контекст сборки с помощью уникального ID

  script:

# 1. Загружаем свежие исходники из Git в базу сборки

    - /opt/1cv8/x86_64/8.3.16.1148/1cv8 DESIGNER /S "localhost\CI_Template"
/LoadConfigFromFiles $CI_PROJECT_DIR/src

# 2. Запускаем наш защищенный скрипт контроля

    - ~/ci-syntax-check.sh

Практическое задание

Цель работы: Настроить и протестировать локальный сборочный конвейер 1С на Linux с автоматической фильтрацией False Success. Задание:

• ☐ Подготовьте сборочную базу в WSL и настройте скрипт ci-syntax-check.sh, как описано в инструкции.
• ☐ В среде разработки 1С:EDT (из Лабораторной работы №7) добавьте в любой модуль (например, ОбщегоНазначения) заведомо ошибочный синтаксический код, нарушающий правила языка (например, пропустите закрывающий тег КонецПроцедуры или напишите несуществующий оператор).
• ☐ Сделайте коммит изменений в Git.
• ☐ Запустите скрипт проверки вручную в терминале Linux: ~/ci-syntax-check.sh
• ☐ Проверка результата (Часть 1): Убедитесь, что скрипт обнаружил синтаксическую ошибку, вывел её текст в терминал и завершился с кодом ошибки 1 (пайплайн CI/CD упал), несмотря на то, что сам процесс 1cv8 мог вернуть код 0.
• ☐ Исправьте ошибку в коде, повторно выполните коммит и запустите проверку.
• ☐ Проверка результата (Часть 2): Убедитесь, что синтаксический контроль завершился успешно и скрипт вернул код 0.

Проверьте себя

1. В чем заключается ловушка False Success (ложный успех) при запуске утилиты DESIGNER 1С в Linux-скриптах автоматизации? Ответ: При возникновении некоторых критических или синтаксических ошибок в пакетном режиме, процесс выполнения Конфигуратора завершается со стандартным кодом выхода 0 (что трактуется операционной системой как успешное завершение). Из-за этого сборочные системы CI/CD пропускают дефектный код дальше по конвейеру.
2. Каким образом скрипт синтаксической проверки обходит проблему ложного кода завершения платформы 1С? Ответ: Скрипт принудительно сохраняет вывод платформы в файл лога и осуществляет его текстовый анализ (парсинг) с помощью утилиты grep на наличие сигнатур и ключевых слов ошибок (таких как "Ошибка", "Error", "Синтаксический контроль завершился с ошибками"). При их обнаружении скрипт принудительно возвращает ненулевой код выхода (например, exit 1), прерывая сборку.
3. Зачем перед обработкой файла вывода /Out пакетного режима 1С в Linux-скрипте требуется выполнять утилиту iconv? Ответ: Платформа 1С:Предприятие записывает файл вывода (лог) в кодировке UTF-16LE с сигнатурой BOM (Byte Order Mark). Стандартные консольные утилиты Linux (такие как grep, awk, sed) ориентированы на работу с кодировкой UTF-8 и не могут корректно распознавать текст в UTF-16LE. Утилита iconv перекодирует файл в читаемый формат UTF-8 перед анализом.
4. Для чего используется переменная RUN_ID (например, ID пайплайна в CI/CD) в сборочных конвейерах 1С на Linux? Ответ: Переменная RUN_ID используется для изоляции контекстов параллельных сборок на одном и том же физическом сервере (сборочном раннере). С её помощью динамически генерируются уникальные имена временных баз данных, файлы блокировок и логов, исключая конфликты между одновременно запущенными задачами разных разработчиков.
5. Какой сетевой режим рекомендуется использовать для Docker-контейнеров с сервером 1С при развертывании CI/CD-раннеров для обеспечения лицензионной стабильности? Ответ: Рекомендуется использовать сетевой режим --net=host (хостовая сеть). Это позволяет контейнеру сервера 1С беспрепятственно видеть сетевые ключи защиты (HASP) в локальной сети и использовать сетевые параметры хост-машины, предотвращая частые сбросы программных лицензий 1С при изменении виртуального сетевого окружения Docker.