Работаем с GIT без хранилища и EDT

В этой статье я разберу, как «скрестить ежа с ужом» – интегрировать Git в разработку на 1С, не покидая привычный Конфигуратор.

Речь пойдет в основном о версионировании кода конфигураций, расширений, отчетов.

Версионирование необходимо, чтобы знать, что, когда и зачем мы изменили, оно дает возможность откатиться к любой точке истории разработки и проследить, кто, что и с какой целью изменял.

Хранилище vs Git

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

В отличие от хранилища конфигурации, Git позволяет хранить не только код, но и все сопутствующие артефакты: тексты, тесты, скрипты развертывания / сборки и прочее.

Git дает возможность работы с ветками, интеграцию с задачами, предварительный анализ доработок до попадания в основную версию конфигурации, но требует обучения и не имеет прямой интеграции с конфигуратором.

Git позволяет сделать ветку под каждую задачу, применять различные паттерны ветвлений (Git Flow, GitHub Flow), создавать запросы на слияние (pull/merge requests), которые дают нам возможность предварительно проверить работу программного продукта, и проводить code review (автоматическое и ручное).

Какие инструменты существуют

Стандартные функции конфигуратора. Можно выгрузить конфигурацию, расширение, обработку в файлы и загрузить из файлов в формате конфигуратора. К сожалению, они обладают невысоким быстродействием, что особенно заметно, если мы работаем с конфигурациями типа ERP, ERP + БИТ.ФИНАНС и прочими «монстрами».

Gitsync/ГитКонвертер. Предполагает гибридную работу: можно работать с хранилищем и при этом автоматически выгружать наши доработки в Git.

1C:Enterprise Development Tools. Решение позволяет работать непосредственно с Git, но требует значительных вложений в оборудование разработчика (особенно для больших конфигураций), а также дополнительных навыков от разработчика, которые нужно еще приобрести.

Инструменты командной строки. Благодаря тому, что для целей конвертации артефактов 1С в различные форматы существуют инструменты командной строки, можно автоматизировать работу – например, использовав скрипты. Я выбрал этот путь решения проблемы.

К артефактам относятся конфигурация, расширение, внешние обработки и отчеты. Формат может быть бинарным (CF, CFE, EPF, ERF), XML и EDT. Источниками доработок могут быть информационная база, хранилище, каталог/файл.

Инструменты командной строки

Для конвертации из формата в формат вендор предусмотрел ряд инструментов командной строки. И этих инструментов больше чем один!

Есть конфигуратор (пакетный режим/агент), утилита управления автономным сервером (ibcmd) и утилиты ring/1cedtcli. Начиная с EDT версии 2024.01 ring исчез и осталась только 1cedtcli.

У каждого инструмента свои параметры командной строки разной степени сложности, а также свои допустимые входные/выходные форматы. Единого инструмента нет, поэтому необходимо их изучить, держать в голове и пытаться как-то использовать.

Командная строка в конфигураторе имеет большой массив параметров, которые необходимо помнить.

В ibcmd свой массив параметров.

1cedtcli конвертирует только между форматом выгрузки конфигуратора и форматом EDT. Каждый из них имеет свой набор параметров. Все это достаточно тяжело запомнить.

В один прекрасный момент мне захотелось вести один небольшой Pet-проект в нескольких форматах (EDT/ VS Code/ Конфигуратор). Я решил написать небольшой BAT из всех утилит командной строки, тем самым собрав простой конвертер для личного использования. В конечном счете получился целый набор утилит.

Утилиты принимают на вход либо конфигурацию, либо расширение, либо внешний отчет / обработку. Допускается использовать не просто CF/CFE, а либо информационную базу, либо CF, либо разобранные в XML или EDT файлы.

Решение реализовано в виде набора batch-скриптов (BAT), так как первоначально планировалось сделать маленький батничек. В результате получилось несколько маленьких батничков на полторы тысячи строк.

Два основных параметра скриптов: путь к исходникам и путь к результату. Иногда необходимо указать дополнительные параметры, которые «прячутся» в специальном файле, в котором указаны переменные окружения: версия EDT/платформы и базовая конфигурация/информационная база, относительно которой будут разрешаться ссылки на объекты метаданных при конвертации.

Ранее эти скрипты конвертации были описаны в статье //infostart.ru/1c/tools/1909958/.

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

Для выгрузки/загрузки исходников одним нажатием кнопки разработчику потребуется один раз настроить в конфигурационном файле базу, в которой ведется работа. Также существует отдельная утилита для подготовки к обновлению конфигурации вендора.

Подготовка репозитория

Можно просто скопировать свой репозиторий, вставить в него скрипты или хранить их отдельно. Однако такое решение нежелательно.

Для подготовки репозитория рекомендую создать подмодуль, ссылающийся на основной репозиторий разработки скриптов (https://github.com/arkuznetsov/1CFilesConverter). Далее создать отдельный каталог для скриптов и скопировать в него содержимое каталога примеров (examples).

Структура вашего репозитория и окружение разработки могут быть любыми, поэтому скрипты проще скопировать и доработать под конкретные нужды.

Каждый разработчик размещает у себя файл .env. Этот файл содержит настройки взаимодействия с основной базой разработки, в т.ч. секреты, такие как логины, пароли и прочие токены доступа, поэтому он добавляется в .gitignore, не индексируется и хранится строго локально.

Ветки GIT

При разработке рекомендую использовать подход GitFlow:

• master — для стабильных релизов;

• develop — основной ствол разработки. Все изменения попадают в него через pull request;

• feature — по одной ветке на задачу;

• release — ветки для подготовки релизов;

• hotfix — ветки для срочных исправлений.

Специфичные ветки:

• base1c (название на ваше усмотрение) — для исходной конфигурации поставщика в исходном виде. Обеспечивает наследственность и возможность автоматизированного обновления.

• storage — для синхронизации с хранилищем конфигурации 1С (через git sync). Подойдет командам, использующих хранилище.

Работа с доработками

Основные шаги при выполнении доработок:

• Из ветки develop создаем feature-ветку для выполнения доработок,

• Запускаем скрипт конвертации исходников в информационную базу разработки,

• Выполняем требуемые доработки в конфигураторе,

• Выгружаем измененную конфигурацию из конфигуратора обратно в исходники (в созданную feature-ветку),

• Актуализируем feature-ветку из ветки develop (если там были изменения), попутно решая возникающие конфликты,

• Отправляем доработки на Git-сервер и создаем запрос на слияние (merge/pull request).

При создании запроса на слияние автоматически запускается сценарий сборки, который может выполнять анализ запроса на слияние, синтаксический контроль конфигурации/файлов и минимальные автоматизированные тесты.

Проводится code review. После успешного прохождения всех проверок запрос на слияние принимается, и изменения попадают в ветку develop.

Для перехода к новой задаче необходимо удалить feature-ветку, обновить локальную develop, загрузить исходники в базу и повторить цикл.

При необходимости можно переключаться между незавершенными задачами:

• Фиксируем (commit) незаконченные изменения в текущей feature-ветке с помощью скрипта,

• Переключаемся на feature-ветку новой задачи,

• Выполняем стандартный цикл разработки (см. выше),

• Возвращаемся к исходной задаче.

Главная опасность — забыть выгрузить изменения из конфигуратора перед переключением задачи/загрузкой исходников или большое количество изменений в develop. Эти ситуацию необходимо контролировать и по возможности не допускать.

Также рекомендуется регулярное резервное копирование базы разработки.

Утилита ibcmd позволяет выполнять операции без закрытия конфигуратора. Однако такой подход не рекомендуется. Если не закрыть конфигуратор перед загрузкой исходников (ibcmd) и начать разработку, возможны критические ошибки, приводящие к повреждению базы.

Рекомендуется всегда выходить из конфигуратора перед загрузкой или после загрузки конфигурации из файлов выполнить закрытие, а затем открытие конфигурации.

Важно отметить, что большое количество изменений в основной ветке разработки (develop) требует выработки четких правил слияния и разрешения конфликтов.

Для достижения максимальной скорости конвертации артефактов рекомендуется использовать утилиту управления автономным сервером (ibcmd) вместо пакетного режима конфигуратора.

По моим собственным замерам (на ERP) конвертация с использованием пакетного режима конфигуратора занимает 15-40 мин, при использовании ibcmd время конвертации сокращается до 4-10 мин.

На текущий момент утилита ibcmd находится в статусе предварительной версии, поэтому могут попасться проблемные релизы.

Известные ошибки утилиты управления автономным сервером (ibcmd), например, такие как зависания, потери при конвертации и т.п. документированы и часть из них уже исправлена вендором.

Ограничения и рекомендации

Используйте только управляемые формы. Работа с обычными формами через этот цикл стандартными средствами затруднена.

Строго придерживайтесь стандартов разработки и внесения изменений. Например, можно посмотреть тут: https://github.com/arkuznetsov/some1cdocs/blob/master/docs/changing-1c-conf.md.

Используйте новые версии 1С:Предприятие. Для скорости операций рекомендуется платформа 1С:Предприятие не ниже версии 8.3.20, предпочтительно 8.3.24 или новее. Для распараллеливания процессов используйте серверные базы данных, так как при работе с файловыми базами параллельная работа невозможна.

Очищайте рабочий каталог автономного сервера перед операциями.

Снимайте с поддержки конфигурацию поставщика перед работой — это уменьшает размер репозитория и снижает вероятность возникновения проблем с ibcmd (скрипты позволяют вернуть поддержку).

Внешние обработки и отчеты

Внешние обработки и отчеты конфигуратор по умолчанию сохраняет в бинарном виде (.epf). Для сохранения обработки / отчета в виде исходников требуется вручную выбрать формат XML в диалоге сохранения.

Вариант автоматизации сохранения обработок и отчетов в исходники — использование утилиты Watchman. Это инструмент от компании M**a, который отслеживает изменения в каталоге с файлами и позволяет настроить выполнение различных действий.

В нашем случае мы можем отслеживать изменения бинарных файлов обработок и отчетов и автоматически запускать скрипт конвертации в XML при сохранении (Ctrl+S) из конфигуратора. Это обеспечивает постоянную актуальность исходников в XML для просмотра и правки перед помещением в Git.

Обновление конфигурации поставщика и хранилища

Ранее в статье //infostart.ru/1c/articles/1736541/ рассказывалось как можно использовать git при подготовки обновления доработанных конфигураций на новую версию от вендора.

Использование скриптов органично вписывает процесс обновления в общий процесс разработки.

В общем виде порядок следующий:

• В служебном каталоге репозитория (например, base1c) размещается файл обновления (.cf);

• Запускается скрипт подготовки обновления (prepare_update.bat);

• В результате выполнения скрипта получаем обновленную ветку поставщика и результат слияния новой конфигурации поставщика с нашей доработанной конфигурацией в ветке, указанной в настройках;

• Разработчикам остается только разрешить конфликты слияния.

Для команд, использующих хранилище, выгрузка хранилища производится с использованием gitsync в ветку storage. Далее процесс происходит по аналогии с процессом обновления конфигурации поставщика.

Если разработка ведется параллельно и в хранилище и путем непосредственного изменения исходных файлов, то важно возвращать результаты слияния обратно в хранилище, чтобы избежать усложнения будущих синхронизаций.

Данный подход позволяет:

1. Продолжать разработку в конфигураторе 1С, получать исходники в Git по требованию;

2. Ускорить импорт/экспорт благодаря ibcmd;

3. Использовать любой редактор кода (VSC c BSL LS);

4. Применять все преимущества Git (ветвление, code review);

5. Версионировать обработки/отчеты и упростить обновление поставщика. Автоматизация обеспечивается скриптами.

Что в планах

• Перенос реализации скриптов на OneScript для кроссплатформенности (включая Linux);

• Добавление работы с форматом хранилища 1С (прямая выгрузка/загрузка в исходники, включая инкремент);

• Интеграция функциональности конвертации расширений в конфигурацию;

• Реализация вспомогательных задач, таких как автоматическая сортировка метаданных по префиксам/алфавиту для уменьшения конфликтов слияния.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.