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

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

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

Оглавление

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

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

Как решить?

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

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

См. также

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


Спасибо.. попробуем.
17. xzfantom 4 25.06.18 14:51 Сейчас в теме
Отличный проект, хорошо использовать даже без групповой обработки, не нужно искать по xml что к чему относится и когда менялось.
А насчет тестирования - почему бы не использовать GitLab Runner, раз всё равно используется гитлаб? И сразу в проекте будет отображаться прошёл/не прошёл.
18. olegtymko 100 25.06.18 14:53 Сейчас в теме
(17) Можно, пока думаю над вариантами. Ближе конечно Jenkins т.к. его использую для gitsync и запуска тестов.
20. benony 470 26.06.18 01:46 Сейчас в теме
Спасибо за статью, жирный плюс!!!
Предлагаю объединить усилия в продолжении проекта: https://github.com/ha1s/ConversionPlus. На анонсированную задумку там уже ишью лежит :))
itkk24; Артано; olegtymko; +3 Ответить
21. olegtymko 100 26.06.18 03:00 Сейчас в теме
(20) Хорошее решение! Посмотрю ваш проект в отпуске)
22. olegtymko 100 26.06.18 03:55 Сейчас в теме
(20) где можно почитать о функционала вашего проекта?
23. benony 470 26.06.18 03:59 Сейчас в теме
(22) Ссылка уже была: https://infostart.ru/public/632457/. Сейчас на gitHab лежит данная версия, дальнейшие планы развития отражены в ишузах. За работу возьмусь в ближайшие дни
24. nytlenc 271 02.07.18 09:05 Сейчас в теме
Мы не ищем легких путей....
25. olegtymko 100 02.07.18 10:29 Сейчас в теме
(24) Чаще всего их просто нет) Но работать как-то нужно. Что именно вам показалось сложным?
26. nytlenc 271 02.07.18 10:33 Сейчас в теме
(25) по мне, чем ставить столько инструментов, настраивать, изучать, проще и быстрее сразу все реализовать в конвертации данных.
27. olegtymko 100 02.07.18 12:33 Сейчас в теме
(26) в планах вынести общий функционал в конвертацию данных. Только работу с git сервером для группового доступа все равно не убрать)
Оставьте свое сообщение