В тех статьях, которые уже есть, описывается полная цепочка. Думаю своими статьями снизить порог входа в достаточно важную часть разработки.
Вводные
1. Веду разработку через расширения и внешние обработки.
2. Использую Хранилище конфигурации один контур, в комментариях указываю номера задач.
3. С помощью GitSync вручную из хранилища конвертирую в Git, который связан с трекером, можно поставить по расписанию.
4. Рабочая база подключена к хранилищу только на чтение.
Сталкиваюсь с ограничениями:
1. Не переключиться на решение срочной задачи, если есть наработки по текущей.
2. Если отправил в хранилище изменения структуры метаданных, то патч срочно уже не перенести (пользователей среди рабочего дня выгоняем только в аварийных случаях).
3. Потенциальный перенос наработок в рабочий контур через "сравнение/объединение" занимает много времени.
4. Жесткая привязка по доступу к хранилищу конфигурации
5. Проблема с доставкой наработок если у клиента нет хранилища (дубли файлов на локальном месте и на сервере)
Вариант решения:
1. Сконвертировать хранилище/конфигурацию в формат XML или EDT и перенести в GIT
2. Сделать автоматическую сборку cf/cfe и доставку до сервера клиента.
3. Осваивать групповую разработку через git.
Описание форматов и конвертации:
1. "Рабочий", в базе данных , получаем из CF "1cv8 DESIGNER /LoadCfg" либо из XML "1cv8 DESIGNER LoadConfigFromFiles"
2. Упакованный cf/cfe, получаем выгрузкой из базы данных "1cv8 DESIGNER /DumpCfg"
2. XML, получаем выгрузкой из базы 1cv8 "DESIGNER /DumpConfigToFiles" либо выгрузкой из проекта EDT "ring edt workspace export"
3. Проект EDT, схож по структуре с XML, но с дополнительными сервисными описаниями, получаем из XML "ring edt workspace import"
При работе с GIT сравнивать ветки разработки через интерфейс можно только с помощью EDT (смотреть различия в XML сложнее).
При конвертации из CFE в XML при использовании пустой базы конфигурация БД не затрагивается и не слетают "привязки" к базе "родителю" расширения.
Про EDT
Внешне идея хорошая, но:
1. Потребляет очень много ресурсов процессора и дискового пространства.
1.1 В "workspace.metadata.pluginscom._1c.g5.v8.bm.core" судя по объему дублируется/кешируется проект.
2. Нет видео с примерами работы, только со скриншотами от УЦ1, многие "сложные" места просто не показываются.
3. Не стабильно работает импорт/экспорт, периодически при запуске выдает пачку ошибок. Из XML в EDT загружаются не все данные, например <Vendor> из расширения загружен не был, дальше разбираться не стал.
3.1 При конвертации расширения из XML в EDT используется переменная "base-project-name", если привязка не прошла, то процесс не останавливается и в логах непонятно где смотреть ошибку.
После нескольких проб решил использовать XML формат. В часть проектов пишу в одного, по сути нужна сборка и доставка до клиентских серверов (замена хранилища конфигурации развернутая в сервисе). При групповой разработке буду учится/делать слияния, если видели статьи по методике применительно к метаданным и формам то буду раз увидеть в комментариях, применительно к коду инструментарий уже есть.
Перенос из конфигурации/хранилища в Git
Небольшое отступление:
Для переноса в формат EDT возможно использовать ГитКонвертер, https://github.com/1C-Company/GitConverter/tree/develop. Ссылка на dev версию потому что в ней уже реализована выгрузка расширений. Из этого проекта почерпнул блоки по специфике формирования bat для работы с git.
Для переноса из хранилища самое лучшее это https://github.com/oscript-library/gitsync. Использовать хранилище в повседневной работе для меня избыточно, буду грузить напрямую в GIT, для этого реализовал инструмент в виде отдельной конфигурации. Для работы с целевой базой нужно выйти из конфигуратора. Инструмент пишется в том числе как прототип для TurboConf, если сложится хорошо, то будет подобное в самом конфигураторе.
Ссылка на проект https://gitlab.com/malikov-pro/1c_git_worker. Для скачивания сборки нужно пройти по ссылке:
Скриншот с ссылкой
Что сейчас умеет:
1. Фиксировать настройки связи базы с локальным git репозиторием.
Страница настроек
2. Запускать основные команды
Страница команд
3. Просматривать что именно запускалось в командной строке и результат запуска на форме справочника последние запущенные, всю историю храню в РС.
Журнал
Для сравнения используется сборка через временную базу в каталоге tmp проекта. Результат сравнения записывается туда же. Планирую загружать и хранить в журнале команд.
Для работы с репозиторием использую ssh, поэтому логина/пароля в настройках нет.
Прием настройки для SSH
Прием работы:
1. Создаем новую ветку для разработки.
2. Делаем в нее коммиты, смотрим как собралось.
2.1 Если работает нормально то переходим на master ветку и объединяем (сам делаю через merge).
Хорошая документация по workflow https://www.atlassian.com/git/tutorials/comparing-workflows, планирую с развитием инструмента перевести на русский и дополнить спецификой использования с 1С.
Функционал по работе с объединением в разработке.
Сборка:
Реализована за счет gitlab pipeline. Файлы настройки сборки формируются из базы. Проект сам себя собирает. Сборка расширений работает.
В настройках указан тег "windows-dev" для запуска только на отдельно настроенном runner.
Установка: https://docs.gitlab.com/runner/install/windows.html
Регистрация: https://docs.gitlab.com/runner/register/#windows
Для корректной сборки нужно указать переменные проекта: https://docs.gitlab.com/ce/ci/variables/
Для доставки по FTP можно использовать дополнительный bat файл включив его в отдельный этап сборки:
Пример доставки на FTP
Результат:
Возможно вести удаленную разработку с сохранением истории изменений и автоматической сборкой для доставки клиенту.
Благодарю за внимание.
Буду раз дельной критике и информации по работе с git + 1с_xml.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке