Можно внедрять поэтапно?
Да. Обычно сначала приводим репозиторий и сборку CF, затем добавляем deploy в тестовую базу, SonarQube, smoke-тесты, Allure и full-сценарии.
На главную
DevOps для 1С: CI/CD, GitLab, SonarQube, Vanessa Automation и Allure
Помогаю 1С-командам перейти от ручной сборки, ручного обновления тестовой базы и разрозненных проверок к управляемому pipeline: Git, анализ BSL-кода, сборка CF, deploy, smoke/full тесты и понятные отчёты.
Что входит в DevOps для 1С
Цель не в том, чтобы просто добавить GitLab CI к 1С, а в том, чтобы у команды появился повторяемый путь изменения: от выгрузки кода до тестовой базы и отчёта о качестве.
GitSync и структура репозитория для исходников 1С, расширений, тестов и CI-файлов
GitLab CI pipeline для анализа, сборки CF, deploy и автоматических проверок
Сборка CF из `src/cf`, работа с расширениями и отдельными тестовыми базами
SonarQube-анализ изменённых `.bsl` и `.os` файлов, quality gates и группы анализа
Vanessa Automation, smoke/full сценарии, screenshots, JUnit и Allure results
Публикация Allure-отчётов, Telegram-уведомления и прозрачная история pipeline
Когда это нужно 1С-команде
DevOps-контур особенно полезен в крупных 1С ERP и enterprise-проектах, где релизы затрагивают производство, склад, закупки, документы, регистры, интеграции и много пользователей.
- • CF собирается руками и зависит от конкретного компьютера или администратора
- • Тестовая база обновляется нерегулярно, разными способами и без единого журнала
- • Хранилище 1С, Git, тесты и отчёты живут отдельно друг от друга
- • Ошибки BSL-кода и сценариев обнаруживаются поздно, ближе к приёмке или релизу
- • Нужно внедрить smoke/full проверки без остановки текущей разработки
- • Команде нужен понятный pipeline вместо инструкций в чатах и ручных checklist
Как может выглядеть pipeline
Конкретная схема зависит от текущей инфраструктуры 1С, GitLab, runner-ов, тестовых баз и требований безопасности. Обычно контур разделяется на понятные этапы, чтобы команда видела, где именно возникла проблема.
- • Уведомление о commit и запуск pipeline
- • Статический анализ изменённых BSL/OS-файлов в SonarQube
- • Сборка CF на Windows runner из текущего состояния репозитория
- • Deploy CF в отдельную тестовую базу 1С с контролем параметров подключения
- • Запуск Vanessa Automation в Docker-окружении с платформой 1С
- • Публикация Allure-отчётов в GitLab Pages и отправка ссылок в Telegram
Что получает бизнес и команда
Для бизнеса это снижает риск релизов и делает изменения в 1С более управляемыми. Для команды это даёт быструю обратную связь, общие отчёты и меньше ручной рутины вокруг поставки изменений.
- • Меньше ручных операций при сборке и поставке изменений в тестовую базу
- • Быстрее видно, что сломалось: качество кода, сборка, deploy или сценарный тест
- • Результаты проверок доступны всей команде, а не одному человеку на рабочем месте
- • Появляется база для регламентов релизов, quality gates и развития тестового покрытия
- • Инфраструктура 1С становится частью нормального engineering process
Вопросы перед стартом
Нужна ли отдельная тестовая база?
Да, для CI/CD это правильная практика. Тестовая база должна быть отдельной и подготовленной для автоматического обновления, чтобы pipeline не ломал рабочий контур.
Можно анализировать не всю ERP?
Да. Для больших конфигураций удобно анализировать только изменённые `.bsl` и `.os` файлы, разделяя проверки по группам: бизнес-объекты, ядро, документы и регистры.
Это только для 1С ERP?
Нет. Подход применим к 1С ERP, УТ, КА, ЗУП, доработанным конфигурациям и enterprise-контурам, где есть Git, тестовые базы и потребность в управляемой поставке изменений.
Нужен понятный план по инфраструктуре, релизам или production?
Опишите текущий контур, критичные сервисы и проблему. По этому можно выбрать формат: аудит, разовая работа, сопровождение или подключение команды под объём.
Написать в Infra LAB