Версионирование правил обмена в Git

Программирование - Практика программирования

правила обмена git gitflow обмен данными XML

62
Статья рассказывает о принципах работы скриптов, позволяющих применять систему контроля версий git и подход gitflow для версионирования правил обмена.

Введение

Я думаю, что данная статья опоздала по времени своей публикации примерно на год-два. Именно тогда на Инфостарте была волна статей, касающихся возможностей "нетрадиционных" (для разработчиков в экосистеме 1С, прежде всего) способов версионирования исходных кодов конфигураций, обработок и всего остального. Примерно в то же время начался наш проект полноценного версионирования правил обмена между информационными базами 1С.

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

Основная идея

Перейдем к сути. Главная проблема ведения истории правил обмена - это единый файл. Версионировать его, конечно, можно, но всех возможностей gitflow уже не применить. В этом случае использование git ненамного отличается от содержания файла в виде макета в стандартном хранилище 1С, хотя и дает по сравнению с последним много плюсов. Тем не менее, исходя из публикации "Конвертация данных" + Git, становится понятно, что и такой вариант имеет место быть.

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

Что же мы видим, когда изучаем содержимое файла правил обмена? Мы видим фиксированную структуру XML-узлов. Это узлы ПравилаКонвертацииОбъектов, Алгоритмы, Запросы, Параметры, обработчики и др.

Логично разделить этот файл на несколько по именам узлов, чтобы все подчиненные элементы были перенесены в другие файлы. Дальше - больше. Как насчет выделения каждого Параметра, каждого ПравилаКонвертацииОбъекта (ПравилаВыгрузкиДанных, ПравилаОчисткиДанных), а также, Свойств и Значений в отдельные файлы? Хочется, чтобы два (и более, конечно) разработчика могли отредактировать два разных параметра и два разных свойства одного правила конвертации, а я потом мог это автоматически слить без конфликтов, которые обязательно будут при работе с единым файлом.

Реализация

Для реализации поставленной задачи прекрасно подошла библиотека Microsoft XML Parser и ее класс XML Document Object Model (DOM). Это известный большинству разработчиков правил обмена COM-объект MSXML2.DOMDocument. Он позволяет работать с XML-документом как с объектом, а также использовать XPath, модифицировать данные, извлекать любой подчиненный узел для вставки в новый самостоятельный объект и наоборот.

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

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

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

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

Или другой пример. При загрузке правил обмена в конфигурацию Конвертация данных им присваивается уникальный идентификатор (это же элемент справочника, куда ж без него?). А при сохранении измененного файла этот идентификатор прописывается в узел Ид корневого элемента ПравилаОбмена (см. первый скриншот). Если разработчиков несколько, а их несколько, то при слиянии мы всегда будем получать конфликт, хотя от этого как раз и уходили. Поэтому было принято решение ничего не значащий реквизит просто очищать. Та же участь постигла элемент ДатаВремяСоздания. Зачем хранить дату в файле, когда есть история в git?

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

Результат

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

Структура каталогов первого уровня

Все Параметры располагаются в одном каталоге, так как у них отсутствует иерархия и дополнительные свойства. Это, пожалуй, самый простой пример парсинга.

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

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

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

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

Вместо заключения

Системные требования

Скрипт разрабатывался для работы под операционной системой Microsoft Windows и гарантированно работает на корпоративных версиях 7, 8 и 10. Сам скрипт написан на OneScript.

Планы по развитию проекта

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

  • Проекту решительно не хватает автоматизированных тестов. Ни один публичный проект не должен существовать без этой очень важной составляющей.
  • При выполнении скриптов никак не обрабатываются ошибки. Из-за чего приходится контролировать результат разбора "глазами". Может так случиться, что разбор завершился ошибкой, не успев начаться, тогда все файлы git считает удаленными. С непривычки можно такой результат и запушить.
  • На момент публикацию разбираются не все элементы XML-файла, хотя, возможно, кому-нибудь они очень будут нужны.
  • Скрипты не работают автоматически (не используется хук precommit). Приходится запускать bat-ники вручную (хотя мы, на самом деле, уже привыкли и не жалуемся).
  • Возможно, стоит разработать библиотеку, которую можно будет встраивать в Конвертацию данных и выполнять разбор прямо из конфигурации.

Исходный код проекта опубликован в репозитории на GitHub. Поэтому пользуйтесь, участвуйте и изучайте новое!

62

См. также

Комментарии
Избранное Подписка Сортировка: Древо
1. harmit 16 15.12.17 10:37 Сейчас в теме
2. baton_pk 376 15.12.17 10:37 Сейчас в теме
Огонь!!!! Вот ещё буквально пару месяцев и я бы сам такое сел писать!!!
3. artbear 1088 15.12.17 10:52 Сейчас в теме
4. artbear 1088 15.12.17 10:53 Сейчас в теме
Схема с разделением одного большого файла на несколько более мелких/детальных очень удобна.
Юзали ее в разных вариантах.
Самый ранний, который я помню - разбор глобального модуля 1С 7.7 на файлы процедур/функций после разбора gcomp для выгрузки в cvs/snv. 2003 год
5. tsukanov 65 15.12.17 12:46 Сейчас в теме
Прикольно. Спасибо )

А эту задачу нельзя решить с помощью подходящего инструмента мёрджа?
8. bforce 415 15.12.17 21:53 Сейчас в теме
(5)
А эту задачу нельзя решить с помощью подходящего инструмента мёрджа?

Конечно можно, но нужно помнить два важных момента.

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

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

Второго пункта можно избежать, если перед слиянием или в момент коммита будет выполняться сортировка правил (у меня в репозитории есть шаблон сортировки). Иначе, мне кажется, нужно обладать довольно уникальными способностями, чтобы переварить это все в голове (особенно, когда файл у вас на 50 тыс. строк).
9. tsukanov 65 15.12.17 22:41 Сейчас в теме
(8) Я немного о другом. Мне кажется можно сделать дифф (утилиту), который будет игнорировать сортировку и прочее. Ну и соответственно мёрдж на основе этого диффа. По аналогии как конфигуратор модули сравнивает/объединяет по процедурам.
10. bforce 415 16.12.17 12:23 Сейчас в теме
(9)
По аналогии как конфигуратор модули сравнивает/объединяет по процедурам.

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

Так что, да, можно использовать и этот метод. Однако правильность объединения придется всегда контролировать глазами, так как встроенный механизм не позволяет сделать двухстороннего сравнения. Поэтому работать с git лучше.
12. tsukanov 65 16.12.17 14:19 Сейчас в теме
(10) Действительно. Я уже и забыл, что в конвертации есть это. Спасибо что напомнили )

Посмотрел тут: https://infostart.ru/public/177339/
Двухстороннее сравнение - это three-way merge? Судя по статье оно там есть.
13. artbear 1088 16.12.17 14:55 Сейчас в теме
(12) Двухстороннее это не three, это two :)
14. tsukanov 65 16.12.17 15:10 Сейчас в теме
(13) Ну я пытался угадать )) А что за зверь тогда? Просветите, плиз )
15. bforce 415 16.12.17 21:52 Сейчас в теме
(12)
Обычно двухстороннего сравнения достаточно (в конвертации как раз такое), чтобы понять есть ли конфликт, но понять это нужно будет в голове. Дважды измененные (как при работе на поддержке от конфигурации поставщика) стандартный инструмент не показывает. Нужно будет все измененные объекты где-то зафиксировать, чтобы потом сравнить с таким же списком из другой задачи или сравнивать по одному.
В общем, сомнительное удовольствие. Но, если нравится, то пожалуйста. Меня на такую монотонную работу надолго не хватает. А если она еще еженедельная/ежедневная, то ...
16. tsukanov 65 16.12.17 22:33 Сейчас в теме
(15) Понятно. Но вообще странно, что нет фильтра по дважды измененным. Мне кажется его там добавить труда не составит.
6. olegtymko 125 15.12.17 15:21 Сейчас в теме
Идея очень хорошая! Жирный плюс. Хранение в таком же виде правил регистрации пока не планируется?
7. bforce 415 15.12.17 21:40 Сейчас в теме
(6)
Хранение в таком же виде правил регистрации пока не планируется?

Мы их в своей работе не используем, так как выгружаются огромным набором за период. Поэтому такой задачи не стояло, но ее можно решить тем же способом.
11. baton_pk 376 16.12.17 12:27 Сейчас в теме
а ещё подсветка синтаксиса на bsl-файлах отработает, а на bsl внутри xml лесом пошлёт. :) мелочь, а приятно.
ну и git blame отдельно по каждому куску.
17. kuzyara 527 18.12.17 14:27 Сейчас в теме
Почему не префиксы вместо искусственной иерархии ext?
Будет ли такое же версионирование декомпилированных форм?
20. bforce 415 18.12.17 22:40 Сейчас в теме
(17)
Почему не префиксы вместо искусственной иерархии ext?

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

К тому же, если у меня 10 ПКО в одной группе и на каждый созданы все обработчики (8 штук), то это уже 90 файлов в одном каталоге. Не очень удобно.

(17)
Будет ли такое же версионирование декомпилированных форм?

Не понял. Какие формы в правилах обмена?


(18)
А может проще из КД сразу выгружать дополнительно в нужном формате?

Со стороны конечного пользователя-разработчика, конечно, проще. И это будет гораздо удобнее. Но только для него одного. Но есть и минусы, которые перевесили.
1. Сложность. Надо очень аккуратно впилиться в типовую конфигурацию и ничего при этом не поломать, ни в ней, ни в своей логике разбора. Это сложнее, чем отдельный скрипт.
2. Зависимость. Если смотреть не только на разработчика, а на ПМ-щика, автоматизированное тестирование и деплой, то тут дополнительная зависимость от КД ни к чему. Лишние действия по сбору и разбору. В КД, кажется, нет Параметров запуска, чтобы что-то автоматизировать.
Но реализовать такое, конечно, хотелось. Какой-нибудь поставкой (чтобы легко интегрировать), выделить обособленным модулем, расставить где нужно свои вставки.
18. acsent 1079 18.12.17 15:24 Сейчас в теме
А может проще из КД сразу выгружать дополнительно в нужном формате?
19. Totoro 538 18.12.17 21:13 Сейчас в теме
21. benony 728 17.02.18 07:41 Сейчас в теме
Круто! Очень круто!!!
За упоминание моей работы спасибо! :)
22. AlexWhite 186 23.03.18 08:57 Сейчас в теме
Спасибо! Если захотите что-то еще усовершенствовать в этом решении и понадобится финансирование, обращайтесь!
Оставьте свое сообщение