На самом деле, поиск инструментов, которые удовлетворяли бы некоторым базовым требованиям велись уже давно. Но решение всегда ускользало от нас, мы участвовали в большом количестве вебинаров, встреч, обсуждений и дело не сдвигалось с места. После участия в infostart-ивенте к нам на глаза попал очень интересный проект Евгения Сосны (github).
Суть проекта Евгения заключается в том, что при выполнении команды «git commit» обработкиотчеты автоматически распаковываются и добавляются в репозиторий. Соответственно можно смотреть версии и изменения модулей и множество других полезностей. Вроде все что нужно, но не тут то было. По сути мы сделали свой fork с блекджеком и …
Какие проблемы были решены:
- Как оказалось нормально распаковываются только обработки для обычного приложения, а у нас вся работа с УФ. Посидев с бубнами и разобравшись с V8Reader — внесли небольшие изменения;
- Скорость парсинга была не ахти. Решено было написать новую обработку за основу взяли часть кода, оптимизировали, лишнее выкинули по дороге дописали что-то свое;
- Последней неприятностью было то, что при добавлении файлов распаковки (git commit) они всем скопом заменялись и было сложно сразу понять что же у нас изменилось, хотя по своей сути изменялось 1-2 модуля из 40. Тут на помощь пришла 1С 8.3 с встроенными функциями хеширования. Перед записью файлов модулей мы начали сверять их хеши (по алгоритму SHA-1) и записывали только не совпадающие, а так же удаляли те модули которых уже в обработке нет.
Состав архива:
- pyv8unpack.py — python скрипт, получающий список помещаемых файлов при коммите, фильтрующий по расширению только внешние обработки/отчеты и запускающий внешнюю обработку для распаковки этих файлов;
- V8Commit.epf — внешняя обработка 1С, которая с помощью v8unpack разбирает внешние обработки, определяет нормальные наименования и раскладывает их по папкам;
- V8Commit — сервисная база данных для запуска V8Commit.epf;
- pre-commit — собственно командный файл вызываемый git перед каждым помещением. Выполняет роль простой запускалки скрипта pyv8unpack.py.
Скриншот куда это нужно положить чтобы оно начало работать:
P.S. Посильную помощь оказывал Андрей Комар, youtube, infostart. Ну и ссылка на наш блог.
Так же отдельное спасибо: Евгению Сосне aka PumbaEO
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
(0) а почему git, а не hg?
(1) speshuric, так сложилось исторически, мы используем git в веб-проектах. Mercurial возможно когда-то, а пока git.
Я правильно понял, что только отчеты и обработки из состава конфигурации? А все остальное?
(3) Evil Beaver, немного не правильно поняли. 95% наработок у нас хранится во внешних обработках и отчетах, согласно статьи . Автоматически распаковываются файлы *.epf и *.erf.
Добавить поддержку *.cf возможно, но пока для конфигурации мы пользуемся хранилищем конфигурации.
(4) Ясно, спасибо. Для большого числа внешних обработок, кстати, можете попробовать мой обработок. Не сочтите рекламой, просто подумал, что может быть вам полезен в такой схеме.
Без стартманей можно скачать тут:
(5) Evil Beaver, а мы кстати рассматривали вашу публикацию ранее. Но цели у нас разные, нам нужно хранить версии, а у вас сравнение обработок.
(6) версии у вас хранит git. А чем вы сравниваете 2 коммита epf между собой? Я как раз для этого V8Viewer и делал. Нужно видеть историю изменений и сравнивать коммиты. Что изменилось, почему и т.п.
Или я что-то не так понял…
(7) Evil Beaver, разницу сразу показывает git, да и сервис хостинга bitbucket. Пока только модуль объекта, модули форм и макеты СКД. Но в будущем, надеюсь совместными усилиями сообщества, появится возможность все остальное хранить в более понятном виде, а также добавить возможность «патчинга» и обратной сборки в обработкуотчет.
(8) в гите, конечно, должны лежать текстовики. Это более правильный подход, нежели с хранением epf и ковырянием в них сторонними утилитами. Наличие текстовиков позволяет выполнять полноценный merge и вообще, пользоваться «родными» средствами git в полной мере. Смущает меня именно «частичность» хранения. Это лежит в гите, а это — не лежит… как-то польза от такого «контроля версий» кажется мне очень небольшой.
Хранение версий — это все или ничего. Вот есть коммит, он отмечен как «финальная версия 1.01» В любое время дня и ночи он должен быть получен из гита и собран в боевой режим. Этот коммит обязан быть единым и неделимым. Как у вас это обеспечивается?
(9) Evil Beaver, лежат текстовые файлы и соответственно бинарный файл обработки рядом. То что Вы написали мы разрабатываем в свободное от работы время и когда оно будет сказать не могу, но когда будет реализовано в полной мере — тогда и можно начинать делать автоматические ночные тесты и сборки.
Та часть, которая сейчас есть, как раз нам нужна для ускоренного проведения «Code review» и получения последней актуальной версии. Соответственно отпадает нужда в поисках последней версии обработки по базам тестирования и дерганья программистов с вопросом: «А где последняя ли версия?».
хранилище — наше всё …
(2) Я просто спросил, потому что при работе с windows и с текстами 1С, hg оставил гораздо более приятное впечатление. Никаких проблем с кодировками (в комментариях к коммитам), никаких нагромождений типа MINGW32 в дистрибутиве по умолчанию. Bitbucket умеет и hg, и git, поэтому немного удивился, что git. Но если всё остальное в git, то, безусловно, проще с git работать.
(11) У хоронилища конфигураций достаточно много недостатков. Это самое хоронилище — одно из главных препятствий к CI на 1С.
(12) speshuric, с кодировками да проблема еще та. Возможно в конце недели посмотрим в сторону hg.
(9) Evil Beaver, вот например, изображение как проводится «Code review».
(11) Ну и чтобы не быть голословным. Списочек того, что не устраивает в хоронилище:
Блин, надо остановиться, а то я могу этот список еще долго продолжать 🙂
(15) speshuric, не надо продолжать, нервов не хватит)
(16) Вот еще не хватало на хранилище нервы тратить 🙂 Какое уж есть. Для 1-3 человек даже более-менее удобное решение. А вспоминая групповую разработку на клюшках (в до-GComp эпоху) так вообще конфетка 🙂
Del
(18) Ну во-первых суть как раз в «может захватывать объекты, но не может коммитить». Один из сценариев (не единственный) — костыльный «pull request».
Во-вторых, рабочая база не должна быть связана с хранилищем. Моё мнение — рабочая база только на полной поставке.
(17) speshuric,
Интересно, я один не понял, что означает эта фраза? 🙂
(20) Сорри. Клюшки — 1С 7.7, GComp — утилита сборки-разборки файла 1cv7.md в набор текстовых файлов.
(1) у hg неприятная особенность работы с не-латинскими наименованиями файлов, на своей машинке вы этого не заметите, но вот только начнете использовать различные машинки linux, win7, winxp, win8 и при обмене сразу станет проблема с наименованиями файлов. А использовать латинские наименования для внешних обработок, еще и для 1С — это моветон.
(15) каждых 5 минут, мониторим файл базы данных хранилища.
Отчеты по истории версий смотрю с помощью toolcd.
(22) Про имена проверю, мне кажется, я об эту граблю спотыкался, но она решилась просто. Может что-то путаю.
Где-то год назад я пытался прикрутить 1С к общему CI-серверу — тоже написал проверку раз в 5 минут (только всё-таки по отчетам хранилища, из-за чего было медленно). Но в процесс не решился встраивать — уж слишком всё наколеночно получалось: тесты отдельными хранилищами, конфа отдельным, программисты c# в своём hg-репозитории.
(23) был плагин для hg решающий проблему (но только для имен, но не для папок) , но уже и он не совместим с последними версиями.
У меня для обработок тестов отдельное хранилище git поднято(тесты используются как внешние обработки), в роли CI выступает jenkins, который ночью запускает получение последней версии из хранилища, обновление эталонной базы, сохраняет вывод протокола обновления. После этого запускаются тесты, результат вывода идет в стандартном junit xml формате, что позволяет jenkins распарсить результат, а мне видеть в результате количество новых успешных тестов, количество регрессий в тестах и т.д., деградация времени выполнения тестов ну и в случаи неудачи ответственным за последние изменения отсылаются письма счастья.
p.s.: уже можно CI использовать в 1С и это очень удобно.
В рамках показанного на осеннем семинаре 2013 — ненужная штука, мягко говоря 🙂
(25) BabySG, ага, только на вопрос «когда в продакшин, а не тест?», не можем с уверенностью ответь даже про 8.3.5 .
Думаю даже с новым конфигуратором вряд-ли, что-то измениться в плане тестирования. В 8.3 запись тестов появилась, а интерпретация результатов нет, не приняты в 1С автоматические тесты.
вещь хорошая,
но меня с подобной штукой здесь закритиковали….
(27) slavik27, где?
(25) BabySG, не следил. Что там было показано? Крутое хранилище наподобие Git?
(28) pumbaE, я уже даже публикацию удалил.
Статья написана как окончание некоего долгого разговора с кем-то, кого мы не знаем. И че к чему и зачем — не понятно.
(31) Скорее не окончание, а продолжение… Посмотрел блог по ссылке выше — думал там начало диалога — отнюдь…
Так все-таки hg или git — для UTF-8 ?
(32) mihast, git
(29) cleaner_it, ещё круче, но дело возможно даже не 2015-го года, а позже…
(34) Еще круче, заинтриговали:)
Ответьте только на один вопрос, внешние обработки можно будет хранить или только конфигурацию?
(35) akomar, eclipse со своими блэк джеками и шл…ми.
(36) pumbaE, ага, использовать бы ide eclipse под 1ц было бы очень круто. В данном случае проприетарность 1ц только во вред самой платформы. Уже столько лет прошло, ну возьмите вы достойную ide запросто адаптируете под нужные вещи — и вот уже достойная система разработки
Спасибо. Пригодилось.
Раньше в виде бинарников в Гите хранила, решила попробовать.
Достаточно читабельно.
Заработало «из коробки» без никаких модификаций. Только Питон пришлось доставить.
(37) iceflash, Ну так сделали вроде уже работу 1С с ide eclipse. Еще годик и рядовым программистам дадут поиграться.
(38) ekaruk, посоветовал бы вам использовать . К сожалению, в V8Commit есть некоторые ошибки (не разбирается управляемая форма в отчете *.erf с СКД).
Ошибку не планируется исправлять, так как сейчас в процессе идет разработка программы, которой не нужна платформа 1С для работы.
(39) pbazeliuk, precommit1c пробовала раньше.
Не получилось настроить.
Вроде все по описанию, последний вариант с ГитХаба
Может подскажете, что ему не хватает.
(40) есть такая ошибка, нет проверки на первое помещение файла. Для быстрого fix добавьте в параметры «git commit -n » (коммит без вызова хуков) и потом последующие изменения (можно еще раз в модуле пробел добавить) будут проходить нормально.
p.s. для таких случаев есть регистрация ошибок, если несложно сделаете плиз.
(41) pumbaE, Спасибо, помогло.
По регистрации, подскажите, где и как.
(42) ekaruk,
Все эти изменения есть в архиве V8Commit.7z ?
(44) AlexanderKai, если вам нужен V8Reader, то вам публикация не подходит. Если нужен инструмент лучше взять —
все круто работает распаковывает при коммите , но как делать слияние так и не понял ? т.е к примеру вася поменял в модуле обработки , а петя поменял код в модуле формы , ну или оба меняли код модуля формы ? как это смерджится ? или для такой командной разработки не предназначено ? и как я понял для .cf подобного не существуют и все тупо ждут 8.4.1 с его эклипсом и java ?
ПС кажись понял все примеры приводятся лишь для 8.3 ? там можно .cf обратно собрать в пакетном режиме
Не могу исправить ошибку.
Windows 8.1 x64
python 3.3
Git-1.9.5-preview20141217
(24) pumbaE,
Собрал работающую с Mercurial 3.8 и перевел описание на русский язык. Результат редварительного тестирования — работает корректно, проверял на ERP 2.1 и своих расширениях/ внешних обработках.
(48) h00k, спасибо. Попробую. К сожалению, ребята с Японии забросили портирование ядра hg