Решили мы как-то подружить 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 <файл настроек>
Еще один в клуб разборщиков конфы на исходники 🙂
Ссылка на исходники не работает.
Плюс за скорость
Добавьте лицензию к проекту
В целом проект радует. После беглого взгляда рекомендовал бы следующее:
GitPython .
проект . Что мешало просто включить его в качестве зависимости?
— Убрать велосипед git_mng.py. Вместо него есть такая великолепная вещь, как
— Заимствуя чужой код не нарушать лицензию 🙂 Намекаю на мой
— После реализации предыдущих пунктов сделать нормальный setup.py и залить все в pip.
(4) Infactum, GitPython — чтот не взлетел по-быстрому, так что пришлось сделать костыль, а так да, в дальнейшем планируется работа с гитом через него.
по проекту вашему, из него была взята идея и небольшая часть кода, мы боролись за скорость и наше решение выигрывало.
(5) заимствование части кода как бы не отменяет требований лицензии 🙂
А если отложить занудство в сторону, то был бы рад получить более подробное описание относительно того, какие проблемы скорости работы вы встретили и как они были решены. В идеале можно и pull request, но настаивать конечно не могу.
(1) artbear, ссылку поправили, спасибо! И спасибо за интерес!;)
(6) Infactum, хорошо, будем внимательнее:) Чуть позже отпишем по подробностям. Спасибо!
(6) Infactum, по лицензии и возможности pull request позже. мы только после последнего ивента занялись вопросом git и open source:)
Быструю многопоточную разбиралку CF на базе unpackv8 (С++) делал Сергей Батанов (http://infostart.ru/profile/45491/) . Оно как бы хорошо, что вы все наши наработки знаете и пробовали, а все ж теперь есть «еще одна», а не развитие существующих.
А, ну и чего не на гитхабе-то?
Предложение-дополнение Infactum:
1. Делаете пакет «разбиралки» файлов guid.0 из CF на файлы Справочник.ЧтоТоТам.Форма
2. Оформляете как самостоятельный пакет в pip
3. Делаете пакет вот этого вот синхронизатора
4. Подключаете существующий «читатель» 1CD, как зависимость
5. Опять же создаете пакет в pip
6. Переписываете все это на 1Скрипт 🙂
8. Выкладываете на гитхаб.
(10) Evil Beaver, Ссылка куда-то не туда ведет.
В защиту Python (да и любой скриптовой реализации разбора) скажу, что не смотря на всю быстроту C++ необходимость самостоятельно сборки или наличия готовых бинарников под все системы несколько напрягает. Python например работает везде куда только не посмотри, и в большинстве случаев стоит «по дефолту». Кстати никто так и не решился сделать адекватное сравнение скорости работы распаковки/запаковки на Python и C++. В моем субъективном тесте Python версия как минимум работает так же по скорости.
(11) Evil Beaver, плюсую. НУ разве что кроме последнего пункта 🙂
А если надумают выйти на совсем взрослый уровень, то крайне желательно наличие тестов и какого-нибудь CI. Тот же Travis например практически идеальный вариант для гитхаба.
Я на всякий случай сделал 2 origin-а, один из них ведет на исходный сайт автора, другой на гитхабhttps://github.com/artbear/cfg_tools_python
(0) Как только определитесь с лицензией, поправлю репо на гитхабе.
(12) Infactum, т.е. с предпоследним пунктом все-таки согласен?
(11)(14) Предпоследний пункт — это пункт 7 ведь?
(10) Evil Beaver, Мы не нашли «наработок»(кроме Tool_1cd, но у него нет исходников в свободном доступе) на основании которых можно было бы сделать быструю выгрузку. Используя несколько инструментов(tool_1cd и unpuck, например) мы бы тратили лишнее время на сборку cf а потом разборку, когда, например, в коммите был 1 файл.
(11) Evil Beaver, У нас была одна задача на этом этапе — быстро перекинуть код. В будущем постараемся развить, спасибо за советы! А разработку оставим на питоне, потому как нравится:). А не на гитхабе, потому что после ивента решили познакомиться с гитом, «покурили» тему и выбрали гитлаб, потому что его можно бесплатно развернуть у себя (у нас есть закрытые проекты, такой режим на гитхабе платный). Вот и расшарили этот проект на своем сервере. Создаем учетку на гитхабе, опубликуем там проект. Спасибо!
(17) судя по недавним тикетам на gitsync и данной статье, вы с theshadowco — коллеги?
То, что в статье предложено, мне нравится. Я же не с критикой выступаю, а с предложениями. Ну и вообще, я сторонник подхода share the knowledge. Отсюда и желание видеть это в опенсорсе, на сервере, который не будет сегодня-завтра отключен владельцем. Это раз. И хочется видеть это в виде продукта, готового к повторному использованию, с соответствующей документацией и лицензией — это два.
(15) awa, нет, предпоследний — это пункт 6. Просто он две единицы занимает ))
Добавили бы еще в gitsync частичную выгрузку только изменных модулей — цены б не было. Т.е. если в версии поменялся только модуль или толстая форма, тогда только их выгружаем по правильному пути, а в случаи изменения объектов или упр.форм тогда выгружаем все полностью всю конфигурацию.
(18) Evil Beaver, нет, не коллеги и не знакомы)
https://github.com/TeamBIOS/cfg_tools ((3) artbear, лицензию добавили).
Очень рады предложениям и с радостью их воспринимаем, спасибо! Про гитхаб все поняли, зарегились, опубликовали там проект
Про готовый продукт обсуждали между собой, чтобы все по-человечески доделать и опубликовать, но решили сделать это сейчас и после доработки обновить (для этого и приписали beta). В общем, оно и хорошо получилось, учтем все предложения при развитии проекта.
(4) Infactum, Добавили лицензию и включили в нее Вас
(6) Infactum, про проблемы сложно сказать, т.к. проект был написан с нуля с использованием части Вашего кода(разбор описания таблиц и преобразование типов + некоторые идеи) за это вам большое спасибо, уже исправились в части лицензировния:)). В чистом виде Ваше решение у нас не взлетело, решили писать свой велосипед (уже поняли, что это не популярное мероприятие в местных кругах, но интересно же:)). Можно только по итогу сказать — разница в быстродействии — примерно в 2 раза (база ~ 3гб; onec_tools: 06:28.567312; cfg_tools: 03:49.299595). Если есть желание можем попробовать объеденить наши проекты. но это надо обсуждать отдельно.
(21) Первый форк у меня 🙂
Лицензию увидел
(23) опубликуйте код теста, которым вы производительность сравниваете, пожалуйста (например наGIST ). Как будет время я обязательно посмотрю, что там с быстродействием.
(25) Infactum,текст кода , была идея сначала, что дело в BLOB, но увы они мало влияют. А так, профйлер покажет что надо улучшать.
Разместил хранилище с помощью гит хранилище на сайте bitbucket.org. Загрузка идет прекрассно. Можно ли каким-то образом сделать загрузку обратно в к конфигурацию 1С (хранилище), но не всю целиком (git clone …), а выборочно? То есть, на сайте bitbucket.org хранится информация в коммитах. Допустим коммит 1 — Справочник Номенклатура, коммит 2 Справочник — Организация, коммит 3 — Справочник контрагенты. Мне нужно загрузить в конфигурацию 2 (хранилище 2) из этих 3 коммитов только 1, коммит 2, а остальные не загружать, так как например имеются там какие-нибудь ошибки. Можно это сделать? Если да, то как?
(27) Stas26, На данный момент (в нашем инструменте) нет такой возможности.
Можно посмотреть в строну Tool_1cd, умеет ли он, если да то, можно выгрузить средствами гита нужные коммиты, привести имена файлов к нужному виду(для Tool_1cd) и скормить из ему. А может Tool_1cd уже имеет необходимый функционал.
(6) Infactum, А равзе MIT лицензия не предусматривает что проект является общественным достоянием и код можно использовать по своем усмотрению, в том числе использовать код в своих проектах?
(29) alexkmbk, можно.
У лицензии MIT всего лишь одно условие:
В файле store_reader.py в строке 126 ошибка
Сейчас
if not self.format_83:
должно быть
if self.format_83:
Добрый день, спасибо!