Проблематика (Как я до этого дошел)
Когда я начал вплотную заниматься разработкой правил обмена на проекте, мне захотелось версионировать правила, чтобы видеть историю изменений. На первых парах я выгружал в Git просто файлы правил целиком, как есть, даже без доработок, которые предлагал в своей статье Станислав Ганиев.
Однако это было несерьезное решение, версионировать и работать с одним огромным файлом такая себе затея. И тем более, когда к разработке подключился коллега, было решено делать декомпозицию правил на структуру папок и файлов, чтобы получился полноценный репозиторий проекта с файлами xml и bsl.
На ИнфоСтарте уже есть несколько разработок на эту тему, от:
- Никиты Коротаева со скриптами на OScript;
- Олега Тымко и его Gitrules;
- Александра (tambu) с обновлением для КД и использованием Gitrules.
Это все очень крутые инструменты, но они требуют изучения и установки дополнительных компонентов, по крайней мере OneScript. Хотелось взять инструмент для простого 1Сника, который сможет запустить его в любой базе КД 2.1, т. е. в виде внешней обработки.
Такого инструмента не нашел, поэтому решил сделать сам. Ну как, сам, взял за основу проект Никиты Коротаева, и превратил код OneScript в обычный 1С. Благо, языки почти идентичны, чтобы запустить обработку в первый раз, пришлось изменить несколько строк. Дальше уже пошла работа над удобством использования и разные усовершенствования. Что получилось в итоге расскажу дальше.
Интерфейс Обработки
Основное (и единственное) окно программы представляет собой таблицу с добавленными конвертациями. Настройки сохраняются, поэтому можно добавить нужные правила один раз и навсегда. Напротив каждой конвертации вы указываете путь, куда выгружать /откуда загружать разобранные правила.
Ну и тут же в строке есть кнопки Выгрузить в папку и Загрузить из папки. Кстати, не смог сделать, чтобы кнопки были активны всегда, а не только при нажатии, почти не работал с обычными формами. Может, кто-то подскажет, можно ли сделать как-то лучше?
Внизу еще есть галка Добавлять описание параметров..., которая включает одну мою доработку, о ней подробнее расскажу в следующем разделе.
Отличия от исходного инструмента
В исходных скриптах Никиты я сделал несколько доработок:
- Папки и файлы, отвечающие за конвертацию свойств, выгружались просто по номерам, было неинформативно, добавил в имена еще наименования правил.
- Увеличил количество сериализуемых обработчиков событий.
- Файлы алгоритмов называются по теперь по имени алгоритма, а не просто Текст, чтобы тоже повысить информативность.
И последнее, что касается как раз галки из интерфейса обработки. Добавил возможность выгрузки в файлы bsl обработчиков описание параметров, чтобы было удобнее работать во внешних редакторах (VS Code, Sublime...), были подсказки, не надо было лезть в справку за пояснениями. Вот пример описания для обработчика перед выгрузкой объекта:
#Область Параметры
#Если Клиент И Сервер Тогда
Отказ = Ложь; // Булево. Если установить значение Истина, то выгрузка объекта производится не будет
Параметры = Новый Структура(); // Структура, в которой хранятся переменные доступные во всех обработчиках
ИмяПКО = ""; // Строка. Имя правила конвертации объектов, указанное по умолчанию в правиле выгрузки данных. При
// выгрузке конкретных объектов может быть изменено
Правило = Неопределено; // ссылка на данное правило выгрузки данных
ВходящиеДанные = Неопределено; // произвольные вспомогательные данные, инициализированные в обработчике «Перед
// обработкой» правила выгрузки данных как ИсходящиеДанные.
ИсходящиеДанные = Неопределено; // произвольные вспомогательные данные, передаваемые правилу конвертации объекта.
// В обработчиках ПКО данная информация будет доступна как переменная ВходящиеДанные
Объект = Неопределено; // Произвольный. Выгружаемый объект. Может быть переопределен или назначен непосредственно
// в обработчике.
КонецЕсли;
#КонецОбласти
Вынес этот функционал в отдельную настройку, потому как вам это может и не нужно, а такое описание в каждом обработчике будет занимать много места.
Варианты использования
1. В первую очередь, конечно, этот инструмент делался для версионирования и совместной разработки через Git. Командная разработка с его применением выходит на новый уровень: не нужно постоянно договариваться о совместных доработках, заниматься сложным переносом и объединением, бояться потерять свои наработки. В качестве гит-клиента я использую SourceTree, мне нравится его графический интерфейс.
2. Можно выгружать тексты обработчиков в SonarQube или другие системы для контроля качества кода.
3. Также можно открыть всю папку с правилами или отдельные файлы в таких редакторах как VS Code или Sublime Text, и производить, например, удобный поиск по всем правилам. А с установленным плагином BSL LS можно редактировать тексты с автодополнением, подсказками и проверками.
4. Еще отлично может помочь Консоль кода на основе Monaco от salexdv. Например, вы открываете файл обработчика после загрузки документа в этой консоли, запущенной в базе-приемнике. Тогда у вас работает не только подсказка ввода по ключевым словам, но и вы находитесь в контексте конфигурации: будут видны общие модули, реквизиты объектов, конструктор запросов и т.д.
Процесс совместной разработки
Расскажу кратко о процессе, который мы используем при командное работе с правилами. По сути, это почти классический Gitflow.
- В базе КД2 есть, как минимум, следующие варианты правил: рабочие, а также отдельные для каждого разработчика.
- В гите есть две постоянных ветки: master, где лежат полностью проверенные рабочие правила и develop с правилами, по которым закончена разработка.
- Когда разработчик начинает делать новую задачу, он "отпочковывается" от ветки develop, создает свою feature-ветку с именем задачи.
- В этот момент в его локальной папке репозитория лежат разобранные правила из ветки develop.
- С помощью Обработки в КД2 разработчик загружает правила из файлов в свою копию правил конвертации.
- Начинается сама работа над правилами. В процессе работы можно делать промежуточные коммиты в feature-ветку выгружая правила через Обработку. В гит-клиенте можно посмотреть изменения и сделать коммит с комментарием.
- Когда разработка по задаче закончена, делается последний коммит и происходит слияние feature-ветки в develop. Лучше использовать классический merge, с коммитом, даже если возможен fast-forward, т. е. когда изменений в develop не было. Если происходят какие-то конфликты в доработках, надо будет их разрулить в этот момент, однако из-за разделения на множество отдельных файлов, их вероятность сильно падает.
- Когда совместно разработанные правила проверены и пора обновлять рабочие, происходит слияние ветки develop в master, аналогично предыдущему пункту. Правила из ветки master через Обработку загружаются в рабочие правила в КД2 и вставляются в продуктивные базы.
Заключение и благодарности
Буду рад, если этот инструмент кому-то пригодится в работе. Жду замечаний, пожеланий по обработке
Отдельное спасибо хочу сказать:
- Никите Коротаеву за сам исходный инструмент,
- Антону Иванову как альфа- и бета- тестеру обработки, за подсказки и советы.
Репозиторий на GitHub: https://github.com/KonstantinHeinrich/ConversionRulesLoader
Вступайте в нашу телеграмм-группу Инфостарт
