Конвейер 1С: от задачи в GitSell до проверенной печатной формы

Конвейер 1С: от задачи в GitSell до проверенной печатной формы

Видео-презентация: смотреть на Rutube

Подробное техническое описание конвейера: как устроен GitSell Pipeline для разработки 1С.

В этой статье показываю один практический кейс: пользователь ставит задачу на печатную форму в GitSell, а конвейер сам создает репозиторий, поднимает песочницу 1С, запускает AI-агентов, собирает EPF, проверяет результат через bridge и публикует артефакт в релиз.

Это не история про "нейросеть написала код". Для 1С этого мало. Важны версия конфигурации, метаданные, сборка, тестовая база, проверка в runtime и доказательства, что результат действительно сформировался.

Демонстрационный кейс

Для видео выбран понятный пример: внешняя печатная форма для документа Заказ клиента в УНФ.

Задача формулируется так:

Кейс удобен для демонстрации, потому что в нем есть все основные элементы реальной 1С-разработки:

• работа с объектом конфигурации и табличной частью документа;
• внешний артефакт .epf;
• макет печатной формы;
• интеграция с внешним API;
• обработка нештатной ситуации;
• машинная проверка результата без длинного UI-сценария.

Как выглядит маршрут задачи

Упрощенный маршрут одной задачи:

GitSell является пользовательской поверхностью: там создается проект, выбирается тип работы, конфигурация и описание задачи. Дальше задача уходит в Pipeline API.

Pipeline создает рабочий репозиторий в Gitea. В нем появляется стандартная структура:

src хранит XML-исходники 1С, dist - собранные EPF/ERF/CFE, tests - проверочные сценарии, docs/timeline.md - короткую историю выполнения. Это важно: результат не остается в виде случайного файла, а становится воспроизводимым репозиторием.

Зачем нужна песочница 1С

Для каждой задачи конвейер создает отдельную серверную песочницу 1С из заранее подготовленного шаблона демобазы. В нашем случае это шаблон УНФ нужной версии.

Песочница нужна, чтобы:

• проверять результат на реальной конфигурации;
• не портить общую демобазу;
• отключать регламентные задания;
• ставить bridge-расширение;
• изолировать параллельные задачи;
• удалять временную базу после TTL или очистки проекта.

Если bridge не установлен или не отвечает, конвейер должен блокироваться. Bridge - не факультативная проверка, а критический элемент runtime-валидации.

Почему bridge-first

Открывать 1С-клиент и кликать по интерфейсу можно, но это дорого и хрупко. Поэтому порядок проверок такой:

1. Проверить метаданные и доступность инфраструктуры.
2. Собрать артефакт.
3. Проверить результат через CodexTestBridge.
4. Сохранить MXL/HTML/TXT/render evidence.
5. Делать короткий Playwright/UI-снимок только если без визуального слоя нельзя.

Для печатных форм и отчетов скриншота недостаточно. Нужно получить машинно-читаемый результат: MXL, HTML или TXT, а затем проверить, что в нем есть нужные колонки, заголовки, суммы и тестовые данные.

В демонстрационном кейсе bridge должен подтвердить, что печатная форма сформировалась и в результате есть:

• заголовок формы;
• номер и дата документа;
• контрагент;
• колонки RUB / USD / EUR;
• сведения о курсах;
• строки табличной части.

Что делает AI-агент

AI-агент в таком процессе не является единственной точкой доверия. Он получает подготовленный worker request:

• описание задачи;
• выбранную конфигурацию и версию;
• путь к репозиторию;
• доступные skills и MCP;
• правила проверки;
• контекст research-стадии;
• требования к JSON-результату.

Dev-agent вносит изменения в репозиторий, добавляет исходники, тесты и первичное evidence. После этого независимые стадии сборки и review перепроверяют результат.

Такой подход защищает от типичной ошибки: агент уверенно сообщает "готово", но код не собирается или не запускается в нужной базе. В конвейере "готово" означает не текстовый ответ, а проверяемый след: исходники, собранный артефакт, render evidence и review.

Что показывается в видео

В видео я прохожу технический маршрут задачи:

• создание проекта и запуска в GitSell;
• состояние run в Pipeline web panel;
• репозиторий задачи в Gitea;
• структуру исходников и тестов;
• временные dev/review контейнеры в Proxmox;
• сервер 1С и sandbox-базу;
• bridge-проверку печатной формы;
• финальный release с артефактом.

Видео доступно здесь: https://rutube.ru/video/76497327c1238545b6c75d74ed6450c9/

Что получает пользователь

На выходе пользователь получает не просто файл .epf. Он получает результат, который прошел маршрут:

В релизе остаются:

• готовый EPF;
• исходники;
• краткое описание задачи;
• timeline выполнения;
• validation report;
• evidence формирования результата.

Это особенно важно для 1С, где большая часть ошибок проявляется не в тексте модуля, а при сборке, загрузке, открытии формы или формировании табличного документа.

Скрин результата

Ниже пример печатной формы, сформированной в демонстрационном запуске:

На скрине видны заголовок формы, дата курса ЦБ РФ, курсы USD/EUR и табличная часть с колонками Цена, руб., Цена, USD, Цена, EUR.

Стенд тестирования

Приложенная печатная форма тестировалась на следующем стенде:

• конфигурация: Управление нашей фирмой, редакция 3.0;
• релиз конфигурации: 3.0.13.238;
• платформа 1С:Предприятие: 8.5.1.1150.

Файл результата

К статье приложен EPF, полученный в демонстрационном запуске:

• pechatnaya-forma-zakaz-klienta-v-valyutah.epf;
• размер: 12 281 байт;
• SHA-256: 8AC9795E4FDFCA6B9926F911888A008E41B5645952EF6D94E751E68F5A8E99BC.

Это именно результат работы конвейера для кейса с печатной формой заказа клиента в валютах.

Главный вывод

AI в 1С-разработке полезен не тогда, когда он просто генерирует код, а когда встроен в инженерный процесс.

Конвейер добавляет вокруг агента обязательные элементы:

• явную версию конфигурации;
• метаданные через MCP;
• изолированную песочницу;
• сборку артефакта;
• bridge-first runtime-проверки;
• evidence;
• review;
• релиз в Gitea.

Именно это превращает "агент что-то написал" в "задача прошла проверяемый производственный маршрут".