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

15.12.17

Разработка - Групповая разработка (Git, хранилище)

Статья рассказывает о принципах работы скриптов, позволяющих применять систему контроля версий 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. Поэтому пользуйтесь, участвуйте и изучайте новое!

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

См. также

Системы контроля версий для 1С-разработчиков.

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9008    78    4    

108

Автоматизация процесса разработки с помощью сервиса GitFlic

Групповая разработка (Git, хранилище) Бесплатно (free)

GitFlic – первая в России полностью самостоятельная реализация сервиса для хранения репозиториев с исходным кодом. За три года разработки сервис GitFlic стал полноценным инструментом, которым можно заменить GitLab, GitHub и BitBucket. Расскажем о том, как выстроить в GitFlic процесс автоматического тестирования, статического анализа кода и сборки приложений.

05.03.2024    1747    user1989937    6    

15

OpenYellow - рейтинг открытых GitHub репозиториев для платформы 1С:Предприятие

Групповая разработка (Git, хранилище) Бесплатно (free)

Обновляемый топ GitHub репозиториев для 1С по всем языкам программирования и еще немного рассуждений про open-source.

05.02.2024    3685    bayselonarrend    15    

59

Насколько глубок 1С-ный GitHub?

Групповая разработка (Git, хранилище) Бесплатно (free)

Open-source проекты - важная часть мира программного обеспечения. 1С привычно держится немного в стороне от глобальных трендов, но бросить холодный статистический взгляд на положение дел мне показалось небезынтересным.

22.01.2024    7713    bayselonarrend    50    

86

TCP прокси-сервер хранилища конфигурации 1С

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Платформа 1С v8.3 Бесплатно (free)

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    2648    kamisov    17    

56

Отдай корень! Библиотека OneScript для получения информации о захваченных объектах в хранилище

Групповая разработка (Git, хранилище) Бесплатно (free)

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

26.12.2023    1281    ardn    1    

24

Git Code Review - инструмент для рецензирования кода

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Конфигурации 1cv8 1С:ERP Управление предприятием 2 Абонемент ($m)

Git Code Review - инструмент, позволяющий быстро анализировать изменения из git-репозитория прямо в 1С

1 стартмани

20.12.2023    3833    56    salexdv    26    

80

Захват в хранилище по составу подсистем

Групповая разработка (Git, хранилище) Управляемые формы 8.3.8 Конфигурации 1cv8 Абонемент ($m)

Обработка для захвата объектов в хранилище согласно составу подсистем.

1 стартмани

21.11.2023    1295    7    ImHunter    0    

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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