DevOps для 1С: сборка, тесты и выкладка конфигураций без ручной возни

DevOps в 1С — это набор практик, при которых изменения конфигурации хранятся в Git, проверяются автоматически и попадают в рабочую базу скриптом, а не руками из Конфигуратора. Минимальный набор: репозиторий с исходниками, сервер сборки (Jenkins или GitLab CI), автотесты и скрипт обновления базы через командную строку 1cv8.

Зачем это нужно, видно по простому случаю. Три программиста правят одну конфигурацию, тестировщик проверяет «на глаз», а релиз выкладывает администратор вечером в пятницу. Любое звено ломается тихо. Автоматизация убирает именно эти звенья.

Чем DevOps в 1С отличается от обычной разработки

Классическая схема: разработчик работает в Конфигураторе с хранилищем конфигурации, сам собирает поставку, сам тестирует, передаёт файл .cf или .cfe администратору. Всё держится на людях и договорённостях.

В DevOps-подходе меняются три вещи:

• 📁 Источник правды — Git. Конфигурация лежит в репозитории в виде файлов (модули .bsl, XML метаданных), а не бинарного .cf. Поэтому видно, что именно изменили в коммите.
• 🤖 Сборку и проверку делает сервер. Человек не нажимает «Обновить конфигурацию базы данных», это делает задание в CI.
• 🔁 Релиз повторяемый. Один и тот же скрипт выкладывает изменения на тест, предпрод и прод.

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

Какие проблемы решает автоматизация разработки

Пять типовых болей, ради которых обычно и затевают всё это:

1. Непонятно, кто и что поменял. В хранилище история есть, но сравнивать версии модулей неудобно, а ветвления почти нет. В Git — ветки, pull request, ревью.
2. Ошибки ловятся у пользователей. Синтаксическая ошибка в редком модуле всплывает через неделю. Статическая проверка в CI находит её до релиза.
3. Обновление зависит от одного человека. Только он знает порядок действий. Скрипт знает всегда.
4. Регрессия. Починили проведение документа, сломали отчёт. Сценарные тесты прогоняются на каждое изменение.
5. Долгие релизы. Ручная выкладка на 3–4 базы съедает час-два. Скрипт делает то же за несколько минут и без пропущенных шагов.

Инструменты: от скриптов до готовых платформ

Единого «продукта DevOps для 1С» нет. Пайплайн собирают из кубиков, большая часть которых — открытые проекты сообщества.

Для старта хватает связки: Git + GitLab CI + vrunner + BSL Language Server. Vanessa Automation подключаете вторым шагом, когда есть кому писать сценарии.

Базовый пайплайн для 1С: шаг за шагом

Ниже — схема из четырёх операций. Она закрывает основной цикл: разработчик правит конфигурацию → изменения попадают в Git → тестовая база обновляется сама. Пути и логины в примерах — условные.

1. Выгрузка конфигурации в файлы

Конфигурацию из базы выгружают в каталог исходников командой Конфигуратора в пакетном режиме:

"C:\Program Files\1cv8\8.3.25.1445\bin\1cv8.exe" DESIGNER ^
  /F "D:\bases\dev" /N "Автомат" /P "пароль" ^
  /DisableStartupDialogs /DumpConfigToFiles "D:\src\config" ^
  /Out "D:\logs\dump.log"

Номер каталога платформы подставьте свой. Результат — дерево файлов: у каждого объекта метаданных свой XML и модули .bsl. Если выгрузка идёт регулярно, используйте режим обновления только изменённых файлов, чтобы не перезаписывать весь каталог.

Если вы работаете в EDT, этот шаг не нужен: проект там уже хранится файлами.

2. Коммит в Git

Дальше обычный Git:

cd /d/src/config
git add -A
git commit -m "БП: исправлена заливка счетов в корректировке"
git push origin feature/fix-schet

Две привычки, которые экономят время всей команде:

• 🌿 Одна задача — одна ветка, слияние только через запрос на слияние (merge request) с ревью.
• 📝 Сообщение коммита начинается с номера задачи из трекера. Через полгода по нему найдёте и причину, и автора.

3. Резервная копия целевой базы

Перед загрузкой в тестовую или рабочую базу снимите копию. Для файловой базы это копия каталога, для серверной — выгрузка в .dt:

1cv8.exe DESIGNER /S "srv1c\test_base" /N "Автомат" /P "пароль" ^
  /DisableStartupDialogs /DumpIB "D:\backup\test_base.dt" ^
  /Out "D:\logs\backup.log"

Для больших баз .dt делается долго, поэтому на проде чаще используют бэкап СУБД (SQL Server, PostgreSQL) — это быстрее и не требует остановки пользователей так надолго. Договоритесь с администратором СУБД заранее.

4. Загрузка новой конфигурации и обновление базы

Здесь два действия: загрузить исходники в конфигурацию и применить изменения к структуре данных.

1cv8.exe DESIGNER /S "srv1c\test_base" /N "Автомат" /P "пароль" ^
  /DisableStartupDialogs /LoadConfigFromFiles "D:\src\config" ^
  /UpdateDBCfg /Out "D:\logs\load.log"

Если собираете поставку целиком, вместо файлов можно грузить готовый .cf ключом /LoadCfg, а затем /UpdateDBCfg. После запуска обязательно читайте файл из /Out: код возврата процесса не всегда показывает, что платформа отказалась загружать часть объектов.

В CI эти четыре шага оформляются как этапы задания: dump → test → backup → deploy. Падение любого этапа останавливает цепочку, и до пользователей ничего не доходит.

Как это выглядит в задании CI

Типовая схема для GitLab CI: файл .gitlab-ci.yml описывает этапы, а исполнитель (runner) стоит на машине с установленной платформой.

• 🔍 На каждый коммит в ветку задачи запускается статический анализ и проверка конфигурации. Занимает несколько минут.
• 🔀 На запрос слияния добавляется развёртывание тестовой базы из эталонного .dt и прогон сценариев.
• 🚀 На слияние в основную ветку обновляется предпроизводственная база. Выкладка на прод запускается вручную кнопкой, по согласованию с владельцем процесса.

Ручное подтверждение перед продом оставляйте даже при хорошем покрытии тестами: автоматика проверяет то, что вы в неё заложили, а не то, о чём забыли подумать.

Автоматические тесты: Vanessa Automation и что ещё есть

Без тестов пайплайн просто быстрее выкладывает баги. Поэтому следующий слой — автопроверки, от дешёвых к дорогим.

Статический анализ. BSL Language Server читает модули и ругается на неиспользуемые переменные, слишком сложные процедуры, пустые Попытка…Исключение, забытые Сообщить в отладочных вставках. Запускается за секунды, не требует базы. Ставьте первым.

Синтаксический контроль платформой. Команда Конфигуратора /CheckConfig с нужными флагами проверяет конфигурацию так же, как пункт меню проверки. Полный набор ключей смотрите в справке по пакетному режиму вашей версии платформы.

Модульные тесты (YAxUnit). Проверяют отдельные функции: расчёт скидки, разбор строки, формирование номера. Хорошо подходят для общих модулей без интерфейса.

Сценарные тесты (Vanessa Automation). Имитируют работу пользователя: открыть форму, заполнить поля, провести документ , проверить результат. Сценарии пишутся на Gherkin, близком к обычному русскому:

Сценарий: Проведение поступления товаров
  Дано Я открываю навигационную ссылку "e1cib/list/Документ.ПоступлениеТоваровУслуг"
  Когда В панели действий я нажимаю на кнопку "Создать"
  Тогда открылось окно "Поступление товаров и услуг (создание)"

Тесты Vanessa запускаются на тестовой базе с подготовленными данными. Заведите отдельную «эталонную» базу и разворачивайте её из .dt перед каждым прогоном, иначе результат зависит от того, что туда нагнали вчера.

Что с чем сочетать, зависит от ресурсов:

• Один программист: статический анализ + 5–10 сценариев на самые денежные операции (проведение, оплата, выгрузка отчётности).
• Команда 3–5 человек: плюс модульные тесты на общую логику и обязательный прогон перед слиянием.
• Крупная конфигурация: тесты по ночам на копии боевой базы и отчёт в чат.

Распространённые ошибки при внедрении

• ❌ Пытаются автоматизировать хаос. Если нет договорённости о ветках и ревью, скрипты закрепят беспорядок.
• ❌ Один огромный тест на всё. Он падает по десяти причинам и никто не разбирается. Лучше десять коротких сценариев.
• ❌ Тесты на живой базе. Прогон Vanessa на рабочей базе создаёт реальные документы. Только отдельная копия.
• ❌ Секреты в репозитории. Логины и пароли храните в переменных CI, а не в .bat под Git.
• ❌ Версия платформы на сборщике не совпадает с боевой. Выгрузка на другой версии даёт другой формат и «лишние» изменения в коммитах. Фиксируйте версию в описании задания.
• ❌ Игнорируют лог. Платформа может вернуть успешный код при частично неудачной загрузке. Парсите файл /Out.

DevOps для облачных решений и сервиса 1С:Fresh

В облаке картина другая: доступа к Конфигуратору и серверу кластера у вас, как правило, нет. Выкладка обновлений типовой конфигурации идёт силами владельца сервиса, а вы управляете только своими доработками.

Что реально работает:

• 🧩 Расширения. Доработки оформляются расширением конфигурации (.cfe). Его можно хранить в Git, собирать и проверять в CI на собственном тестовом стенде, а подключать к сервису в порядке, который допускает оператор.
• 🧪 Локальный стенд. Тесты гоняйте на своей копии базы с той же версией конфигурации, а в сервис отправляйте уже проверенное.
• 📋 Требования оператора. Состав допустимых изменений и порядок подключения расширений определяет провайдер сервиса. Уточняйте их до начала работ.

Для облачной виртуальной машины (аренда сервера под своё приложение) ограничений нет: там тот же пайплайн, что и на своём железе, нужен только сетевой доступ для агента CI.

Когда DevOps в 1С не нужен

Честный раздел, которого обычно нет в обзорах. Откажитесь или отложите внедрение, если:

• ⏸ Конфигурация типовая, без доработок. Обновление делается штатным механизмом, а автоматизировать нечего.
• ⏸ Изменения случаются раз в квартал. Затраты на настройку не вернутся.
• ⏸ Нет человека, который будет поддерживать скрипты. Заброшенный пайплайн хуже ручного процесса: никто не знает, почему он падает.

Если сомневаетесь, начните с малого: репозиторий с исходниками и один скрипт выгрузки. Через месяц станет ясно, нужно ли двигаться дальше.

Частые вопросы