При обновлении нетиповых конфигураций или анализе изменений между версиями разработчики часто сталкиваются с огромным списком измененных объектов. Если задача ограничена конкретным функциональным блоком, поиск нужных элементов в общем дереве метаданных превращается в рутину. В этой статье мы разберем, как эффективно использовать механизмы 1С для фильтрации объектов по подсистемам в режиме сравнения и объединения.
Это наиболее правильный и эффективный способ, предусмотренный в стандартном конфигураторе. Часто пользователи совершают ошибку, ограничиваясь только первым шагом, и не видят результата. Разберем правильный алгоритм действий по шагам.
Войдем в режим сравнения конфигураций (например, через меню Конфигурация — Сравнение, объединение с конфигурацией из файла). После того как дерево сравнения будет построено, выполним следующие действия:
После выполнения этих действий дерево метаданных мгновенно перестроится, и мы увидим только те объекты, которые входят в выбранную подсистему и при этом имеют отличия. Это позволяет сосредоточиться на конкретном коде, не отвлекаясь на изменения в других модулях.
Рассмотрим альтернативный вариант, который может быть полезен, если нам нужно быстро просмотреть изменения в конкретной дочерней подсистеме. Этот способ упоминался как менее удобный, но он имеет право на жизнь при локальной работе.
В дереве объектов основной конфигурации (не в окне сравнения, а в обычном окне метаданных) найдем нужную нам подсистему. Откроем её свойства и нажмем на кнопку «Состав». В открывшемся окне состава подсистемы также доступна кнопка настройки фильтра. Если в этом окне установить отбор «Измененные», система покажет список объектов этой подсистемы, которые отличаются от текущей версии.
Важное ограничение: данный метод крайне ненадежен для полноценного объединения. Проанализируем причину: в состав подсистемы разработчики часто забывают включить зависимые объекты, такие как ОбщиеМодули, ОпределяемыеТипы или ПодпискиНаСобытия. Если ориентироваться только на окно «Состава», можно пропустить критически важные изменения в логике, которые физически не привязаны к подсистеме, но функционально к ней относятся.
Если вы используете современную среду разработки EDT, процесс сравнения выглядит иначе. Поскольку EDT базируется на Eclipse и тесно интегрирована с Git, механизмы фильтрации там значительно мощнее:
Иногда требуется не объединять код, а просто подготовить список изменений для аналитика или руководителя проекта. В окне сравнения/объединения выберем Действия — Отчет о сравнении объектов.
Хотя в настройках самого отчета нет прямой галочки «По подсистеме», мы можем скомбинировать методы: сначала отметить объекты по подсистеме (как в Методе 1), а при формировании отчета указать настройку «Только для отмеченных объектов». В результате мы получим подробный документ (в формате табличного документа .mxl или текста), содержащий детальный аудит изменений только по выбранному контуру. Для формирования такого перечня в табличном виде можно использовать обработку для анализа изменений конфигурации с выгрузкой в XLS.
Проанализируем ситуацию, когда необходимо сравнить только специфический функционал, вынесенный в расширение. В этом случае задача упрощается: само расширение по сути является фильтром. Если мы сравниваем конфигурацию с расширением, система автоматически ограничивает область видимости только теми объектами, которые были в него добавлены. Опытные разработчики иногда используют этот прием, временно добавляя объекты интересующей подсистемы в пустое расширение, чтобы визуализировать изменения отдельно от основной массы кода.
Если вам требуется регулярно выполнять сравнение по определенным критериям, можно воспользоваться запуском конфигуратора из командной строки. Используйте параметры:
/ConfigurationRepositoryCompareCfg -File "имя_файла"
/DumpConfigToFiles "путь_к_выгрузке"
Выгрузив конфигурацию в файлы, вы сможете использовать внешние инструменты сравнения (например, Beyond Compare или WinMerge), где можно настроить сложнейшие фильтры по маскам имен файлов и путям к папкам подсистем. Это позволяет полностью автоматизировать процесс контроля изменений в больших командах разработчиков. При необходимости для экспорта объектов подойдёт обработка для частичной выгрузки метаданных в файлы.