Развертка - выносим cf-конвертер в отдельный продукт

Пять конфигураций - от маленькой коробки до ящика на тележке

В прошлой статье я рассказал, как выгрузил типовую Бухгалтерию в XML с побайтовым совпадением, и спросил, какую конфигурацию проверить следующей.

Вы предложили несколько вариантов. Один читатель сливает релизы ERP через git и попросил проверить ERP. Другой напомнил, что свежей Бухгалтерии недостаточно: многие работают со старыми релизами и старым режимом совместимости. Еще был вопрос о проверке самого эталона - результата работы платформы.

В итоге я прогнал пять конфигураций. Нашел объекты, которые конвертер еще не поддерживал, и ошибки в методике сравнения. Ниже - результаты, исправления и то, что пока осталось за бортом.

Заодно поменялось и само устройство проекта. Выгрузка и загрузка XML оказались полезны сами по себе, без окна и редактора, поэтому я выношу этот cf-конвертер в отдельный продукт - консольную утилиту "Развертка".

Результаты на пяти конфигурациях

При выгрузке я сравниваю XML-файлы конвертера с файлами платформы. При загрузке - записи в собранном файле конфигурации. Записи отвергнутых файлов в последнюю колонку не попадают, а если отвергнут хоть один файл, файл конфигурации утилита не собирает вовсе. Поэтому целиком сейчас загружаются только Клиент ЭДО и свежая Бухгалтерия.

Машина та же: Ryzen 5 7500F, 64 ГБ памяти, SATA SSD. Версия платформы - 8.5.1.1529.

Конвертер выгружает Зарплату за 7 секунд, ERP - за 48. Чтобы сравнивать одинаковые действия, я замерил шаги платформы на Зарплате по отдельности: создание базы - 8 секунд, загрузка файла конфигурации - 26, выгрузка из базы в XML - 24. Если конфигурация уже лежит в базе, платформе остается только выгрузка: 24 секунды против 7 у конвертера, который читает файл конфигурации. Если на входе только файл, платформе нужен весь путь - около 57 секунд.

Расхождения у Зарплаты и ERP двух видов. Часть файлов утилита отказалась выгружать и для каждого указала причину: 8 у Зарплаты и 7 у ERP. Остальные выгружены не так, как у платформы: 230 файлов у Зарплаты и 4 у ERP. Их я сейчас и исправляю. Правило из прошлой статьи осталось прежним: без потерь или ошибка.

Самое слабое место - загрузка старой Бухгалтерии: она не проходит. Конвертер отверг 5 656 форм, и файл конфигурации собирать не стал. Причина у всех одна. На старом режиме совместимости платформа 8.5 выгружает формы без объявления одного пространства имен - схемы компоновки данных. Утилита такую форму не принимает: правило есть правило. Вслед за формами отвергнуты их модули и картинки, поэтому в отчете больше 11 тысяч файлов. Это первое, что я буду исправлять в загрузке.

Что обнаружилось после Бухгалтерии

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

В Бухгалтерии нет регистров расчета, поэтому их поддержка оставалась непроверенной. Вместе с ними - планы видов расчета и права на эти объекты в ролях. Не встречались мне и ссылки на них в формах. При выгрузке утилита записывала такие ссылки простыми идентификаторами, а при загрузке отвергал их описания.

ERP добавила бизнес-процессы с картами маршрутов, диаграммы Ганта с точками и сериями, графические схемы и автономную конфигурацию. Отдельно пришлось разбираться с динамическими списками: в их запросах используются виртуальные таблицы регистров.

Бухгалтерия собрана, а на столе еще лежат детали, которых в ней не было

Что добавилось за последние дни

ERP продолжает подбрасывать работу. Из последнего:

• Диаграммы. Подписи шкалы (положение, шрифт, угол, число строк), заголовок шкалы и его место теперь загружаются и выгружаются. Расположение легенды и заголовка диаграммы берется из полных таблиц платформы, а не только из уже встреченных значений. У поля диаграммы загружаются события выбора и обработки расшифровки. Благодаря этому выгружается форма начальной страницы мобильного приложения.
• Права. Для реквизита адресации снятое право на изменение больше не снимает право на просмотр. Пока это вывод по одному образцу, в коде он помечен как временное решение.
• Списки. У динамического списка с основной таблицей загружается свойство Group.
• Свой разборщик запросов научился разбирать условие перед {...} в параметре виртуальной таблицы, цепочку сравнений вида а = б <> в, конструкцию Поле.* в параметре виртуальной таблицы, ИНДЕКСИРОВАТЬ ПО полю источника, которого нет в выборке, и колонку ВерсияДанных в своем запросе. Ресурсы, реквизиты и регистратор в условии среза тоже разбираются, но пока по образцам.

Теперь размер конфигурации для меня не главный ориентир. Даже после большой конфигурации маленькая может принести новые типы объектов.

Что брать за эталон

Выгрузку конвертера я сравниваю с выгрузкой платформы файл за файлом. А вот для проверки загрузки сначала пришлось уточнить, с чем именно сравнивать результат.

ERP и старая Бухгалтерия сохранены в режиме совместимости 8.3.16. В исходном файле конфигурации записи имеют старый формат. Платформа 8.5 при загрузке XML записывает их уже в новом.

Когда я сравнил результат загрузки утилиты с исходным файлом, не совпали все формы, макеты и перечисления. Но дело было в выборе эталона: файл поставщика для такой проверки не подходит.

Правильный эталон - файл, который сама платформа собрала из того же XML. Тогда сравниваются результаты одной и той же операции.

Эталон - то, что платформа собрала из того же XML, а не файл поставщика

Почему одна запись все равно не совпала

В Бухгалтерии осталась одна несовпадающая запись из 77 266. Это макет схемы компоновки данных: у нескольких ячеек одинаковое оформление со встроенной картинкой.

Платформа объединяет одинаковые оформления, а при сравнении картинок учитывает их адреса в памяти. Между запусками адреса меняются. Поэтому в файле поставщика могут быть объединены одни пары оформлений, а после загрузки той же платформой - другие.

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

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

Три формата XML

Проверка старой Бухгалтерии подняла еще один вопрос: какой формат выгрузки нужен пользователям разных версий платформы?

У 8.3.24, 8.3.27 и 8.5 разные версии XML:

Тем, кто работает на 8.3.24 или 8.3.27, нужен соответствующий формат.

Большинство различий удалось описать таблицей: где-то появились свойства со значениями по умолчанию, где-то изменились названия или пространство имен. Каждую следующую версию я описал как набор изменений к предыдущей.

Теперь утилита поддерживает все три формата. На старой Бухгалтерии каждый из них совпал с выгрузкой соответствующей платформы: 68 742 файла из 68 742.

Здесь тоже важно правильно выбрать исходные данные. Таблицу различий нужно строить по выгрузкам одной конфигурации разными версиями платформы - например, 8.5 и 8.3.24. Если сравнивать платформу с конвертером, его ошибки могут попасть в таблицу под видом особенностей формата.

Одна конфигурация - три формата

Загрузка и сверка на всех ядрах

В прошлой статье я писал, что загрузка пока идет в один поток и ускорять ее буду следующей. На ERP это стало заметно: проверка загрузки целиком - собрать записи из XML и сравнить больше ста тысяч записей с эталоном - занимала 13 минут 44 секунды.

Запускать проверку хочется после каждой правки. С такой паузой итераций за день получается немного. Поэтому ускорил оба шага:

• загрузка теперь обрабатывает объекты верхнего уровня параллельно, каждый в своем потоке, а результаты собирает в прежнем порядке: на ERP было 218 секунд, стало 64;
• сравнение с эталоном тоже раздается по ядрам: было 602 секунды, стало 4. Тут упирались даже не в процессор, а в открытие файлов.

Вся проверка загрузки ERP теперь занимает 1 минуту 16 секунд. Результат при этом не изменился: отчеты до и после совпали байт в байт.

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

Что я изменил в подходе к проверке

После этих пяти конфигураций у меня сложилось несколько правил:

• Проверять разные предметные области. Одна большая конфигурация не покрывает всю платформу. Маленькая конфигурация из другой области может быстрее обнаружить пробелы.
• Для загрузки брать эталон, собранный платформой из того же XML. Особенно это важно для старых режимов совместимости: исходный файл поставщика может иметь другой внутренний формат.
• Проверять воспроизводимость самого эталона. Два запуска платформы помогают найти файлы, которые меняются без изменения конфигурации.
• Изучать различия версий по выгрузкам платформы. Иначе есть риск принять ошибку конвертера за особенность старого формата.
• Ускорять проверку. Чем меньше длится сверка, тем чаще ее можно запускать и тем быстрее исправлять ошибки.

Как пользоваться Разверткой

Развертка - консольная утилита. Платформа и база ей не нужны, на вход - файл конфигурации или каталог выгрузки. Сейчас команда называется cfkit, к выпуску имя может поменяться.

cfkit export 1Cv8.cf src                 выгрузить конфигурацию в XML, как "Выгрузить конфигурацию в файлы"
cfkit export 1Cv8.cf src --format 2.17   то же в формате 8.3.24 (2.20 - формат 8.3.27)
cfkit import src 1Cv8.cf                 собрать файл конфигурации из выгрузки
cfkit xml-diff src ref                   сравнить две выгрузки по видам файлов

Выгрузка и загрузка раздают объекты по всем ядрам. Выгрузка пишет, сколько файлов записано. Если какой-то объект выгрузить без потерь нельзя, утилита называет его и причину и завершается с ошибкой. Загрузка строже: если хоть один файл не разобран, файл конфигурации не пишется вовсе, а в отчете - список отказов. Код возврата отличается от нуля, поэтому сборку в CI такая ошибка остановит сама.

Сравнение xml-diff показывает по каждому виду файлов, сколько совпало, сколько отличается, чего не хватает и что лишнее. Им удобно сверять свою выгрузку с выгрузкой платформы - так получены цифры в таблице выше.

Что дальше

Развертку я готовлю к публикации в открытом репозитории и надеюсь выложить ее в ближайшее время. Когда это случится, расскажу отдельно - и буду рад, если вы прогоните ее на своих конфигурациях.

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

• выгружать выбранные объекты или подсистему вместо всей конфигурации;
• загружать только объекты, измененные по данным git diff;
• проверить слияние релизов ERP: взять три выгрузки, выполнить слияние в git и загрузить результат. При этом собрать все причины отказа за один прогон, без цепочки ошибок, вызванных одной исходной проблемой.

Если вы сливаете релизы через git, на каком этапе сейчас больше всего трудностей? И нужен ли вам формат EDT или достаточно формата платформы?

Ну и какую конфигурацию проверить шестой? Пишите в комментариях.

Изображение для анонса создано нейросетью.