Оглавление:

• Расширение возможностей отчета о сравнении
• Предыстория
• Инструменты анализа изменений в 1С
  • Анализ изменений через сравнение/объединение
  • Обновление конфигурации на поставке
• Отчет о сравнении: анализ структуры
  • Данные из отчета
  • Аномалии 1: нарушение структуры в шаблоне RLS
  • Аномалии 2: отсутствие иерархии изменений
  • Разные шаблоны для обозначения различий
  • Различия в модулях
• Работа с данными отчета. Анализатор различий
  • Работа в анализаторе
  • Заполнение подсистем
  • Парсинг отчета о сравнении метаданных
  • Нормализация данных дерева в таблицу
  • Сравнение модулей
  • Выгрузка данных для анализа
• Сценарии использования
  • Обновление конфигурации поставщика
  • Анализ использования функций, у которых поменялось определение или видимость
  • Поиск объектов, которые были удалены в новой конфигурации поставщика
  • Изменения типов
  • Срезы различий
    • Описание полей таблицы данных сравнения
    • Типы
    • Модули
    • Роли
    • Предопределенные
    • Подсистемы
    • Формы
    • Реквизиты
• Ошибки и ограничения в текущей версии
• Поставка

Расширение возможностей отчета о сравнении

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

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

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

Предыстория

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

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

После завершения этапа "инвентаризации" был проведен анализ доработок в разрезе подсистем, модулей и функций. Исходные данные для анализа были извлечены из отчета о сравнении. В качестве основного инструмента было использовано множество написанных мной скриптов на OneScript. Эти скрипты помогли мне спарсить отчет о сравнении, получить состав подсистем, сформировать сводные данные по подсистемам, а также проанализировать измененные функции в БСП для проверки потенциальных проблем в местах их использования в основной конфигурации.

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

Я заметил, что процесс обновления стал значительно проще. У меня уже были готовые скрипты для конвертации отчета о сравнении в таблицу и отбора данных по подсистемам. Полученную таблицу я загружал в Excel и строил сводные отчеты по различным критериям: по предопределенным элементам справочников, по типам и их составу, по модулям и функциям, по составу подсистем. Это позволяло мне проверять корректность и полноту перенесенных изменений.

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

В конечном итоге я понял как правильно нужно парсить отчет и сделал качественный алгоритм преобразования отчета в таблицу данных сравнения. Разобрался с механизмом сравнения модулей и пришел к выводу, что нужно реализовать свой вариант (см. подробнее в "Различия в модулях").

Инструменты анализа изменений в 1С

Анализ изменений через сравнение/объединение

Инструмент сравнения/объединения конфигураций позволяет подробно увидеть изменения конфигурации до определенного уровня. Так для того, чтобы увидеть измененные модули достаточно просто раскрыть дерево метаданных до уровня модулей. Однако более подробно увидеть изменения на уровне функций и строк можно уже только по команде "Показать различия". Аналогично и с формами. Увидеть изменения отдельных элементов формы можно только по команде вывода отчета о сравнении.

Вызов отдельных команд для детализации изменений каждого объекта метаданных может быть весьма трудоемким процессом. Было бы удобно, если бы изменения отображались непосредственно в дереве сравнения. Такой механизм реализован в EDT, что значительно упрощает работу с функционалом. Еще бы EDT умел сохранять состояние объединения между сеансами работы.

В конфигураторе все же есть способ увидеть изменения сразу все - сформировать отчет о сравнении. При большом количестве изменений работать с таким отчетом напрямую также очень трудоемко. Этот отчет слишком детализирован и выбрать нужный уровень детализации или использовать фильтры нет возможности. Например, если нужно посмотреть только изменения в модулях (общих, менеджера, объекта, формы), то сделать это нельзя. Еще в отчет входят много не значащих изменений, таких как "изменен порядок объекта", которые также затрудняют его восприятие. В отчете могут также присутствовать "мусорные" изменения, которые в принципе не устраняются, например изменение внутренних ссылок в справочной информации. В EDT хотя бы доступна возможность установить отбор по подсистемам, однако применение дополнительных фильтров или нужных группировок здесь также не предусмотрено.

Обновление конфигурации на поставке

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

Конфигуратор, в свою очередь, предоставляет возможность проводить такие обновления с максимально возможной эффективностью. Особенно удобна данная процедура, когда обновления происходят регулярно, а вероятность возникновения конфликтов остается на низком уровне. В таких ситуациях количество возможных конфликтов, как правило, минимально. Однако, если обновления осуществляются редко при большом объеме изменений, вероятность конфликтов, наоборот, значительно увеличивается и может достигать 100% (тут я исхожу из того, что при редких обновлениях значительная часть функционала может быть изменена, а значит вероятность конфликтных изменений возрастает).

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

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

Отчет о сравнении: анализ структуры

Данные из отчета

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

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

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

Дерево данных сравнения

Аномалии 1: нарушение структуры в шаблоне RLS

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

Например, изменения в модулях отображаются с правильными отступами, соответствующими глубине дерева метаданных. Однако текст, связанный с RLS (Row-Level Security), выводится без соблюдения иерархии: он начинается с начального отступа, а затем продолжается без дополнительных отступов, начиная с новой строки. При автоматической обработке (парсинге) это может привести к ошибкам интерпретации: первая строка воспринимается как элемент определенного уровня иерархии, а последующие строки — как элементы нулевого уровня (без отступов).

Для корректного анализа текстового отчета необходимо учитывать эту особенность и разрабатывать алгоритмы, которые смогут правильно обрабатывать нарушения в отступах иерархии. На иллюстрации, например, в строке 679689 отсутствует отступ, что нарушает структуру иерархии и требует дополнительной обработки для восстановления корректного представления данных.

Аномалии структуры в шаблоне ограничений

Аномалии 2: отсутствие иерархии изменений

Еще одним примером нарушения иерархии можно считать отсутствие группировки для строк, которые были изменены в модуле. Например, строки с описаниями вроде "Изменены строки: 100–200" или "Объект присутствует: 3000–3200" выводятся на том же уровне отступа, что и сами измененные строки, что затрудняет восприятие структуры изменений.

В ранних версиях инструмента анализа была предпринята попытка улучшить читаемость за счет группировки изменений в модулях по диапазонам строк, указанным в отчете. Однако впоследствии я отказался от этого подхода, так как он не обеспечивал достаточной точности. Вместо этого была реализована функция сравнения самих измененных модулей с учетом их внутренней структуры (подробнее см. раздел "Различия в модулях").

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

Отсутствие иерархии для диапазона строк

Отсутствие иерархии для детализации изменений формы

Отсутствие иерархии изменений в команде

Разные шаблоны для обозначения различий

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

Также может быть использована метка в одном из шести вариантов, 4 из которых указаны в отчете и две не указанные - это знаки "<", ">".

Сторона изменений указана на родительском уровне иерархии от значений

Сторона изменений указана на том же уровне измененного свойства

Используемые метки изменений

Различия в модулях

Изменения в модулях, представленные в отчете, к сожалению, имеют ограниченную практическую ценность. Дело в том, что при выполнении команды "Показать различия в модулях" сравнение выполняется с учетом структуры модулей, однако в отчет попадают результаты построчного сравнения, которое не учитывает эту структуру.

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

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

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

Работа с данными отчета. Анализатор различий

Работа в анализаторе

Анализатор реализован в виде встроенной обработки, интегрированной в конфигурацию на основе базовой версии БСП (Библиотека стандартных подсистем). На главном экране обработки доступны следующие элементы для ввода данных:

1. Файл отчета о сравнении конфигураций.
2. Каталог с выгрузкой первого проекта.
3. Каталог с выгрузкой второго проекта.

Перед началом анализа необходимо выполнить две основные команды: Сформировать дерево и Сформировать таблицу.

• В результате выполнения первой команды (Сформировать дерево) создается файл дерева сравнения в формате JSON. Имя файла формируется автоматически на основе имени отчета о сравнении: ИмяФайлаОтчетаОСравнении.json.
• После выполнения второй команды (Сформировать таблицу) генерируется файл таблицы сравнения с расширением .tbl. Имя файла также формируется на основе имени отчета: ИмяФайлаОтчетаОСравнении.tbl.

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

Анализатор различий. Данные сравнения

Заполнение подсистем

Для упрощения работы с большими объемами данных в Анализаторе предусмотрена возможность фильтрации по подсистемам.

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

Фильтрация данных сравнения по выбранным подсистемам выполняется на вкладке "Данные сравнения" с помощью команды "Заполнить по выбранным подсистемам". Это позволяет сосредоточиться только на тех объектах, которые относятся к интересующим подсистемам, что значительно сокращает объем анализируемых данных и упрощает процесс сравнения.

Анализатор различий. Подсистемы

Выбранные подсистемы

Парсинг отчета о сравнении метаданных

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

Пример структуры дерева в JSON:

       {
        "Уровень": 3,
        "Код": 49507,
        "Путь": "//7/49507",
        "Метка": "- ***",
        "Имя": "ОбщийМодуль.ОбменСБанкамиСлужебный",
        "Тело": [],
        "ПодчиненныеЭлементы": []
        }

Схема JSON для структуры дерева:

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "type": "object",
    "properties": {
        "Уровень": {
            "type": "integer",
            "description": "Уровень вложенности элемента в структуре."
        },
        "Код": {
            "type": "integer",
            "description": "Уникальный код элемента."
        },
        "Путь": {
            "type": "string",
            "pattern": "^//[0-9]+/[0-9]+$",
            "description": "Строка, представляющая путь к элементу в иерархии."
        },
        "Метка": {
            "type": "string",
            "description": "Метка изменения: '+' - добавлено, '-' - удалено, '~' - изменено"
        },
        "Имя": {
            "type": "string",
            "description": "Любой текст узла"
        },
        "Тело": {
            "type": "array",
            "description": "Строки текста узла, например текст RLS"
        },
        "ПодчиненныеЭлементы": {
            "type": "array",
            "items": {},
            "description": "Массив подчинённых элементов, которые могут содержать другие объекты."
        }
    },
    "required": [
        "Уровень",
        "Код",
        "Путь",
        "Метка",
        "Имя",
        "Тело",
        "ПодчиненныеЭлементы"
    ]
}

Нормализация данных дерева в таблицу

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

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

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

  {
   "Уровень": 2,
   "Код": 7,
   "Путь": "//7",
   "Метка": "- ***",
   "Имя": "Конфигурация.ИмяВашейКонфигурации",
   "Тело": [],
   "ПодчиненныеЭлементы": [
    {
     "Уровень": 3,
     "Код": 8,
     "Путь": "//8",
     "Метка": "- ",
     "Имя": "Версия - Различаются значения",
     "Тело": [],
     "ПодчиненныеЭлементы": [
      {...}
    }
  }

Далее анализируются подчиненные узлы. Каждый узел проверяется на соответствие шаблонам имен объектов метаданных. Вот основные шаблоны:

• Вид.Тип — например, Справочник.Организации, ОбщийМодуль.ОбщегоНазначения
• Вид.Тип.Элемент.ИмяЭлемента — например, Справочник.Организации.Форма.ОсновнаяФорма, Справочник.Организации.ТабличнаяЧасть.КонтактныеЛица
• Вид.Тип.Элемент.ИмяЭлемента.ТабличнаяЧасть.ИмяТабличнойЧасти.Реквизит.ИмяРеквизита — например, Справочник.Организации.ТабличнаяЧасть.КонтактныеЛица.Реквизит.Наименование
• Подсистема - узлы, относящиеся к подсистемам

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

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

• Различаются значения:
  • Модуля
  • Любые другие различия
• Объекты — различия в составе объектов или доступе для ролей
• Любые другие различия

Различия определяются по последнему элементу в процессе рекурсивного спуска по дереву. Тип различия зависит от вершины узла, с которого начинается поиск.

Для определения изменений в левой и правой частях сравнения используются метки, которые указывают на характер различий. В отчете о сравнении применяются следующие метки:

• ["- -->"] = "-"; // Объект метаданных слева
• ["- <--"] = "+"; // Объект метаданных справа
• ["-->- "] = "-"; // Объект метаданных только слева
• ["<--- "] = "+"; // Объект метаданных только справа
• ["-->"] = "-"; // Слева
• ["<--"] = "+"; // Справа
• ["- "] = "~"; // Изменен
• ["^"] = "^"; // Порядок объекта изменен
• ["< "] = "-"; // Слева
• ["> "] = "+"; // Справа
• ["~"] = "~"; // Изменен
• ["Основная конфигурация"] = "-"
• ["Файл"] = "+"
• ["Конфигурация поставщика"] = "+"
• ["Конфигурация базы данных"] = "+"

Эти метки помогают точно определить, какие изменения произошли в конфигурации и на какой стороне (левой или правой) они находятся.

Сравнение модулей

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

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

1. Поиск всех функций в модуле слева (из первой конфигурации)
2. Поиск всех функций в модуле справа (из второй конфигурации)
3. Формирование списка общих функций как пересечения множеств, полученных на этапах 1 и 2
4. Определение удаленных функций как разности множеств из этапа 1 и этапа 3
5. Определение добавленных функций как разности множеств из этапа 2 и этапа 3
6. Выявление измененных функций на основе списка из этапа 3. Функция считается измененной, если у нее различаются хэш-суммы

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

• Удаленные функции
• Добавленные функции
• Измененные функции
  • Для измененных функций дополнительно определяется, были ли изменения в их определении или видимости (например, экспорт функции)

Этот подход позволяет получить детализированную информацию о различиях в модулях, что значительно упрощает анализ изменений между конфигурациями.

Сравнение модулей. Настройка фильтра

Выгрузка данных для анализа

Анализ изменений удобно производить в сводной таблице. Для этого нужно вывести список из таблицы данных сравнений и сохранить его в формате Excel. Дальше открыть сохраненный файл и добавить страницы со сводными таблицами по различным срезам (см. Срезы различий).

Сценарии использования

Обновление конфигурации поставщика

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

Процесс сравнения включает следующие шаги:

1. Анализ изменений основной конфигурации по отношению к текущей конфигурации поставщика для выбранных подсистем
2. Аналогичное сравнение основной конфигурации с новой конфигурацией поставщика

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

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

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

Еще один способ обновления включает следующие этапы:

1. Перенос объектов конфигурации поставщика, как при первом внедрении, по выбранным подсистемам.
2. Восстановление изменений, внесенных в основную конфигурацию по отношению к исходной конфигурации поставщика.

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

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

Анализ использования функций, у которых поменялось определение или видимость

Иногда поставщик может пересмотреть определение функций в своей конфигурации. Это может выражаться в изменении видимости функции — например, если ранее она была доступна для внешнего интерфейса, а в новой версии стала скрытой. Другой возможный сценарий — изменение состава параметров функции: добавление нового параметра или удаление существующего. Подобные изменения могут привести к проблемам в коде, который использует эти функции.

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

Такой подход позволяет минимизировать риски, связанные с изменением внешнего API поставщика, и избежать потенциальных ошибок в работе системы.

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

Установить отбор:

• Вид различий = "Модуль"
• Определение изменено = "Да"
• Метка = "~" Группировку можно использовать такую: Вид, Тип, Функция.

Сводная таблица по функциям с измененным определением

Настройка объединения функции с измененным определением

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

Установить отбор:

• Вид различий = "Модуль"
• Видимость изменена = "Да"
• Метка = "~" Группировку можно использовать такую: Вид, Тип, Функция.

Функции с измененной видимостью

Изменение видимости у процедуры

Поиск объектов, которые были удалены в новой конфигурации поставщика

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

Используйте отборы сводной таблицы:

• Вид различий = "(пусто)"
• Метка = "-"

Удаленные объекты

Изменения типов

Сравнение типов Основной конфигурации текущей и новой позволяет выявить ошибки обновления в типах. Это важно, т.к. неверный тип может привести к потери информации.

Используйте отборы сводной таблицы:

• Вид различий = "Тип"

Различия в типах

Аналогично можно проанализировать изменение в составе.

Используйте отборы сводной таблицы:

• Вид различий = "Состав"

Изменение состава

Срезы различий

Описание полей таблицы данных сравнения

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

Таблица. Поля таблицы данных сравнения

Типы

Вид различий: Тип, Тип параметра команды, Владельцы Группировка: Вид, Тип, Вид элемента, Элемент, Метка, Текст

Срез различий по типам

Модули

• Отбор:
  • Вид различий
    • Модуль, Модуль команды, Модуль менеджера, Модуль менеджера значения, Модуль набора записей, Модуль объекта
  • Определение изменено: Да
  • Видимость изменена: Да
• Группировка:
  • Вид, Тип, Вид различий, Вид элемента, Элемент, Метка, Функция

Срез различий в модулях

Роли

• Отбор
  • Вид: Роль
  • Текст: Разрешено
• Группировка
  • Тип, Право, Вид различий, Метка, Объект

Срез различий по ролям и правам на объекты

Предопределенные

• Отбор
  • Вид различий: Предопределенные
• Группировка
  • Вид, Тип, Метка, Текст

Срез различий предопределенных значений

Подсистемы

• Отбор
  • Вид: Подсистемы
  • Вид различий: Состав
• Группировка
  • Тип, Вид элемента, Элемент, Метка, Текст

Срез различий в составе подсистем

Формы

• Отбор
  • Вид элемента: Форма
• Группировка
  • Вид, Тип, Вид элемента, Элемент, Вид различий, Метка, Текст

Срез различий в формах

Реквизиты

• Отбор
  • Вид элемента: Реквизит
• Группировка
  • Тип, Вид элемента, Метка, Табличная часть, Элемент

Срез различий в реквизитах

Ошибки и ограничения в текущей версии

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

Одной из возможных ошибок, с которой можно столкнуться, является сообщение "Файл не существует". Эта ошибка возникает, если в данных сравнения присутствует узел с указанием на различия в значениях (например, "Модуль такой-то - Различаются значения"), но при этом соответствующий файл модуля отсутствует. Это может быть связано с тем, что модуль пуст и платформа не выгрузила его, либо с несоответствием между выгруженными файлами и сравниваемыми конфигурациями. Текущая интерпретация такая: если модуль не найден в 1-ой конфигурации, то значит модуль был добавлен, а если во 2-ой - значит удален.

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

• плана обмена,
• веб-сервиса,
• хранилища настроек,
• плана видов характеристик.

Поставка

Протестировано на платформе 8.3.25.1520 в файловом режиме. Должно работать и в клиент-серверном, но пути к файлам отчета и выгрузки должны быть доступны с сервера.

Поставляется в виде архива dt базы.