Содержание:

1. Что такое CI-CD и зачем это нужно в 1С

2. Компоненты автоматизированного конвейера для 1С

3. Пример простого CI-пайплайна в GitLab CI

Разработка в системе 1С прошла долгий путь от одинокого программиста, вносящего правки напрямую в рабочую базу, до полноценной командной работы. Однако один из «рудиментов» прошлого до сих пор жив во многих компаниях — ручное тестирование и обновление. Этот процесс часто выглядит как ночной кошмар тимлида: разработчики сдают свои доработки в последний момент, тестировщик судорожно пытается проверить основной функционал, а обновление на рабочую базу превращается в рискованное мероприятие, способное парализовать работу всей компании.

К счастью, современные инженерные практики добрались и до мира 1С. Внедрение CI/CD (Continuous Integration / Continuous Delivery) позволяет превратить хаотичный и рискованный процесс релиза в предсказуемый, автоматизированный конвейер.

Что такое CI-CD и зачем это нужно в 1С

Continuous Integration (CI, Непрерывная интеграция) — это практика, при которой разработчики регулярно (в идеале, несколько раз в день) вливают свои изменения в общий репозиторий. После каждого такого слияния автоматически запускается сборка проекта и его тестирование. Главная цель CI — как можно раньше обнаружить ошибки интеграции и дефекты в коде.

Continuous Delivery (CD, Непрерывная поставка) — это логическое продолжение CI. После того как код успешно прошел все автоматические тесты, он автоматически собирается в готовый к выпуску релиз (артефакт). Этот релиз может быть автоматически развернут на тестовом стенде для ручного тестирования или даже сразу в рабочей среде (этот подвид называется Continuous Deployment).

В контексте 1С это решает сразу несколько классических проблем:

• «У меня на компьютере все работало»: CI-пайплайн запускает тесты в чистом, изолированном окружении, что исключает влияние локальных настроек разработчика.
• Конфликты слияния: Частые интеграции кода не дают веткам разработки «разъехаться» слишком далеко друг от друга, делая слияние более простым и предсказуемым.
• Человеческий фактор: Автоматика не забудет запустить важный тест или проверить синтаксис. Риск выпустить обновление, которое ломает критический функционал (например, расчет себестоимости или формирование регламентной отчетности), снижается в разы.
• Скорость доставки ценности: Вместо долгих релизных циклов (раз в месяц или квартал) компания может поставлять новые функции и исправления пользователям гораздо чаще, быстрее реагируя на требования бизнеса.

Компоненты автоматизированного конвейера для 1С

Чтобы построить полноценный CI-CD-пайплайн для 1С, нам понадобится несколько ключевых инструментов:

1. Система контроля версий: Git. Хотя «Хранилище конфигурации 1С» все еще широко используется, для современных практик разработки Git является стандартом де-факто. Он обеспечивает гибкую работу с ветками, а для синхронизации с форматом 1С существуют утилиты вроде gitsync.

2. CI/CD-сервер: Jenkins или GitLab CI. Это «мозг» всей системы. Он отслеживает изменения в Git-репозитории и оркестрирует все шаги конвейера: сборку, тестирование, развертывание.

• Jenkins — мощный и гибкий open-source инструмент с огромным количеством плагинов. Требует чуть больше усилий для начальной настройки.
• GitLab CI — встроен в платформу GitLab. Настройка конвейера происходит через простой YAML-файл (.gitlab-ci.yml) прямо в репозитории, что делает его очень удобным и наглядным.

3. Фреймворк для тестирования: Vanessa-Automation (ADD). Это абсолютный стандарт для автоматизированного тестирования в 1С. Он позволяет писать тесты на человекочитаемом языке Gherkin (в синтаксисе Дано / Когда / Тогда), имитируя действия пользователя: открытие форм, нажатие кнопок, ввод данных и проверку результатов.

Пример простого CI-пайплайна в GitLab CI

Представим типичный сценарий работы. Разработчик закончил свою задачу в отдельной ветке и создает Merge Request (запрос на слияние) в основную ветку develop. В этот момент GitLab CI автоматически запускает конвейер, который может состоять из следующих шагов:

Шаг 1: Сборка конфигурации

• CI-сервер получает исходный код конфигурации из Git (выгруженный в текстовом формате).
• Создает пустую временную информационную базу.
• С помощью командной строки 1С загружает конфигурацию из исходников во временную базу.
  “C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe” DESIGNER /F “path\to\temp_ib” /LoadConfigFromFiles “path\to\sources”

Шаг 2: Проверка синтаксиса

• В той же временной базе запускается полная синтаксическая проверка конфигурации с выводом результата в лог. Это позволяет отловить самые базовые ошибки.

Шаг 3: Запуск дымовых тестов (smoke tests)

• Запускается минимальный набор самых критичных тестов с помощью Vanessa-Automation. Например, проверка открытия основных разделов и форм. Это быстрая проверка на то, что конфигурация в принципе работоспособна.

Шаг 4: Запуск полного набора регрессионных тестов

• Если дымовые тесты прошли успешно, запускается полный набор сценариев Vanessa-Automation, которые проверяют весь ключевой бизнес-функционал. Этот шаг может занимать от нескольких минут до часа, в зависимости от объема тестов.
  “C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe” ENTERPRISE /F “path\to\temp_ib” /Execute “path\to\vanessa\runner.epf” –test=”path\to\features” –report

Шаг 5: Публикация отчета

• Результаты прогона тестов (обычно в формате Allure Report) публикуются прямо на странице Merge Request. Разработчик и тимлид видят наглядный отчет: какие тесты прошли успешно, а какие упали, с подробными логами и скриншотами ошибок.

Если все шаги конвейера завершились успешно («зеленый пайплайн»), значит, изменения можно безопасно вливать в основную ветку. Если хотя бы один шаг провалился («красный пайплайн»), Merge Request блокируется до исправления ошибок.

Вывод:

Внедрение CI/CD в разработку на платформе 1С — это не погоня за модой, а зрелый инженерный подход. Он требует первоначальных инвестиций времени в настройку инструментов и написание тестов, но окупается сторицей. Автоматизация рутины снижает риски, повышает качество кода, ускоряет доставку обновлений и, что самое главное, освобождает драгоценное время разработчиков и тестировщиков для решения реальных бизнес-задач, а не для тушения «пожаров» после очередного релиза. Это переход от кустарного производства к промышленному конвейеру, где качество заложено в сам процесс.

Специалист компании ООО “Кодерлайн”,

Радченко Степан