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

27.06.2018 46 Comments

Практика программирования, Разработка

, ,







    image24.png
    image41.png
    image20.png
    image34.png
    image31.png
    image27.png
    image51.png

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

Оглавление

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

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

Как решить?

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

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

Related Posts

46 Comments

  1. kembrik

    Отличная статья, спасибо, в копилку однозначно. А есть ли аналог GitRules для красивого «схлопывания» процедур и функций в Общем модуле «МенеджерОбменаЧерезУниверсальныйФормат» для Кд 3.0?

    Reply ↓
  2. olegtymko

    (1) Спасибо.

    Есть один из проектов на осень, где я буду копаться в EnterpriseData. Я думаю, что у gitrules появиться возможность это делать. Можете написать issue здесь: https://github.com/otymko/gitrules/issues. Может кто-то раньше меню доберется и доработает=)

    Reply ↓
  3. olegtymko

    (3) В каждом подходе есть свою плюсы и минусы. Для «быстрого старта» правила обмена очень даже подходят. Тем более при небольшой сложности все накликивается мышкой)

    Reply ↓
  4. AntonSm

    Отличная статья. Спасибо за наводку на gitrules.

    Reply ↓
  5. olegtymko

    (5) Gitrules писался в попытке представить правила обмена как выгрузку конфигурации в xml. Есть определенные ограничения в функционале, которые со временем должны решиться.

    Reply ↓
  6. gorakh

    (3)В КД2 есть обмен через COM.

    Reply ↓
  7. acanta

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

    Reply ↓
  8. fishca

    Пожелания:

    1. Добавить ссыль на https://github.com/otymko/gitrules

    2. Сконцентрироваться на описании gitrules

    Reply ↓
  9. olegtymko

    (8) конфигурации на БСП? Если да, то можно почитать здесь https://its.1c.ru/db/pubcloud1c/content/81/hdoc.

    Reply ↓
  10. olegtymko

    (9) пожелания приняты)

    Вообще в планах было написать отдельную статью о Gitrules и о расширении для КД 2.х, помогающее версионировать правила.

    Reply ↓
  11. olegtymko

    (7) если рассматриваем БСП, то там есть обмен com с использованием правил обмена. Но в плане разработки ничего не меняется)

    Reply ↓
  12. herfis

    Не могу найти, но точно у кого-то читал ранее про групповую разработку правил обмена через git. Только не помню, как там решалась (и решалась ли) задача декомпозиции правил. С gitrules это превращается в полноценный инструмент. Плюс за подробный мануал.

    Reply ↓
  13. sisdrou

    Идея интересная…. Как это будет работать с большими, объемными конфигурациями. Типовой механизм достаточно долго сравнивает изменения, если тут будет все происходить многократно быстрее, тогда — Да. А так.., это просто забавная фича. Внести ее в работу будет достаточно сложно, с учетом поправки на трафик с депозитарием ..

    Reply ↓
  14. olegtymko

    (13) вот статьи в этом направлении https://infostart.ru/public/683631/ и https://infostart.ru/public/632457/

    Reply ↓
  15. olegtymko

    (14) проверял на правилах обмена более 30 тыс. строк. Не особо долго ждал. Могу сделать замер, если вам интересно) Вообще если делать сравнение на git хостингах — это происходит довольно так быстро.

    Reply ↓
  16. xzfantom

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

    А насчет тестирования — почему бы не использовать GitLab Runner, раз всё равно используется гитлаб? И сразу в проекте будет отображаться прошёл/не прошёл.

    Reply ↓
  17. olegtymko

    (17) Можно, пока думаю над вариантами. Ближе конечно Jenkins т.к. его использую для gitsync и запуска тестов.

    Reply ↓
  18. sisdrou

    (16)

    это происходит довольно так быстро

    Спасибо.. попробуем.

    Reply ↓
  19. stas_ganiev

    Спасибо за статью, жирный плюс!!!

    Предлагаю объединить усилия в продолжении проекта: https://github.com/ha1s/ConversionPlus. На анонсированную задумку там уже ишью лежит :))

    Reply ↓
  20. olegtymko

    (20) Хорошее решение! Посмотрю ваш проект в отпуске)

    Reply ↓
  21. olegtymko

    (20) где можно почитать о функционала вашего проекта?

    Reply ↓
  22. stas_ganiev

    (22) Ссылка уже была: https://infostart.ru/public/632457/. Сейчас на gitHab лежит данная версия, дальнейшие планы развития отражены в ишузах. За работу возьмусь в ближайшие дни

    Reply ↓
  23. nytlenc

    Мы не ищем легких путей….

    Reply ↓
  24. olegtymko

    (24) Чаще всего их просто нет) Но работать как-то нужно. Что именно вам показалось сложным?

    Reply ↓
  25. nytlenc

    (25) по мне, чем ставить столько инструментов, настраивать, изучать, проще и быстрее сразу все реализовать в конвертации данных.

    Reply ↓
  26. olegtymko

    (26) в планах вынести общий функционал в конвертацию данных. Только работу с git сервером для группового доступа все равно не убрать)

    Reply ↓
  27. STivO

    У себя настроил под одного клиента, у которого 60 правил обмена. Версионность правил уже использовал раннее через git, но с gitrules намного удобнее стало. Осталось механизм взаимодействия с git напрямую из КД приделать для полного счастья. Пришлось кончено повозиться с длиной полного имени файла.

    Reply ↓
  28. olegtymko

    (28) Длина полного имени файл — это прям боль) Как с длиной решили вопрос?

    p.s. потихоньку пилится расширение для кд 2.0.

    Reply ↓
  29. Serg O.

    git версионирование сравнивает построчно… И при добавлении 1 строки вначале текста меняется N строк всего. Разложение на объекты хорошо, но как обратно собрать версию месячной давности например? Обычное сохранение правил в отдельные файлы и 1С стандарная сравнение файлов иногда лучше (и привычнее) работает… Переход на git синхронизацию неплохая идея, сама 1С уже на EDT с ним работает. Для oScript тоже уже масса автоматов прописана… но все равно это китайская грамота до сих пор для многих. Нет универсального клиента для git и это жаль

    Reply ↓
  30. STivO

    (29) Пока временно изменил модуль РазобратьПравилаОбмены.os. С помощью команды «subst» создается виртуальный диск, который сопоставляется к каталогу, в который в данный момент разбираются правила. Пробовал еще через команду robocopy обходить 260 символов, всё отрабатывало, но медленно. Еще были варианты в интернете, но пока не пробовал их.

    Reply ↓
  31. olegtymko

    (31) Да уж, решение не из простых =)

    Reply ↓
  32. olegtymko

    (30) Если мне нужны правила обмена, допустим которые я коммитил в начале июня, я переключаюсь git checkout на нужный commit и беру файл xml. Для сбора правил из разложенных файлов и папок можно также воспользоваться gitrules assembly. В качестве клиента я использую github desktop — обычно мне его функционала хватает, для разработки и поддержки правил обмена.

    Reply ↓
  33. STivO

    Когда ты делаешь коммит определенного правила обмена, а разбираются у тебя все, что есть в каталоге не правильно) и при этом исходники надо отдельно коммитить. В механизме precommit1c, когда ты делаешь коммит определенной обработки, то у тебя разбирается сама обработка и исходники сразу же помещаются в тот же коммит. Так же, когда делаешь установку gitules через консольную команду, то содержимое файла pre-commit в папке hooks затирается. В общем есть над чем поработать)

    Reply ↓
  34. olegtymko

    (34) Всегда можно добавить issue на github)

    Reply ↓
  35. infosoft-v

    Спасибо за удобный инструмент.

    Reply ↓
  36. Korolev

    Благодарю, полезно!

    Reply ↓
  37. Lancelot-2M

    Какой смысл сравнивать все через git? Ну если только ради спорта. По настоящему дельной была бы разработка подсистем блокировки правил внутри кд для групповой разработки(что легко), сравнения и слияния(что интересно) и копирования вместе с конфигурациями с прямо записью в таблицы данных (что нудно, но необходимо для порождения новых версий больших правил обмена между большими конфигурациями).

    Reply ↓
  38. olegtymko

    (38)

    сравнивать все через git? Ну если только ради спорта. По настоящему дельной была бы разработка подсистем блокировки правил внутри кд для групповой разработки(что легк

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

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

    Reply ↓
  39. artkor

    Извините, а в таком случае уже ничего поделать нельзя?

    START precommit gitrules
FILE: D:
uПравилаОбменаДанными(БП__УТ)(1).xml
D:
usrcПравилаОбменаДанными(БП__УТ)(1).xmlПравилаКонвертацииОбъектовДокументыФинансыДвижениеДен­ежныхСредствДвижениеБезналичныхДенежныхСредствПоступлениеБ­езналичныхДенежныхСредствКонвертацияВалютыПоступлениеПБДС_­ПоступленияОтПродажиИностраннойВалюты
{Модуль C:Program Files (x86)OneScriptlibgitrulessrccoreМодулиРазобратьПравилаОбме­на.os / Ошибка в строке: 157 / {Модуль C:Program Files (x86)OneScriptlibgitrulessrccoreМодулиРазобратьПравилаОбме­на.os / Ошибка в строке: 154 / Внешнее исключение (System.IO.PathTooLongException): The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.}}
Выполнено с ошибками, см. выше.
    Reply ↓
  40. olegtymko

    (40) Можно например отключить ограничение длины пути в windows 10.

    Reply ↓
  41. kembrik

    (40)

    РазобратьПравилаОбме­на.os

    РазобратьПравилаОбме<wbr>­на.os

    Латиницей бы переназвать

    Reply ↓
  42. artkor

    (41)

    отключить ограничение длины пути в windows 10

    в win 2016 никакие танцы с бубнами вокруг групповых политик не помогли, пришлось названия подрезать. В целом пакет у Вас мегаполезный — как без этого раньше жил 😉

    Reply ↓
  43. tambu

    (39) Добрый день! Спасибо за статью и за GitRules! Мы у себя начали опытную эксплуатацию.

    Если позволите, несколько вопросов:

    1. Правильно я понял, что с правилами регистрации GitRules не работает? Он их раскладывает, но при попытке собрать обратно ругается на неправильный тип.

    2. Порой GitRules ругается на длинные пути к файлам, мы пока это обошли используя subst. Но может статься, что в самих правилах будет или большая вложенность или длинные названия. Можно эту проблему как-то «победить»?

    3. У нас много 1Сников, не знакомых с GIT и пришлось все нужные вызовы команд (клонирование, создание веток, commit, push..) прикрутить в саму конвертацию данных. Если Вы позволите, я после опытной эксплуатации опубликую статью об этом.

    Reply ↓
  44. olegtymko

    (44)

    1. Сборка правил регистрации пока у меня в тесте лежит. В этом месяце думаю добавлю эти изменения в основной проект.

    2. По длинным путями проблема из-за windows + oscript. Кто-то решал проблему на win10 включение длинных путей.

    3. Да, конечно. У нас самих кстати КД доработана, чтобы получать правила с GIT, фиксировать локально изменения, отправлять на удаленный репозиторий =)

    Reply ↓
  45. tambu

    (45) Спасибо за оперативный ответ 🙂

    Вы сами не будете свою КД выкладывать? Не хочу «дорогу перебегать» 🙂 А так, у нас примерно такой же путь получился, сложные команды (откаты, ребейс, просмотр изменений и т.п) не реализовывали. Только то, что нужно в линейном бизнес-процессе разработки. Получили правила, создали новую ветку, коммитим, когда пора пушим на удаленный репозиторий. Запросы на слияние уже в веб интерфейсе гитЛаба.

    Reply ↓
  46. olegtymko

    (46) Планировал, но не раньше декабря. Выкладывайте свою версию, я думаю многим это будет полезно!

    Reply ↓

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *