Решили мы как-то подружить 1С (и себя) с GIT. Основной задачей этой дружбы является анализ истории объектов, быстро найти, "откуда ноги растут" той или иной строчки кода. Есть желание попробовать Git-flow в контексте 1С. Но, на данном этапе, нужно было перегрузить модули различных конфигураций 1С с комментариями из хранилища в GIT.
На данный момент есть несколько разработок, позволяющих это сделать
- Gitter от rtmn, - конфигурация для автоматизации процесса выгрузки изменений из хранилища 1С в систему версионирования Git.
- gitsync на OneScript от Evil Beaver - представляет собой отдельное (standalone) приложение на 1Script, и предназначено для синхронизации хранилища конфигураций 1С с репозитарием git.
Мы выбрали gitsync, это было субъективное решение, желание поработать с OneScript, более легкое и гибкое решение.
Сначала тестирование проводилось на небольших хранилищах 8.3, все отлично отработало и работает сейчас.
Следующим шагом была выгрузка хранилище на 8.1. Немного подправив скрипты, запустили процесс выгрузки. По примерным расчетам, для переноса данных хранилища в git, потребовалось бы чуть меньше месяца (проекту 8 лет, большая конфигурация, много версий, на 1 commit требовалось около 8 минут). Смирились с производительностью и решили подождать месяц. Но стали возникатоь ошибкой 1с конфигуратора. Не долго разбираясь, решили попробовать написать свой велосипед. Были наработки на C# и python по чтению 1CD и разбору контейнеров(cf)
Получился скрипт, который распаковывает версию и выгружает как есть, за некоторым исключением - формирует нормальные имена файлов, раскладывает данные по каталогам.
Спасибо
- awa за описание формата файлов 1cd, утилиту tool_1cd и помощь в понимании формата хранения данных хранилища.
- Evil Beaver за описание формата файлов конфигурации (CF, EPF, ERF), OneScript
- Infactum за то что натолкнул на идею использовать python
Плюсы:
- скорость - 1 commit ~ 0,7 сек, выгрузка всей истории хранилища(4600 версий) заняла примерно 1 час, без выполнения git -commit 22 сек.
- эстетическая - нет дополнительных окон (конфигуратор, tool_1cd, cmd)
Минусы:
- "обратно не засунешь" - нет возможности собрать из выгрузки cf или загрузить в базу (но у нас не было такой задачи),
- трудно читаемое описание объектов - объекты выгружаются как есть (в скобочном формате "{"), а не в XML (опять же, задача была быстро выгрузить код)
Итог: данное решение подходит, если хранилище на 8.1/8.2, если основной целью выгрузки является код.
8.3 умеет выгружать конфигурацию в XML, тут лучше подойдет gitsync на OneScript.
Исходники выложены на GitHub и на своем Git-сервере, кто хочет помочь, присоединяйтесь.
Требования:
Сценарий использования:
- Создаем файл настроек
[LOG] level = ERROR file = %%Y-%%m-%%d.log [BASE] store = Путь к файлу хранилища local_repo = Путь к локальному каталогу репозитория remote_repo = URL удаленного репозитория
- Запускаем для создания репозитория и служебных файлов.
python rup.py init <файл настроек>
- Настраиваем соответствие пользователей и пользователей GIT в файле <Каталог локального репозитория>\authors.cs
- Запускаем для выгрузки истории
python rup.py export <файл настроек>
