В предлагаемой доработке реализованы инструменты, позволяющие получать идентичные файлы правил при их последовательной загрузке/выгрузке разными разработчиками, что позволяет работать в КД в группе с использованием Git-а.
Что было изменено и добавлено
1. Исправлена ошибка: Исчезающий Приемники в ПКС при отсутствии Источника
Если в ПКС необходимо указать только Приемник без Источника (Например, значение заполняется в коде обработчика), то при выгрузке и загрузке таких правил Приемник очищался (Рис. 1).
Эта же ошибка проявлялась и тогда, когда в настройках ПКС разработчику нужно, чтобы Источник и Приемник различались – при повторной загрузке правил Приемник приравнивался к источнику.
2. Установлено единообразие при выгрузке: Конечные пробелы в строках
При выгрузке правил не однозначно производилась выгрузка концовок строк XML для атрибутов и обработчиков конвертации, из-за чего правила, выгруженные сразу после разработки, и повторно выгруженные после загрузки их в КД, могли отличаться пробелами в конце строковых значений.
То же самое можно было наблюдать и при выгрузке кодов и наименований для ПВД, ПКО, ПКС, ПКЗ, ПОД, ПКГО, ПКГС и их групп.
Исправлено: при выгрузке все строки дополнительно обрезаются функцией СокрЛП().
3. Добавлен инструмент адаптации под Git: Порядок элементов и лишний коммит с датой
Стандартно, выгрузка объектов конвертации (ПКО, ПКС и т.д.) производится в порядке, отсортированном по реквизиту «Порядок выполнения», который можно найти на закладке «Дополнительно» любого объекта.
Проблема типовой «Конвертации данных» состоит в том, что при разработке правил обмена для новых элементов при некоторых обстоятельствах (каких именно, не стал выяснять) реквизит «Порядок» может быть заполнен одинаковым для двух соседних элементов, или не заполнен вовсе (остается нулевой).
При загрузке таких правил пустым значениям «Порядка» КД сама присваивает новые значения, а при последующей выгрузке правил, из-за одинаковых номеров, сортировка элементов дает совершенно иной результат. Как следствие, Git показывает много изменений целыми блоками, которых на самом деле нет с точки зрения функционала.
Для решения этой проблемы, в меню «Отладка обработчиков», после пункта «Настройка» добавлен новый – «Адаптация под Git-flow». Основное его предназначение – выполнение корректировки реквизитов «Порядок» у всех объектов текущей конвертации (Рис. 2).
Также, дополнительно можно указать необходимость округления даты обновления правил при каждой выгрузке в репозиторий. Это дополнительно поможет избежать самого часто встречающегося изменения при коммите (Рис. 3).
Порядок внедрения
1. В рабочей конфигурации включаем возможность внесения изменений;
2. Сравнением/объединением загружаем приложенный файл конфигурации, принимаем изменения. Если ваша конфигурация уже изменена, то необходимо перенести доработки только измененных и новых объектов (см. следующий раздел);
3. Таким же образом должны обновить свои конфигурации КД все разработчики вашей команды;
4. Запускаемся в пользовательском режиме, и для всех правил обмена выполняем корректировку нумерации порядка выгрузки;
5. Выполняем первый коммит откорректированных правил обмена, чтобы все разработчики группы работали с идентичными файлами (пункты 4 и 5 достаточно выполнить одному разработчику из команды, остальные получат изменения из Гита (pull)).
Техническая информация
Для тех, кто уже залез в конфигурацию КД или пользуется другими сторонними доработками.
Перечень доработанных и добавленных объектов:
— Новые общие модули bnГитфлоу и bnГитфлоуПовтИсп
— Изменена общая форма ПравилаОбмена
— Новая общая форма bnНастройкиГитфлоу
— Изменены обработки ВыгрузкаКонвертации и ЗагрузкаКонвертации
Изменения выполнены только в коде модулей, диалоги не затронуты.
Все измененные и добавленные объекты помещены в отдельную подсистему bnГитфлоу.
Предназначен для версии "Конвертации данных" 2.1.8.2
Новое в версии от 18.12.2024
1. Опция контроля необходимости корректировки порядков элементов вынесена в настройки;
2. В форме выгрузки правил обмена добавлен флажок "Сохранять оригиналы XML". Позволяет одновременно выгружать правила обмена/регистрации в виде исходных XML (например, для версионирования в Git), и в виде архива zip (для загрузки в рабочий контур).
3. В форме выгрузки правил теперь корректно сохраняются/восстанавливаются пути к файлам, в ходящим в комплект zip-поставки. Раньше, при выборе других правил конвертации, правила корреспондента и правила регистрации оставались прежними.
4. Реализована возможность редактирования кода обработчиков в VS Code с установленным плагином 1C:BSL. Возможность появилась во всех формах, где присутствуют настройки обработчиков событий. Перед первым использованием необходимо зарегистрировать VS Code как программу по умолчанию для файлов с расширением *.bsl.
Новое в версии от 07.11.2024
1. Оптимизирован алгоритм перенумерации "Порядка" элементов для единообразной выгрузки в Git. Раньше, если сбивался номер одного элемента (ПКО, ПКС, и т.д.), то корректировка правил обмена вызывала изменение реквизита "Порядок" у большинства элементов конвертации. Теперь изменения затрагивают только элементы с неуникальным и нулевым "Порядком", что приводит к минимальным изменениям в коммите.
2. При установленном флажке "Производить контроль перед выгрузкой правил" отключен вопрос пользователю о необходимости скорректировать конвертацию, перенумерация производится автоматически.
3. Устранены выявленные мелкие недочеты в алгоритме выгрузки правил.
+ за Гит и решение проблемы больших различий в файлах
Функционала и описания применения методики Git-flow не увидел.
(2) Я не ставил перед собой целью описание технологии Git-flow, я просто решил проблему невозможности применения КД в группе при использовании Гита, этим и поделился. Описание технологии — это тема отдельной статьи, на эту тему уже есть немало вебинаров и статей, в том числе ваша, Петр 🙂
Плюсую, молодец!
(3) При прочтении заголовка ожидал интеграцию с git, плюс, конечно, заработали. Надеюсь следующая статья будет об этом 😉
Файл правил в итоге остается один большой или он разбивается на фрагменты?
(8)файл остаётся один, только уменьшается на несколько килобайт за счёт обрезания пробелов в конце строк
(3) это вам, видимо, намекнули, что термин Gitflow в заголовке не относится к статье никак. Gitflow — это только методология работы с DVCS, она даже к Git не привязана.
Вы решили проблему неидемпотентного сохранения, результат этой работы может использоваться в любой VCS и с любой методологией.
(10) Спасибо за конструктивное замечание. Заголовок поправил
(11) А вам спасибо за разработку, очень нужную проблему решили
Спасибо за публикацию. Берем в копилку знаний.
Полезное решение, спасибо!
Какая крутотень. Попробую освоить. Спасибо, что довели это дело до конца, все-таки. Отсутствие даже примитивного синтаксического контроля в КД 2 и нюансы групповой разработки иногда из себя выводили — порой проще было в Notepad++ что-то поправить, если нужно было быстро. Сейчас наконец можно все привести к единому знаменателю.