Оглавление
В чем проблема?
- Нет версионирования правил обмена. Доступный способ это делать - копировать правила обмена вручную.
- Групповая разработка правил мало эффективна. Большие трудозатраты на объединение правил.
- Не ведется учет изменений в удобной форме. Нет общего сервиса для просмотра истории изменений.
Как решить?
Для решения проблем, связанных с разработкой и сопровождением правил обмена, можно использовать систему контроля версий Git.
Git
Git - распределённая система управления версиями. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года.
Википедия https://ru.wikipedia.org/wiki/Git
Если говорить простыми словами, Git - это консольное приложение, которое умеет отслеживать и фиксировать изменения в файлах. Git хранит данные проекта в виде наборов слепков проекта. При каждом фиксированном изменении (commit) Git сохраняет текущую версию проекта в виде слепка текущего состояния файлов на момент фиксирования изменений. Также Git может хранить несколько версий наборов слепков - этот механизм называется ветвление.
Более подробно о Git можно прочитать на официальном сайте.
Для локального просмотра изменений я использую Github desktop. Есть и другие клиенты Git, например:
- Sourcetree от Atlassian;
- Visual studio code. В этом редакторе есть функционал по работе с Git;
- Gitahead и т.п.;
Выбор клиента Git дело вкуса и привычек.
Git flow
При помощи подхода git flow можно упорядочить работу с ветками. Для каждого вида работ отводится отдельная ветка. В общих случаях это:
- master - содержит последнюю актуальную рабочую версию проекта;
- feature - ветка для нового функционала. Сливаем изменения в ветку develop;
- develop - содержит все feature. Сливаем изменения в ветки release или master;
- release - ветка с изменениями из develop и hotfix. Сливаем с веткой master;
- hotfix - ветка для исправления ошибок. Сливаем с ветками develop или master;
Всю разработку ведем от ветки develop. Каждое изменение фиксируем как feature (новый функционал) или hotfix (ошибки), в зависимости от ситуации. При внедрении в рабочую систему делаем слияние с веткой master. Более подробнее можно почитать "Шпаргалка по git-flow".
Продолжаем дальше
Все сводится к тому, что становится трудно ориентироваться в изменениях файла 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С).
Скачиваем дистрибутив с официального сайта 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, можно проверять правила обмена на базовых тестах, например та же самая проверка синтаксиса.
