Проверка расширения 1С перед обновлением: ext_vs_release

Расширение может остаться прежним, а метод поставщика, который оно перехватывает, — измениться в новом релизе. Поэтому сравнение двух версий самого .cfe отвечает только на часть вопросов при обновлении. Нужна ещё проверка того, что изменилось в основной конфигурации вокруг доработки.

В Профессиональной редакции MCP-1C с v2.42.0 для этого есть действие ext_vs_release инструмента code_review. Оно показывает изменения нового релиза, затрагивающие объекты расширения, включая модули и поддерживаемые элементы форм. Это способ подготовить список мест для проверки перед обновлением. Состав и параметры доступны в справочнике Профессиональной редакции, версия появления — в истории изменений.

В статье:

• Какие исходники подготовить
• Как вызвать сравнение
• Зачем нужна текущая база
• Как разбирать отчёт и отказы
• Что делать перед переносом

Какие исходники подготовить

Сначала определите три источника: действующее расширение, новый релиз поставщика и текущую конфигурацию, с которой работает расширение. Новый релиз должен относиться к той же поставке, что и текущая база. Названия каталогов вроде old и new ничего не подтверждают — сохраните версии и происхождение выгрузок рядом с результатом проверки.

Для расширения в виде каталога ibcmd не нужен. Для файла .cfe серверу необходима утилита ibcmd платформы 1С: она преобразует файл в выгрузку для сравнения. Если подходящей утилиты нет, используйте выгрузку расширения в файлы из базы, где оно установлено.

Пути открывает машина сервера MCP-1C. Каталоги сравнения должны находиться внутри зарегистрированного каталога выгрузки или его подкаталогов; произвольный путь с компьютера клиента не подходит. Это ограничение описано в разделе «Пути к выгрузкам». Подготовьте отдельные подкаталоги, чтобы не затереть текущие исходники новой поставкой.

Как вызвать сравнение

Пример аргументов code_review, когда все три выгрузки уже доступны серверу в разрешённом дереве каталогов:

{
  "action": "ext_vs_release",
  "ext_dump": "/opt/1c/dump/ext",
  "release_dump": "/opt/1c/dump/new",
  "base_dump": "/opt/1c/dump/current",
  "format": "markdown"
}

Это условные пути. Подставьте свои каталоги, предварительно проверив, что они зарегистрированы и содержат нужные версии. markdown используется по умолчанию; также поддерживаются json и text. Для сохранения исходных фактов отчёта в своём процессе можно выбрать JSON, а для обсуждения в задаче — Markdown.

Вместо base_dump можно передать base — имя зарегистрированной базы, для которой настроена выгрузка через --dump. Если заданы оба параметра, base_dump переопределяет путь, найденный по имени базы. Действие использует файлы на диске: оно не подключается к живой информационной базе и не выбирает текущую базу по умолчанию.

Зачем нужна текущая база

Проверка целевого метода состоит из разных вопросов. Есть ли он в новом релизе? Совпадают ли его параметры с перехватом расширения? Изменилось ли тело метода по сравнению с текущей версией? Последний вопрос требует исходной точки сравнения.

Когда передана выгрузка текущей базы, инструмент дополнительно сравнивает тело целевого метода в ней с телом в новом релизе. Это помогает заметить ситуацию, когда сигнатура сохранилась, но логика поставщика изменилась и доработку нужно пересмотреть.

Без текущей выгрузки наличие метода и совпадение параметров проверяются, но тела целей перехватов &Перед, &После и &Вместо не сравниваются. Отчёт помечает непроверенные места. Поэтому отсутствие найденных изменений при неполных входных данных нельзя читать как заключение о совместимости.

Например, расширение использует &Вместо для процедуры расчёта. В новой поставке её имя и параметры прежние, но внутри добавилась обязательная проверка. Проверка сигнатуры сама по себе этого различия не раскрывает. Для анализа тела нужна корректная текущая выгрузка, а решение о переносе новой логики остаётся задачей разработчика.

Как разбирать отчёт и отказы

Разделяйте найденное отличие, непроверенный участок и ошибку подготовки данных. Это разные результаты и разные следующие действия.

• При отличии метода откройте исходники обеих версий, проверьте смысл изменения и связанные сценарии расширения.
• При непроверенном участке уточните, каких данных не хватает. Если причина в отсутствии текущей выгрузки, подготовьте её и повторите сравнение.
• При отказе чтения .cfe проверьте наличие и версию ibcmd или перейдите на XML-выгрузку установленного расширения. Отказ не означает, что расширение совместимо или несовместимо: сравнение не завершилось.
• При отказе пути проверьте регистрацию каталога. Не переносите исходники за границы разрешённого дерева ради обхода проверки.

В ignore поддерживаются только два фильтра: bsl_inline_whitespace включён по умолчанию, comments выключен. Подбирайте их под задачу и сохраняйте вместе с отчётом: иначе результаты двух запусков сложнее сопоставить. Подробный контракт параметров находится в документации ext_vs_release.

Эта проверка отличается от сравнения двух файлов расширения. Там вопрос — что поменялось между версиями .cfe. Здесь — какие изменения поставщика затрагивают существующую доработку. На обновлении могут пригодиться оба отчёта.

Что делать перед переносом

По отчёту составьте список затронутых сценариев. Если изменён перехватываемый метод проведения, проверьте проведение и отмену проведения на синтетических данных. Если затронута форма, откройте её, пройдите нужные страницы и действия под соответствующими правами. Для предварительного разбора структуры можно использовать form_view, но схема по выгрузке не исполняет код формы.

Обновление сначала выполняйте в отдельной тестовой базе по принятой в команде процедуре. Подтвердите загрузку расширения, запуск и поведение затронутых операций, затем сохраните результаты регресса рядом с версиями входных файлов и отчётом сравнения.

Успешный статический отчёт сужает область внимания. Он не заменяет запуск платформы, не доказывает отсутствие всех конфликтов и не даёт автоматического разрешения обновлять рабочую базу. Его практическая ценность — показать разработчику конкретные места, которые стоит проверить до переноса.