Пилот на реальных задачах¶

Две недели (2026-10-04 — 2026-10-18) ОТК работал в CI настоящего проекта рядом с проверкой Конфигуратором: на каждой проверке — вердикт ОТК, затем синтаксический контроль /CheckModules и сверка находок. Цель — ответить на три вопроса: бывает ли «ОТК пропустил — Конфигуратор нашёл», сколько ложных ошибок и сколько это стоит по времени. Здесь — выжимка: цифры, что пропускалось и ложно срабатывало и что исправлено. Дозамер возможностей, появившихся после пилота, — в конце страницы.

Критерии и итог¶

Критерии выхода из пилота заданы заранее: ни одного случая «ОТК зелёный — Конфигуратор красный» по классам ошибок, которые ОТК заявляет закрытыми, и медиана прогона ≤ 10 минут.

Критерий	Результат
Пропуски «ОТК зелёный — Конфигуратор красный»	0 из 105 проверок расширения
Медиана прогона ≤ 10 минут	53 с на расширение; изменённое в отраслевой конфигурации целиком — 2 мин
Ложные ошибки (вердикт «не отправлять» без дефекта в коде)	2 из 105 — сбой записи служебного файла дымового теста форм, исправлен на 10-й день; после — 0

Оговорка, без которой цифры читаются неверно: в изменения за пилот не попало ни одного реального дефекта, который поймал бы Конфигуратор. «0 пропусков» значит, что на чистом коде ОТК ни разу не разошёлся с Конфигуратором, а не что он испытан настоящей ошибкой в CI. Ошибкой ОТК испытывают иначе: каталогом контрольных дефектов (заведомые ошибки каждого класса, паритет с Конфигуратором — vs-designer.md) и прогонами на больших типовых, где находки разбирались вручную. Пропуски и ложные срабатывания, найденные за пилот, пришли именно оттуда.

Что проверялось¶

Источник	Что это	Объём
CI проекта-расширения	`otk gate --all` по расширению на двух отраслевых конфигурациях, затем `/CheckModules` и сверка	66 прогонов, 105 проверок
CI отраслевой конфигурации целиком (≈ 12 тыс. файлов выгрузки)	`gate` на каждый PR; полная проверка Конфигуратором — по расписанию, затем по метке и вручную	24 прогона: 12 полных проверок, 12 — `gate` на PR
Статика целиком на типовых (`gate --dir`, без git и ИБ)	1С:ERP 2.5 (25 414 модулей) и 1С:УНФ 3.0 (15 352 модуля), каждая находка разобрана	6 прогонов с исправлениями между ними
Каталог контрольных дефектов (`otk controls --parity`)	заведомые дефекты по классам	10 и 9 дефектов на двух конфигурациях

Полная проверка отраслевой конфигурации Конфигуратором — 9 успешных прогонов, расхождений с базовой линией нет (ошибки самой типовой приняты базовой линией, см. CI); отрицательный контроль — заведомая порча, которую проверка обязана увидеть, — срабатывал каждый раз.

Пропуски¶

В CI — 0. Вне CI найдены и исправлены три пропуска в классах, заявленных закрытыми, — каждый мог дать «зелёный» при «красном»:

Что пропускалось	Как нашли
сборка копии ИБ шла по редакции последнего плана, а не по проверяемому коммиту — пробы могли идти не по тому коду	разбор журнала сборки
код под `#Иначе` после `#Если ВебКлиент` и под `Не ВебКлиент` не проверялся на методы платформы	статика на УНФ целиком
выгрузка в корне репозитория: пути модулей обрезались, изменения не попадали в план	проект с выгрузкой в корне

Ложные срабатывания¶

Что	Где	Исправлено
сбой записи служебного файла дымового теста форм — вердикт «не отправлять» без дефекта	CI расширения, 2 прогона	да; после — 0
«Возможно ошибочное свойство» на новую ссылку расширения на объект основной конфигурации	сквозная проверка расширения	да
5 ложных находок о методах платформы на УНФ (`Новый` с переносом строки, код мобильной платформы, конструкторы вне справки); повтор одной находки до 34 раз	УНФ целиком	да
правило BSL LS о стандарте (`ServerSideExportFormMethod`) выдавалось как ошибка	ERP целиком	убрано из встроенного набора
ошибки BSL LS на переносе строки после точки и на локальной `ЭтотОбъект` — все ошибки BSL LS на типовых	УНФ — 29, ERP — 66	да
41 предупреждение BSL LS в формах и командах	CI расширения	да

После исправлений на ERP целиком — 0 ложных: все 123 находки о ссылках на метаданные — настоящие висячие ссылки. На УНФ — 100 находок, все настоящие (висячие ссылки, рассинхрон сигнатур, обработчики).

Время¶

Что	Медиана	Максимум
ОТК на расширение (`gate --all`, всё расширение)	53 с	714 с ¹
`/CheckModules` на то же расширение	5,3 с	24,7 с
`gate` на PR в отраслевой конфигурации (изменённый модуль, статика + пробы)	1 мин 53 с	—
Полная проверка той же конфигурации Конфигуратором (задача CI целиком)	12 мин	21 мин
Статика целиком (`gate --dir`, без ИБ): УНФ / ERP	13 / 27 мин	—
то же с BSL LS: УНФ / ERP	22 / 49 мин	—

¹ Первый прогон после смены выгрузки основной конфигурации: построение индекса, дальше — из кеша.

На маленьком расширении ОТК медленнее Конфигуратора (53 с против 5 с): он делает то, чего компиляция не видит, — пробы исполнения, запросы в базе, дымовой тест форм, доступность методов по контексту. Выигрыш по времени — на больших конфигурациях: отраслевую целиком Конфигуратор проверяет 10–12 минут, ОТК изменённое — за 2.

Выводы¶

Критерии выполнены, и CI проекта переведён на вердикт ОТК; проверка всех модулей Конфигуратором осталась страховкой — по метке PR, при слиянии и в релизе (CI).
Настоящую проверку ошибкой дают каталог контрольных дефектов и большие типовые, а не «0 пропусков» на чистых изменениях: каталог прогоняется на каждом изменении проверок.
Ручная работа в редакторе (хуки VS Code и pre-push) за пилот почти не шла, а её прогоны не оставляли журнала — эти данные потеряны. Следующему пилоту нужен журнал срабатываний: строка на прогон (время, режим, вердикт, длительность).

Дозамер после пилота¶

После пилота появились проверка проекта 1C:EDT в копии ИБ без экспорта, проверка доработок относительно поставщика (--vendor) и второй анализатор BSL (bsl-analyzer). Их замеры — той же меркой: время, ложные, пропуски. Замеры 2026-10-23, по одному стенду на возможность; каждый нашёл дефекты самого ОТК — они исправлены до публикации, ниже — цифры после исправлений и что было до них.

Проект 1C:EDT без экспорта (1С:ERP 2.5, 90 тыс. файлов проекта)¶

Копия проекта ERP в EDT, пять изменённых модулей: три контрольных дефекта (необъявленная переменная в серверном общем модуле, опечатка в поле запроса модуля менеджера, вызов несуществующей процедуры в клиентском обработчике формы) и две чистые правки (модуль объекта, модуль формы). Без git: gate --dir <стало> --base-dir <было>, копия ИБ — чистая ERP той же версии, платформа 8.3.27.

	Прогон 1: все пять правок	Прогон 2: без дефекта общего модуля
Дефекты пойманы	3 из 3	2 из 2
Шаги, поймавшие дефекты	проба COM (переменная), разбор запроса платформой, статика (`platform-api`)	разбор запроса, статика
Ложные ошибки	0	2 — дымовой тест форм на пустой базе ¹
Ложные предупреждения	1 — BSL LS по неизменённому коду ²	1 — то же
Время всего / план без git / пробы	16 мин 40 с / 8 мин / 7,6 мин	10 мин / 2,5 мин / 6,5 мин

Экспорт EDT не понадобился ни разу: модули загружены частичной загрузкой (сборка 93–106 с, из них выгрузка ИБ 21–22 с), описания для расширенной проверки — частичной выгрузкой копии (111 объектов, 21–25 с). Экспорт того же проекта — 35 минут (edt.md). Дефект общего модуля, который используется при запуске, не даёт стартовать тонкому клиенту: клиентские пробы и дымовой тест в прогоне 1 — «не проверено» с причиной, ошибка — в сводке. Сравнение каталогов без git на проекте такого размера — заметная часть времени (содержимое 90 тыс. файлов; с git план строится по git diff за секунды).

¹ Формы документа и справочника на ERP без начального заполнения не открываются («Не удалось заполнить поле "Организация"», «Преобразование значения к типу Булево»): для дымового теста нужна заполненная копия, иначе — [smoke] severity = "warning" (checks.md). ² Замечание BSL LS о сигнатуре обработчика в неизменённой процедуре изменённого модуля показано как новое; вердикт не меняет, разбирается.

Доработки относительно поставщика (`--vendor`)¶

Демо-конфигурация БСП 3.1.12 на поддержке с разрешёнными изменениями, три доработанных модуля; в одном из них правка сломала структуру Если … КонецЕсли — настоящая синтаксическая ошибка. Основная конфигурация ИБ при этом не была применена к БД, как бывает после правки в Конфигураторе. Платформа 8.5.1.

Шаг	Время
состояние поддержки, `/CompareCfg` (полный отчёт), выгрузка ИБ	11 + 11 + 11 с
`/UpdateDBCfg` копии (основная конфигурация не была применена)	11 с
весь `gate` (статика, пробы COM и YAxUnit, дымовой тест, расширенная проверка)	2,5 мин

Ошибку ловят проба COM и расширенная проверка Конфигуратором, без BSL LS. До исправлений тот же прогон без BSL LS давал «можно отправлять»: пробы исполнялись по конфигурации БД, то есть по прежнему коду (теперь ОТК сверяет КонфигурацияИзменена(): копию обновляет, в рабочей базе пробы — «не проверено» с причиной), а расширенная проверка теряла ошибку разбора и, на платформе 8.5, не загружала формы из выгрузки ИБ (версия формата 2.22 против 2.20). Это единственный найденный за пилот и дозамер случай «ОТК зелёный — Конфигуратор красный».

bsl-analyzer¶

Статика целиком (gate --dir --static-only --analyzer bsl-analyzer, bsl-analyzer 0.3.2) — та же постановка, что в пилоте для BSL LS: каждая находка — по всей типовой, без «было».

	1С:УНФ 3.0 (15 352 модуля)	1С:ERP 2.5 (25 414 модулей)
Время: статика ОТК / с BSL LS (пилот) / с bsl-analyzer	13 / 22 / 21 мин	27 / 49 / 47 мин
Ошибки статики ОТК (ссылки на метаданные, сигнатуры, обработчики)	100 — все настоящие	123 — все настоящие
Ошибки bsl-analyzer	8 — все ложные ¹, исправлено; после — 0	0
Предупреждения bsl-analyzer	18 741	31 132

¹ ЭтотОбъект = … в общих модулях и модулях менеджеров, где это локальная переменная, — тот же класс, что пилот нашёл у BSL LS; фильтр BSL LS к bsl-analyzer не применялся.

Предупреждения на всей типовой — не мера ложных: в gate по правке показываются только новые замечания относительно «было», и вердикт они не меняют. Самые частые (УНФ / ERP) — лишние запятые (2 744 / 5 296), несовпадение типов (2 578 / 4 632), пропущенный обязательный параметр (1 461 / 4 218), неразрешённое поле (3 350 / 2 704). По времени bsl-analyzer на всей типовой — как BSL LS; памяти ERP целиком с ним требует много: на машине с 16 ГБ прогон уместился только без других тяжёлых программ. Первый прогон на УНФ упал до анализа: список всех модулей не помещался в командную строку Windows; исправлено — при длинном списке анализируется всё дерево.