Повышаем эффективность разработки правил обмена

Публикация № 845576

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

правила обмена git версионирование групповая разработка практика

110
Как повысить скорость и качество разработки правил обмена? Как вести групповую разработку правил обмена? Как облегчить сопровождение правил обмена после передачи в эксплуатацию? Об этом и многом другом вы можете узнать из этой статьи.

Оглавление

В чем проблема?

  • Нет версионирования правил обмена. Доступный способ это делать - копировать правила обмена вручную.
  • Групповая разработка правил мало эффективна. Большие трудозатраты на объединение правил.
  • Не ведется учет изменений в удобной форме. Нет общего сервиса для просмотра истории изменений.

Как решить?

Для решения проблем, связанных с разработкой и сопровождением правил обмена, можно использовать систему контроля версий Git.

Git

Git - распределённая система управления версиями. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года.

Википедия https://ru.wikipedia.org/wiki/Git

 

Если говорить простыми словами, Git - это консольное приложение, которое умеет отслеживать и фиксировать изменения в файлах. Git хранит данные проекта в виде наборов слепков проекта. При каждом фиксированном изменении (commit) Git сохраняет текущую версию проекта в виде слепка текущего состояния файлов на момент фиксирования изменений. Также Git может хранить несколько версий наборов слепков  - этот механизм называется ветвление.

Более подробно о Git можно прочитать на официальном сайте.

Для локального просмотра изменений я использую Github desktop. Есть и другие клиенты Git, например:

Выбор клиента Git дело вкуса и привычек.

Git flow

При помощи подхода git flow можно упорядочить работу с ветками. Для каждого вида работ отводится отдельная ветка. В общих случаях это:

  • master - содержит последнюю актуальную рабочую версию проекта;
  • feature - ветка для нового функционала. Сливаем изменения в ветку develop;
  • develop - содержит все feature. Сливаем изменения в ветки release или master;
  • release - ветка с изменениями из develop и hotfix. Сливаем с веткой master;
  • hotfix - ветка для исправления ошибок. Сливаем с ветками develop или master;

Ветвление git flow

Всю разработку ведем от ветки develop. Каждое изменение фиксируем как feature (новый функционал) или hotfix (ошибки), в зависимости от ситуации. При внедрении в рабочую систему делаем слияние с веткой master. Более подробнее можно почитать "Шпаргалка по git-flow".

Продолжаем дальше

Если версионировать только файлы XML, возникает проблема отслеживания изменений в больших файлах XML от 10 тыс. строк. Версионирование файла XML выглядит вот так:

Изображение 2

Все сводится к тому, что становится трудно ориентироваться в изменениях файла XML в Git. Общий файл правил обмена мало подходит для анализа, сравнения и т.д.

Gitrules

Эту проблему можно решить, разбирая правила обмена как конфигурацию 1С (Выгрузить конфигурацию в xml). Для разбора правил на более мелкие файлы и каталоги можно воспользоваться библиотекой Gitrules для Onescript. Более подробнее о этом проекте можно почитать здесь https://github.com/otymko/gitrules .Также есть еще решения в этом направлении "Версионирование правил обмена в Git".

При повторении примера выше, получаем следующее:

Теперь можно точно отследить, какой объект, какое свойство, какой обработчик изменился. И самое главное, все это в читабельном виде. На уровне файлов и папок это примерно выглядит так:

Вариант с перечислениями, где вместо свойств используются значения:

Как же вести групповую разработку? Для этого нужно использовать Git хостинг. Мой выбор пал на GitLab CE.

Gitlab

GitLab — сайт и система управления репозиториями кода для Git. Проект появился из попытки сделать свой собственный GitHub, но с открытым исходным кодом, так чтобы можно было его поставить на собственный сервер внутри компании. GitLab используют сотни тысяч компаний по всему миру: IBM, VMWare, Uber, IBM, Redhat, Sony, Intel и другие.

GitLab включает в себя:

  • Хостинг Git репозиториев;
  • Гибкая настройки ролей и прав доступа на каждый проект или группу проектов;
  • Учет задач и этапов;
  • Запросы на слияние веток;
  • Обсуждения запросов на слияние и задач;
  • CICD (непрерывная интеграция, непрерывная доставка);
  • Код ревью;
  • Встроенную Wiki для каждого проекта;
  • Интеграция с внешними сервисами, такими как Trello, Slack, Gitter, LDAP, JIRA, Jenkins и т.д.;

Gitlab CE - бесплатная версия продукта с удобным интерфейсом. В последних версиях появился Web IDE. Есть возможность Git хостинг развернуть на своем сервере. Теперь каждый разработчик может с удаленного Git хостинга получать изменения и работать параллельно. При использовании Git сервера решен вопрос с получением актуальной версии правил, которые уже внедрены в продакшен или в разработке. Как альтернатива GitLab есть Bitbucket от Atlassian, GitWeb, GitHub с приватными репозиториями (стоит денег).

А где же пример?

Разберем поэтапно, как этим подходом можно пользоваться. Будем рассматривать вариант работы на OS Windows.  Для Windows существует менеджер пакетов Chocolatey. С ним устанавливать ПО становится быстрее, как в Linux. Все команды будем выполнять в cmd или powershell, кому как удобнее.

Устанавливаем Git

Скачиваем дистрибутив с официального сайта Git или с помощью Chocolatey:

choco install git

Устанавливаем OneScript

Скачиваем с официального сайта Onescript последнюю стабильную версию 1.0.20 или устанавливаем с помощью с Chocolatey:

choco install onescript.cli -Source https://myget.org/F/onescript -y

Устанавливаем библиотеку Gitrules

Библиотеку Gitrules можно установить, скачав пакет с hub Onescript. В этом поможет консольное приложение opm. Это консольное приложение идет в комплекте с Onescript.

Для установки выполним:

opm install gitrules

P.S. При выполнении команды у пользователя должны быть права чтения/записи на каталог, в котором установлен Onescript.

Создаем проект Git

Создаем начальный проект Git. Для этого, выбрав нужный каталог, выполняем команду:

git init REPO

REPO - это название нового каталога, в котором будет подключен Git.

Для перехода в каталог нужно в консоли выполнить команду:

cd REPO

Для проверки подключения каталога к Git можно обратить внимание на скрытый каталог .git:

Другой вариант - в каталоге проекта выполняем команду:

git status

При удачном выполнении будет выведено в консоль:

Подключаем Gitrules к проекту Git

В каталоге с проектом выполняем команду:

gitrules install

После выполнения будет выведено сообщение “Установка завершена”.

На этом все, подготовительный этап завершен. Для удобства также можно установить Visual Studio Code с поддержкой BSL (подсветка кода 1С).

 
 Установка Visual Studio Code (VSC)

Скачиваем дистрибутив с официального сайта https://code.visualstudio.com/Download или воспользуемся Chocolatey:

choco install visualstudiocode

Откроем VSC и установим расширение BSL. Для этого в редакторе откроем Расширения и установим его:


 

Теперь в VSC код 1С подсвечен, как на изображении ниже:



 

Первые изменения commit

Перейдем к самой интересной части. Возьмем правила обмена и сделаем первое фиксирование изменений в Git проекте. Сохраняем правила обмена из Конвертации данных. Для примера я взял тестовые правила обмена:

P.S. На закладку Версионирование и упоминания GIT в Конвертации данных не обращаем внимание. Пока это все только в состоянии разработки.

Сохраним правила обмена в каталог проекта Git:

Перейдем в каталог с проектом REPO и выполним команду:

git add ExchangeRules.xml

Теперь фиксируем изменения, сделав commit:

git commit -m ”Создание проекта с правилами обмена”

После подключения Gitrules добавился hook - precommit в проекте Git. Теперь при каждом commit правила обмена будут раскладываться на более простые составляющие - файлы и папки. Вот что получилось:

Последующие изменения правил

В Конвертации данных изменяем правила обмена. Для примера я изменил пару строк кода, изменил пару свойств объектов. Сохраняем эти изменения в проекте Git. Если просмотреть текущие изменения через GitHub Desktop:

Изменился только файл xml, но изменений на уровне файлов и папок не видно. Как я писал ранее, они делаются при commit с помощью hook precommit. Для просмотра изменений правил обмена без фиксации изменений воспользуемся в каталоге проекта командой:

gitrules precommit

Теперь изменения в каталоге проекта выглядят так:

Фиксируем изменения. Выполняем команду:

git commit -m “Изменения по спецификации С-1”

Или воспользуемся GitHub Desktop, в котором ранее подключили локальный проект Git. Заполняем заголовок и содержание commit. Фиксируем изменения:

Теперь история проекта Git выглядит так:

Подключаем проект Git к удаленному репозиторию на GitLab

Конкретно в моем случае GitLab развернут на внутреннем сервере, но на пример это никак не влияет.

Создадим проект Git в GitLab:

Укажем имя и описание проекта:

Теперь подключим удаленный Git для проекта. Выполним в каталоге проекта команду:

git remote add origin “http://path.to.hosting/my-exchange-rules.git

Теперь отправим изменения в GitLab. Выполняем команду:

git push -u origin --all

В дальнейшем можно использовать более упрощенную команду:

git push

На сервере GitLab теперь этот проект выглядит следующим образом:

История изменений:

Git flow?

А где же упомянутый git flow со своим подходом к ветвлению? Подробности по git flow опущены, чтобы не усложнять этот тестовый пример .

Подведем итоги

Используя версионирование Git при разработке правил обмена, можно выделить как плюсы, так и минусы.

Плюсы:

  • Версионирование правил в удобном виде;
  • Групповая разработка. Возможность параллельно дорабатывать одни и те же правила обмена;
  • Инструменты для анализа. Например, тот же самый code review;

Минусы:

  • Нужно осваивать новые технологии. В их списке Onescript, Git, GitLab;
  • Нет штатных средств работы с Git из Конвертации данных 2.х. Разработчики тратят больше времени на все действия;
  • Еще много минусов, которые я, возможно, не замечаю;

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

Что дальше?

В планах реализовать такую идею, как внедрение использования Gitrules и Git в Конвертацию данных 2.х. Для начала простой функционал:

  • Разбор правил обмена на файлы и папки при сохранении правил обмена;
  • Получение актуальных правил обмена с хостинга Git;
  • Объединение правил обмена в Конвертации данных 2.х., используя ветки с Git проекта;

Также остро стоит вопрос автоматизации тестирования правил обмена. В голову приходит идея применения CI/CD. Используя сервер сборки Jenkins, можно проверять правила обмена на базовых тестах, например та же самая проверка синтаксиса.

Спасибо за внимание! Особенно тем, кто дочитал до конца :)

110

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. kembrik 2 25.06.18 10:55 Сейчас в теме
Отличная статья, спасибо, в копилку однозначно. А есть ли аналог GitRules для красивого "схлопывания" процедур и функций в Общем модуле "МенеджерОбменаЧерезУниверсальныйФормат" для Кд 3.0?
maxx; olegtymko; +2 Ответить
2. olegtymko 147 25.06.18 11:01 Сейчас в теме
(1) Спасибо.
Есть один из проектов на осень, где я буду копаться в EnterpriseData. Я думаю, что у gitrules появиться возможность это делать. Можете написать issue здесь: https://github.com/otymko/gitrules/issues. Может кто-то раньше меню доберется и доработает=)
3. ManyakRus 284 25.06.18 11:39 Сейчас в теме
легче вообще не пользоваться правилами обмена :)
всё стереть и сделать COM-обмен
4. olegtymko 147 25.06.18 11:47 Сейчас в теме
(3) В каждом подходе есть свою плюсы и минусы. Для "быстрого старта" правила обмена очень даже подходят. Тем более при небольшой сложности все накликивается мышкой)
7. gorakh 18 25.06.18 12:14 Сейчас в теме
(3)В КД2 есть обмен через COM.
olegtymko; +1 Ответить
12. olegtymko 147 25.06.18 13:04 Сейчас в теме
(7) если рассматриваем БСП, то там есть обмен com с использованием правил обмена. Но в плане разработки ничего не меняется)
Fox-trot; gorakh; +2 Ответить
5. AntonSm 24 25.06.18 11:52 Сейчас в теме
Отличная статья. Спасибо за наводку на gitrules.
olegtymko; +1 Ответить
6. olegtymko 147 25.06.18 11:57 Сейчас в теме
(5) Gitrules писался в попытке представить правила обмена как выгрузку конфигурации в xml. Есть определенные ограничения в функционале, которые со временем должны решиться.
8. acanta 56 25.06.18 12:44 Сейчас в теме
Правильно ли я поняла что после создания правил обмена в конвертации 2 необходимо добавить план обмена конфигураторе, в который следует включить все объекты, на которые есть ПКО и не включать тех, на которые ПКО нет?
10. olegtymko 147 25.06.18 12:50 Сейчас в теме
(8) конфигурации на БСП? Если да, то можно почитать здесь https://its.1c.ru/db/pubcloud1c/content/81/hdoc.
9. fishca 1149 25.06.18 12:48 Сейчас в теме
Пожелания:
1. Добавить ссыль на https://github.com/otymko/gitrules
2. Сконцентрироваться на описании gitrules
11. olegtymko 147 25.06.18 12:53 Сейчас в теме
(9) пожелания приняты)
Вообще в планах было написать отдельную статью о Gitrules и о расширении для КД 2.х, помогающее версионировать правила.
13. herfis 281 25.06.18 13:07 Сейчас в теме
Не могу найти, но точно у кого-то читал ранее про групповую разработку правил обмена через git. Только не помню, как там решалась (и решалась ли) задача декомпозиции правил. С gitrules это превращается в полноценный инструмент. Плюс за подробный мануал.
olegtymko; +1 Ответить
15. olegtymko 147 25.06.18 13:27 Сейчас в теме
14. sisdrou 22 25.06.18 13:20 Сейчас в теме
Идея интересная.... Как это будет работать с большими, объемными конфигурациями. Типовой механизм достаточно долго сравнивает изменения, если тут будет все происходить многократно быстрее, тогда - Да. А так.., это просто забавная фича. Внести ее в работу будет достаточно сложно, с учетом поправки на трафик с депозитарием ..
16. olegtymko 147 25.06.18 13:30 Сейчас в теме
(14) проверял на правилах обмена более 30 тыс. строк. Не особо долго ждал. Могу сделать замер, если вам интересно) Вообще если делать сравнение на git хостингах - это происходит довольно так быстро.
19. sisdrou 22 25.06.18 16:50 Сейчас в теме
(16)
это происходит довольно так быстро


Спасибо.. попробуем.
17. xzfantom 4 25.06.18 14:51 Сейчас в теме
Отличный проект, хорошо использовать даже без групповой обработки, не нужно искать по xml что к чему относится и когда менялось.
А насчет тестирования - почему бы не использовать GitLab Runner, раз всё равно используется гитлаб? И сразу в проекте будет отображаться прошёл/не прошёл.
18. olegtymko 147 25.06.18 14:53 Сейчас в теме
(17) Можно, пока думаю над вариантами. Ближе конечно Jenkins т.к. его использую для gitsync и запуска тестов.
20. benony 986 26.06.18 01:46 Сейчас в теме
Спасибо за статью, жирный плюс!!!
Предлагаю объединить усилия в продолжении проекта: https://github.com/ha1s/ConversionPlus. На анонсированную задумку там уже ишью лежит :))
itkk24; Артано; olegtymko; +3 Ответить
21. olegtymko 147 26.06.18 03:00 Сейчас в теме
(20) Хорошее решение! Посмотрю ваш проект в отпуске)
22. olegtymko 147 26.06.18 03:55 Сейчас в теме
(20) где можно почитать о функционала вашего проекта?
23. benony 986 26.06.18 03:59 Сейчас в теме
(22) Ссылка уже была: https://infostart.ru/public/632457/. Сейчас на gitHab лежит данная версия, дальнейшие планы развития отражены в ишузах. За работу возьмусь в ближайшие дни
24. nytlenc 271 02.07.18 09:05 Сейчас в теме
Мы не ищем легких путей....
d4rkmesa; the1; itkk24; +3 Ответить
25. olegtymko 147 02.07.18 10:29 Сейчас в теме
(24) Чаще всего их просто нет) Но работать как-то нужно. Что именно вам показалось сложным?
26. nytlenc 271 02.07.18 10:33 Сейчас в теме
(25) по мне, чем ставить столько инструментов, настраивать, изучать, проще и быстрее сразу все реализовать в конвертации данных.
27. olegtymko 147 02.07.18 12:33 Сейчас в теме
(26) в планах вынести общий функционал в конвертацию данных. Только работу с git сервером для группового доступа все равно не убрать)
28. STivO 59 07.08.18 12:49 Сейчас в теме
У себя настроил под одного клиента, у которого 60 правил обмена. Версионность правил уже использовал раннее через git, но с gitrules намного удобнее стало. Осталось механизм взаимодействия с git напрямую из КД приделать для полного счастья. Пришлось кончено повозиться с длиной полного имени файла.
29. olegtymko 147 07.08.18 12:56 Сейчас в теме
(28) Длина полного имени файл - это прям боль) Как с длиной решили вопрос?
p.s. потихоньку пилится расширение для кд 2.0.
31. STivO 59 07.08.18 20:34 Сейчас в теме
(29) Пока временно изменил модуль РазобратьПравилаОбмены.os. С помощью команды "subst" создается виртуальный диск, который сопоставляется к каталогу, в который в данный момент разбираются правила. Пробовал еще через команду robocopy обходить 260 символов, всё отрабатывало, но медленно. Еще были варианты в интернете, но пока не пробовал их.
32. olegtymko 147 08.08.18 02:19 Сейчас в теме
(31) Да уж, решение не из простых =)
30. Serg O. 171 07.08.18 20:13 Сейчас в теме
git версионирование сравнивает построчно... И при добавлении 1 строки вначале текста меняется N строк всего. Разложение на объекты хорошо, но как обратно собрать версию месячной давности например? Обычное сохранение правил в отдельные файлы и 1С стандарная сравнение файлов иногда лучше (и привычнее) работает... Переход на git синхронизацию неплохая идея, сама 1С уже на EDT с ним работает. Для oScript тоже уже масса автоматов прописана... но все равно это китайская грамота до сих пор для многих. Нет универсального клиента для git и это жаль
33. olegtymko 147 08.08.18 02:29 Сейчас в теме
(30) Если мне нужны правила обмена, допустим которые я коммитил в начале июня, я переключаюсь git checkout на нужный commit и беру файл xml. Для сбора правил из разложенных файлов и папок можно также воспользоваться gitrules assembly. В качестве клиента я использую github desktop - обычно мне его функционала хватает, для разработки и поддержки правил обмена.
34. STivO 59 09.08.18 11:09 Сейчас в теме
Когда ты делаешь коммит определенного правила обмена, а разбираются у тебя все, что есть в каталоге не правильно) и при этом исходники надо отдельно коммитить. В механизме precommit1c, когда ты делаешь коммит определенной обработки, то у тебя разбирается сама обработка и исходники сразу же помещаются в тот же коммит. Так же, когда делаешь установку gitules через консольную команду, то содержимое файла pre-commit в папке hooks затирается. В общем есть над чем поработать)
35. olegtymko 147 09.08.18 13:05 Сейчас в теме
(34) Всегда можно добавить issue на github)
36. infosoft-v 299 25.08.18 16:02 Сейчас в теме
Спасибо за удобный инструмент.
olegtymko; +1 Ответить
37. Korolev 50 30.01.19 13:32 Сейчас в теме
38. Lancelot-2M 100 15.04.19 17:11 Сейчас в теме
Какой смысл сравнивать все через git? Ну если только ради спорта. По настоящему дельной была бы разработка подсистем блокировки правил внутри кд для групповой разработки(что легко), сравнения и слияния(что интересно) и копирования вместе с конфигурациями с прямо записью в таблицы данных (что нудно, но необходимо для порождения новых версий больших правил обмена между большими конфигурациями).
39. olegtymko 147 16.04.19 03:24 Сейчас в теме
(38)
сравнивать все через git? Ну если только ради спорта. По настоящему дельной была бы разработка подсистем блокировки правил внутри кд для групповой разработки(что легк

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

Так же, доработка КД под совместную разработку тоже имеет смысл (аналог хранилища 1С, но для правил).
Оставьте свое сообщение