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

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

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

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

Оглавление

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

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

Как решить?

Для решения проблем, связанных с разработкой и сопровождением правил обмена, можно использовать систему контроля версий 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, можно проверять правила обмена на базовых тестах, например та же самая проверка синтаксиса.

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

87

См. также

Комментарии
Избранное Подписка Сортировка: Древо
1. kembrik 25.06.18 10:55 Сейчас в теме
Отличная статья, спасибо, в копилку однозначно. А есть ли аналог GitRules для красивого "схлопывания" процедур и функций в Общем модуле "МенеджерОбменаЧерезУниверсальныйФормат" для Кд 3.0?
maxx; olegtymko; +2 Ответить
2. olegtymko 123 25.06.18 11:01 Сейчас в теме
(1) Спасибо.
Есть один из проектов на осень, где я буду копаться в EnterpriseData. Я думаю, что у gitrules появиться возможность это делать. Можете написать issue здесь: https://github.com/otymko/gitrules/issues. Может кто-то раньше меню доберется и доработает=)
3. ManyakRus 273 25.06.18 11:39 Сейчас в теме
легче вообще не пользоваться правилами обмена :)
всё стереть и сделать COM-обмен
4. olegtymko 123 25.06.18 11:47 Сейчас в теме
(3) В каждом подходе есть свою плюсы и минусы. Для "быстрого старта" правила обмена очень даже подходят. Тем более при небольшой сложности все накликивается мышкой)
7. gorakh 17 25.06.18 12:14 Сейчас в теме
(3)В КД2 есть обмен через COM.
olegtymko; +1 Ответить
12. olegtymko 123 25.06.18 13:04 Сейчас в теме
(7) если рассматриваем БСП, то там есть обмен com с использованием правил обмена. Но в плане разработки ничего не меняется)
Fox-trot; gorakh; +2 Ответить
5. AntonSm 25.06.18 11:52 Сейчас в теме
Отличная статья. Спасибо за наводку на gitrules.
olegtymko; +1 Ответить
6. olegtymko 123 25.06.18 11:57 Сейчас в теме
(5) Gitrules писался в попытке представить правила обмена как выгрузку конфигурации в xml. Есть определенные ограничения в функционале, которые со временем должны решиться.
8. acanta 44 25.06.18 12:44 Сейчас в теме
Правильно ли я поняла что после создания правил обмена в конвертации 2 необходимо добавить план обмена конфигураторе, в который следует включить все объекты, на которые есть ПКО и не включать тех, на которые ПКО нет?
10. olegtymko 123 25.06.18 12:50 Сейчас в теме
(8) конфигурации на БСП? Если да, то можно почитать здесь https://its.1c.ru/db/pubcloud1c/content/81/hdoc.
9. fishca 1125 25.06.18 12:48 Сейчас в теме
Пожелания:
1. Добавить ссыль на https://github.com/otymko/gitrules
2. Сконцентрироваться на описании gitrules
11. olegtymko 123 25.06.18 12:53 Сейчас в теме
(9) пожелания приняты)
Вообще в планах было написать отдельную статью о Gitrules и о расширении для КД 2.х, помогающее версионировать правила.
13. herfis 261 25.06.18 13:07 Сейчас в теме
Не могу найти, но точно у кого-то читал ранее про групповую разработку правил обмена через git. Только не помню, как там решалась (и решалась ли) задача декомпозиции правил. С gitrules это превращается в полноценный инструмент. Плюс за подробный мануал.
olegtymko; +1 Ответить
15. olegtymko 123 25.06.18 13:27 Сейчас в теме
14. sisdrou 22 25.06.18 13:20 Сейчас в теме
Идея интересная.... Как это будет работать с большими, объемными конфигурациями. Типовой механизм достаточно долго сравнивает изменения, если тут будет все происходить многократно быстрее, тогда - Да. А так.., это просто забавная фича. Внести ее в работу будет достаточно сложно, с учетом поправки на трафик с депозитарием ..
16. olegtymko 123 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 123 25.06.18 14:53 Сейчас в теме
(17) Можно, пока думаю над вариантами. Ближе конечно Jenkins т.к. его использую для gitsync и запуска тестов.
20. benony 639 26.06.18 01:46 Сейчас в теме
Спасибо за статью, жирный плюс!!!
Предлагаю объединить усилия в продолжении проекта: https://github.com/ha1s/ConversionPlus. На анонсированную задумку там уже ишью лежит :))
itkk24; Артано; olegtymko; +3 Ответить
21. olegtymko 123 26.06.18 03:00 Сейчас в теме
(20) Хорошее решение! Посмотрю ваш проект в отпуске)
22. olegtymko 123 26.06.18 03:55 Сейчас в теме
(20) где можно почитать о функционала вашего проекта?
23. benony 639 26.06.18 03:59 Сейчас в теме
(22) Ссылка уже была: https://infostart.ru/public/632457/. Сейчас на gitHab лежит данная версия, дальнейшие планы развития отражены в ишузах. За работу возьмусь в ближайшие дни
24. nytlenc 265 02.07.18 09:05 Сейчас в теме
Мы не ищем легких путей....
d4rkmesa; the1; itkk24; +3 Ответить
25. olegtymko 123 02.07.18 10:29 Сейчас в теме
(24) Чаще всего их просто нет) Но работать как-то нужно. Что именно вам показалось сложным?
26. nytlenc 265 02.07.18 10:33 Сейчас в теме
(25) по мне, чем ставить столько инструментов, настраивать, изучать, проще и быстрее сразу все реализовать в конвертации данных.
27. olegtymko 123 02.07.18 12:33 Сейчас в теме
(26) в планах вынести общий функционал в конвертацию данных. Только работу с git сервером для группового доступа все равно не убрать)
28. STivO 57 07.08.18 12:49 Сейчас в теме
У себя настроил под одного клиента, у которого 60 правил обмена. Версионность правил уже использовал раннее через git, но с gitrules намного удобнее стало. Осталось механизм взаимодействия с git напрямую из КД приделать для полного счастья. Пришлось кончено повозиться с длиной полного имени файла.
29. olegtymko 123 07.08.18 12:56 Сейчас в теме
(28) Длина полного имени файл - это прям боль) Как с длиной решили вопрос?
p.s. потихоньку пилится расширение для кд 2.0.
31. STivO 57 07.08.18 20:34 Сейчас в теме
(29) Пока временно изменил модуль РазобратьПравилаОбмены.os. С помощью команды "subst" создается виртуальный диск, который сопоставляется к каталогу, в который в данный момент разбираются правила. Пробовал еще через команду robocopy обходить 260 символов, всё отрабатывало, но медленно. Еще были варианты в интернете, но пока не пробовал их.
32. olegtymko 123 08.08.18 02:19 Сейчас в теме
(31) Да уж, решение не из простых =)
30. Serg O. 132 07.08.18 20:13 Сейчас в теме
git версионирование сравнивает построчно... И при добавлении 1 строки вначале текста меняется N строк всего. Разложение на объекты хорошо, но как обратно собрать версию месячной давности например? Обычное сохранение правил в отдельные файлы и 1С стандарная сравнение файлов иногда лучше (и привычнее) работает... Переход на git синхронизацию неплохая идея, сама 1С уже на EDT с ним работает. Для oScript тоже уже масса автоматов прописана... но все равно это китайская грамота до сих пор для многих. Нет универсального клиента для git и это жаль
33. olegtymko 123 08.08.18 02:29 Сейчас в теме
(30) Если мне нужны правила обмена, допустим которые я коммитил в начале июня, я переключаюсь git checkout на нужный commit и беру файл xml. Для сбора правил из разложенных файлов и папок можно также воспользоваться gitrules assembly. В качестве клиента я использую github desktop - обычно мне его функционала хватает, для разработки и поддержки правил обмена.
34. STivO 57 09.08.18 11:09 Сейчас в теме
Когда ты делаешь коммит определенного правила обмена, а разбираются у тебя все, что есть в каталоге не правильно) и при этом исходники надо отдельно коммитить. В механизме precommit1c, когда ты делаешь коммит определенной обработки, то у тебя разбирается сама обработка и исходники сразу же помещаются в тот же коммит. Так же, когда делаешь установку gitules через консольную команду, то содержимое файла pre-commit в папке hooks затирается. В общем есть над чем поработать)
35. olegtymko 123 09.08.18 13:05 Сейчас в теме
(34) Всегда можно добавить issue на github)
36. infosoft-v 283 25.08.18 16:02 Сейчас в теме
Спасибо за удобный инструмент.
olegtymko; +1 Ответить
Оставьте свое сообщение