Переход на разработку с хранением в Git, часть 1, подготовка репозитория

Публикация № 1127356

Разработка - Групповая разработка - Хранилище

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

Вводные

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\.plugins\com._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.

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. kwazi 400 22.01.20 13:32 Сейчас в теме
https://github.com/marmyshev/edt_git_sync
Это не то же самое? В вашей версии можно без хранилища обойтись насколько я понял.
Правильно я понял, что git используется только как хранилище кода?
2. malikov_pro 514 22.01.20 13:36 Сейчас в теме
(1) Немного разное, мой подход без использования хранилища конфигурации 1С. В идеале в конфигураторе имеем пару кнопок по управлению ветками, пушем наработок и сравнению/объединению после мержа, думаю это реализовано в каком то варианте в EDT, но он на данный момент для меня не применим.
3. kwazi 400 22.01.20 13:41 Сейчас в теме
(2) а можно несколько расширений держать в одном репозитории? У клиента их больше 10-ка в одной базе.
6. malikov_pro 514 22.01.20 14:38 Сейчас в теме
(3) в проекте git создается папка src, в ней под каждое расширение своя папка, без разницы через какой инструмент, хранилище конфигурации под каждое расширение свое.
acanta; kwazi; +2 Ответить
4. Xershi 1020 22.01.20 13:49 Сейчас в теме
Я так понял основная проблема, что у вас франч, и нет времени на организацию инфраструктуры или продумывания архитектуры решения.
Все озвученные минусы отсекаются либо административно, либо продуманным подходом.
Конечно когда шапка горит, то данный подход оправдан, но если задуматься накой так работать?
Ну кроме галки умею юзать гит в резюме существенных плюсов не нашел
Хотя один есть куча клиентов на поддержке и у каждого своя хотелка, которую не внедряют другому без доп оплаты. Но опять же так делают обычно только франчи из=за жадности, независимые разработчики унифицируют все.
7. malikov_pro 514 22.01.20 14:40 Сейчас в теме
(4) Я фрилансер, активно использовал gitsync. Git удобен в том числе и для доставки кода до клиента, разрабатываешь локально, пушишь, пришел к клиенту, получил изменения и применил к базе. С хранилищем конфигурации по сетевой инфраструктуре чуть сложнее.
5. acanta 22.01.20 14:15 Сейчас в теме
Если я правильно понимаю, гит это инструмент для администрирования совместной работы распределенной команды. У франчайзи есть собственный администратор как правило, а за проекты, требующие распределения они не берутся.
8. malikov_pro 514 22.01.20 14:42 Сейчас в теме
(5) Для совместной работы, администрирование и управление поверх, при необходимости. "а за проекты, требующие распределения они не берутся." - по разному, зависит о того кто управляет процессом.
9. kwazi 400 22.01.20 14:44 Сейчас в теме
Я видимо пропустил какое-то важное исследование франчайзи. Или есть какой-то тайный кодекс работы франчайзи... Такой свиток, грааль, который хранится у Нуралиева и его дают прочитать всем новоиспеченным франчам.
10. malikov_pro 514 22.01.20 14:53 Сейчас в теме
(9) Нет не пропустили, просто специфика работы вытекающая из непонимания клиентов и отношению к ним поставщиков, когда нужно "Закрыть проект и подписать листы учета времени", а потом "хоть трава не расти", это подход руководства больше. Пробовал раза три, хватило, перешел во фриланс, хотя как вариант роста +- норм.
11. kwazi 400 22.01.20 16:22 Сейчас в теме
(10)
Это особенность работы по проекту. У проекта есть жесткие сроки и финансовые ограничения. Поэтому и возникают казусы. Клиенты тоже не хотят погружаться в 1С. Говорят: Сделайте нам красиво. Многие фрилансеры тоже так работают. Когда фанфары оттрубили и проектник свалил наступают суровые будни. Рядом только сисадмин, который разводит руками и попаболь.
Но не все так работают. Есть франчайзи, которые расчитывают на долговременное сотрудничество. Вам просто не повезло, наверное.

Не люблю навешивать ярлыки и другим не советую...
12. kolya_tlt 24 21.04.20 14:34 Сейчас в теме
так где собственно переход то и снижение порога входа? я как сидел в конфигураторе и не понимал о чем пишут, так и не перестал понимать.
Resident1C; the1; +2 Ответить
13. malikov_pro 514 21.04.20 20:51 Сейчас в теме
(12)
"так где собственно переход то и снижение порога входа?" - обработка как пример работы с git в контексте 1С.

"я как сидел в конфигураторе и не понимал о чем пишут"
Пока работаешь в одного на одном проекте это не сильно нужно.
Когда начинаешь работать в команде/с внешними клиентами по нескольким проектам, то возникает ряд проблем, часть из которых решаются с помощью git.

Напишите что именно непонятно и какую задачу решаете.
14. the1 601 21.04.20 21:24 Сейчас в теме
(12) +1, тоже заголовку порадовался, а в итоге опять ничего не понял)
Resident1C; +1 Ответить
Оставьте свое сообщение

См. также

История одного проекта обновления

Хранилище v8 УТ11 Бесплатно (free)

История одного проекта обновления, хранилище, групповая разработка.

06.11.2019    5205    vasilev2015    20    

Git для 1С-ника и другие технологии групповой разработки

Инструментарий разработчика Git (GitHub, GitLab, BitBucket) v8 1cv8.cf Россия Бесплатно (free)

У многих специалистов в отношении Git сложились стереотипы, мешающие начать работу с этим прекрасным и удобным инструментом. Почему его не стоит бояться, и чем он может упростить жизнь 1С-никам, рассказал архитектор ГК «Невада» Станислав Ганиев.

28.10.2019    12620    stas_ganiev    16