gifts2017

Как мы управляем версиями (Git+1C)

Опубликовал Петр Базелюк (pbazeliuk) в раздел Программирование - Инструментарий

Набор инструментов для автоматической разборки внешних обработок при помещении в git для управления и контролем версий.

На самом деле, поиск инструментов, которые удовлетворяли бы некоторым базовым требованиям велись уже давно. Но решение всегда ускользало от нас, мы участвовали в большом количестве вебинаров, встреч, обсуждений и дело не сдвигалось с места. После участия в infostart-ивенте к нам на глаза попал очень интересный проект Евгения Сосны (github). 

Суть проекта Евгения заключается в том, что при выполнении команды "git commit" обработки\отчеты автоматически распаковываются и добавляются в репозиторий. Соответственно можно смотреть версии и изменения модулей и множество других полезностей. Вроде все что нужно, но не тут то было. По сути мы сделали свой fork с блекджеком и ... 

 

Какие проблемы были решены:

  • Как оказалось нормально распаковываются только обработки для обычного приложения, а у нас вся работа с УФ. Посидев с бубнами и разобравшись с V8Reader - внесли небольшие изменения;
  • Скорость парсинга была не ахти. Решено было написать новую обработку за основу взяли часть кода, оптимизировали, лишнее выкинули по дороге дописали что-то свое;
  • Последней неприятностью было то, что при добавлении файлов распаковки (git commit) они всем скопом заменялись и было сложно сразу понять что же у нас изменилось, хотя по своей сути изменялось 1-2 модуля из 40. Тут на помощь пришла 1С 8.3 с встроенными функциями хеширования. Перед записью файлов модулей мы начали сверять их хеши (по алгоритму SHA-1) и записывали только не совпадающие, а так же удаляли те модули которых уже в обработке нет.

Состав архива:

 

Скриншот куда это нужно положить чтобы оно начало работать:

P.S. Посильную помощь оказывал Андрей Комар, youtube, infostart. Ну и ссылка на наш блог.

Так же отдельное спасибо: Евгению Сосне aka PumbaEO

Скачать файлы

Наименование Файл Версия Размер
V8Commit 46
.7z 119,55Kb
22.02.14
46
.7z 119,55Kb Скачать

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Alexander Speshilov (speshuric) 24.02.14 09:30
2. pbazelyuk (pbazeliuk) 24.02.14 09:41
(1) speshuric, так сложилось исторически, мы используем git в веб-проектах. Mercurial возможно когда-то, а пока git.
3. Андрей Овсянкин (Evil Beaver) 24.02.14 09:43
Я правильно понял, что только отчеты и обработки из состава конфигурации? А все остальное?
4. pbazelyuk (pbazeliuk) 24.02.14 09:59
(3) Evil Beaver, немного не правильно поняли. 95% наработок у нас хранится во внешних обработках и отчетах, согласно статьи http://infostart.ru/public/169131/. Автоматически распаковываются файлы *.epf и *.erf.
Добавить поддержку *.cf возможно, но пока для конфигурации мы пользуемся хранилищем конфигурации.
5. Андрей Овсянкин (Evil Beaver) 24.02.14 10:07
(4) pbazelyuk, Ясно, спасибо. Для большого числа внешних обработок, кстати, можете попробовать мой сравниватель обработок. Не сочтите рекламой, просто подумал, что может быть вам полезен в такой схеме.
Без стартманей можно скачать тут: https://sourceforge.net/projects/v8reader/files/latest/download?source=files
6. pbazelyuk (pbazeliuk) 24.02.14 10:21
(5) Evil Beaver, а мы кстати рассматривали вашу публикацию ранее. Но цели у нас разные, нам нужно хранить версии, а у вас сравнение обработок.
7. Андрей Овсянкин (Evil Beaver) 24.02.14 10:26
(6) pbazelyuk, версии у вас хранит git. А чем вы сравниваете 2 коммита epf между собой? Я как раз для этого V8Viewer и делал. Нужно видеть историю изменений и сравнивать коммиты. Что изменилось, почему и т.п.
Или я что-то не так понял...
8. pbazelyuk (pbazeliuk) 24.02.14 10:40
(7) Evil Beaver, разницу сразу показывает git, да и сервис хостинга bitbucket. Пока только модуль объекта, модули форм и макеты СКД. Но в будущем, надеюсь совместными усилиями сообщества, появится возможность все остальное хранить в более понятном виде, а также добавить возможность "патчинга" и обратной сборки в обработку\отчет.
9. Андрей Овсянкин (Evil Beaver) 24.02.14 10:46
(8) pbazelyuk, в гите, конечно, должны лежать текстовики. Это более правильный подход, нежели с хранением epf и ковырянием в них сторонними утилитами. Наличие текстовиков позволяет выполнять полноценный merge и вообще, пользоваться "родными" средствами git в полной мере. Смущает меня именно "частичность" хранения. Это лежит в гите, а это - не лежит... как-то польза от такого "контроля версий" кажется мне очень небольшой.
Хранение версий - это все или ничего. Вот есть коммит, он отмечен как "финальная версия 1.01" В любое время дня и ночи он должен быть получен из гита и собран в боевой режим. Этот коммит обязан быть единым и неделимым. Как у вас это обеспечивается?
10. pbazelyuk (pbazeliuk) 24.02.14 12:09
(9) Evil Beaver, лежат текстовые файлы и соответственно бинарный файл обработки рядом. То что Вы написали мы разрабатываем в свободное от работы время и когда оно будет сказать не могу, но когда будет реализовано в полной мере - тогда и можно начинать делать автоматические ночные тесты и сборки.
Та часть, которая сейчас есть, как раз нам нужна для ускоренного проведения "Code review" и получения последней актуальной версии. Соответственно отпадает нужда в поисках последней версии обработки по базам тестирования и дерганья программистов с вопросом: "А где последняя ли версия?".
11. Ivan Khorkov (vano-ekt) 24.02.14 12:24
12. Alexander Speshilov (speshuric) 24.02.14 12:48
(2) Я просто спросил, потому что при работе с windows и с текстами 1С, hg оставил гораздо более приятное впечатление. Никаких проблем с кодировками (в комментариях к коммитам), никаких нагромождений типа MINGW32 в дистрибутиве по умолчанию. Bitbucket умеет и hg, и git, поэтому немного удивился, что git. Но если всё остальное в git, то, безусловно, проще с git работать.
(11) У хоронилища конфигураций достаточно много недостатков. Это самое хоронилище - одно из главных препятствий к CI на 1С.
theshadowco; Redokov; McSim; vabue; akomar; pbazeliuk; +6 Ответить 1
13. pbazelyuk (pbazeliuk) 24.02.14 12:51
(12) speshuric, с кодировками да проблема еще та. Возможно в конце недели посмотрим в сторону hg.
14. pbazelyuk (pbazeliuk) 24.02.14 12:58
(9) Evil Beaver, вот например, изображение как проводится "Code review".
15. Alexander Speshilov (speshuric) 24.02.14 13:10
(11) Ну и чтобы не быть голословным. Списочек того, что не устраивает в хоронилище:
  • Хранилище имеет закрытый формат. Если с ним что-то произошло, то очень часто починить нереально.
  • Хранилище не отслеживает релиз платформы, на которой разрабатывается конфигурация. При параллельной разработке в 2 релизах были случаи крэша хранилища. В git/hg даже просто выгруженной конфигурации, этого можно было бы избежать, так как все изменения прозрачно хранятся в файлах.
  • Хранилище очень жадное до трафика. Причем во всех вариантах (и папка и сервер). А сервер еще и тормозной. В git/hg локальная копия всегда под рукой.
  • Хранилище не имеет веток даже в том виде, в котором они были в допотопном SVN. Из-за этого любая разработка скатывается к нескольким независимым хранилищам (как аналогу веток). Но из-за независимости сразу возникает букет проблем (банально даже с заведением разработчиков).
  • Хранилище не позволяет автоматизировать ничего, кроме выплёвывания cf. Нет даже реагирования на события - как CI сервер должен догадаться, что нужно собирать релиз начать? Да, давайте каждые 5 минут формировать полный отчет по хранилищу и смотреть последнюю версию. Только...
  • Отчеты в интерактивном режиме и в пакетном разные. Причем в пакетном нет части настроек. Из-за этого достоверно доверять отчету нельзя.
  • В хранилище нельзя сделать пользователя, который может захватывать объекты, но не может коммитить. В git/hg вообще не нужны захваты и с локальной копией можно хоть камасутрой заниматься.
  • В хранилище нет аналога pull request.
Блин, надо остановиться, а то я могу этот список еще долго продолжать :)
h00k; CSiER; Berckk; FSerg; zlolik; slavik27; 8SiriuS8; vet7777; vlad.frost; artbear; Elisy; baton_pk; +12 Ответить 3
16. Андрей Овсянкин (Evil Beaver) 24.02.14 13:30
(15) speshuric, не надо продолжать, нервов не хватит)
17. Alexander Speshilov (speshuric) 24.02.14 13:52
(16) Вот еще не хватало на хранилище нервы тратить :) Какое уж есть. Для 1-3 человек даже более-менее удобное решение. А вспоминая групповую разработку на клюшках (в до-GComp эпоху) так вообще конфетка :)
19. Alexander Speshilov (speshuric) 24.02.14 14:04
(18) Ну во-первых суть как раз в "может захватывать объекты, но не может коммитить". Один из сценариев (не единственный) - костыльный "pull request".
Во-вторых, рабочая база не должна быть связана с хранилищем. Моё мнение - рабочая база только на полной поставке.
Evil Beaver; +1 1 Ответить
20. Андрей Овсянкин (Evil Beaver) 24.02.14 14:40
(17) speshuric,
вспоминая групповую разработку на клюшках (в до-GComp эпоху)

Интересно, я один не понял, что означает эта фраза? :)
21. Alexander Speshilov (speshuric) 24.02.14 14:48
(20) Сорри. Клюшки - 1С 7.7, GComp - утилита сборки-разборки файла 1cv7.md в набор текстовых файлов.
22. Евгений Сосна (pumbaE) 24.02.14 15:18
(1) у hg неприятная особенность работы с не-латинскими наименованиями файлов, на своей машинке вы этого не заметите, но вот только начнете использовать различные машинки linux, win7, winxp, win8 и при обмене сразу станет проблема с наименованиями файлов. А использовать латинские наименования для внешних обработок, еще и для 1С - это моветон.

(15) каждых 5 минут, мониторим файл базы данных хранилища.
Отчеты по истории версий смотрю с помощью toolcd.
23. Alexander Speshilov (speshuric) 24.02.14 15:38
(22) Про имена проверю, мне кажется, я об эту граблю спотыкался, но она решилась просто. Может что-то путаю.
Где-то год назад я пытался прикрутить 1С к общему CI-серверу - тоже написал проверку раз в 5 минут (только всё-таки по отчетам хранилища, из-за чего было медленно). Но в процесс не решился встраивать - уж слишком всё наколеночно получалось: тесты отдельными хранилищами, конфа отдельным, программисты c# в своём hg-репозитории.
24. Евгений Сосна (pumbaE) 24.02.14 15:57
(23) был плагин для hg решающий проблему (но только для имен, но не для папок) http://mercurial.selenic.com/wiki/FixUtf8Extension , но уже и он не совместим с последними версиями.

У меня для обработок тестов отдельное хранилище git поднято(тесты используются как внешние обработки), в роли CI выступает jenkins, который ночью запускает получение последней версии из хранилища, обновление эталонной базы, сохраняет вывод протокола обновления. После этого запускаются тесты, результат вывода идет в стандартном junit xml формате, что позволяет jenkins распарсить результат, а мне видеть в результате количество новых успешных тестов, количество регрессий в тестах и т.д., деградация времени выполнения тестов ну и в случаи неудачи ответственным за последние изменения отсылаются письма счастья.

p.s.: уже можно CI использовать в 1С и это очень удобно.
artbear; vabue; pbazeliuk; speshuric; +4 Ответить 1
25. BabySG (BabySG) 24.02.14 16:43
В рамках показанного на осеннем семинаре 2013 - ненужная штука, мягко говоря :)
26. Евгений Сосна (pumbaE) 24.02.14 16:47
(25) BabySG, ага, только на вопрос "когда в продакшин, а не тест?", не можем с уверенностью ответь даже про 8.3.5 .
Думаю даже с новым конфигуратором вряд-ли, что-то измениться в плане тестирования. В 8.3 запись тестов появилась, а интерпретация результатов нет, не приняты в 1С автоматические тесты.
27. Вячеслав Клюев (slavik27) 25.02.14 12:46
вещь хорошая,
но меня с подобной штукой здесь закритиковали....
28. Евгений Сосна (pumbaE) 25.02.14 13:21
29. Роман Осадченко (cleaner_it) 25.02.14 14:19
(25) BabySG, не следил. Что там было показано? Крутое хранилище наподобие Git?
30. Вячеслав Клюев (slavik27) 25.02.14 19:34
(28) pumbaE, я уже даже публикацию удалил.
31. Максим Кузнецов (Makushimo) 26.02.14 11:22
Статья написана как окончание некоего долгого разговора с кем-то, кого мы не знаем. И че к чему и зачем - не понятно.
32. Михаил Топоров (mihast) 01.03.14 13:27
(31) Скорее не окончание, а продолжение... Посмотрел блог по ссылке выше - думал там начало диалога - отнюдь...

Так все-таки hg или git - для UTF-8 ?
33. Евгений Сосна (pumbaE) 01.03.14 15:14
34. Алексей Т. (CratosX) 04.03.14 10:16
(29) cleaner_it, ещё круче, но дело возможно даже не 2015-го года, а позже...
35. Андрей Комар (akomar) 05.03.14 18:43
(34) Еще круче, заинтриговали:)

Ответьте только на один вопрос, внешние обработки можно будет хранить или только конфигурацию?
36. Евгений Сосна (pumbaE) 06.03.14 19:24
(35) akomar, eclipse со своими блэк джеками и шл...ми.
37. Денис Яковлев (iceflash) 14.04.14 01:20
(36) pumbaE, ага, использовать бы ide eclipse под 1ц было бы очень круто. В данном случае проприетарность 1ц только во вред самой платформы. Уже столько лет прошло, ну возьмите вы достойную ide запросто адаптируете под нужные вещи - и вот уже достойная система разработки
38. Евгения Карук (ekaruk) 16.11.14 17:01
Спасибо. Пригодилось.
Раньше в виде бинарников в Гите хранила, решила попробовать.
Достаточно читабельно.
Заработало "из коробки" без никаких модификаций. Только Питон пришлось доставить.

(37) iceflash, Ну так сделали вроде уже работу 1С с ide eclipse. Еще годик и рядовым программистам дадут поиграться.
39. Петр Базелюк (pbazeliuk) 16.11.14 19:28
(38) ekaruk, посоветовал бы вам использовать precommit1c. К сожалению, в V8Commit есть некоторые ошибки (не разбирается управляемая форма в отчете *.erf с СКД).

Ошибку не планируется исправлять, так как сейчас в процессе идет разработка программы, которой не нужна платформа 1С для работы.
40. Евгения Карук (ekaruk) 17.11.14 01:16
(39) pbazeliuk, precommit1c пробовала раньше.
Не получилось настроить.
Вроде все по описанию, последний вариант с ГитХаба
Может подскажете, что ему не хватает.
Прикрепленные файлы:
41. Евгений Сосна (pumbaE) 17.11.14 09:54
(40) есть такая ошибка, нет проверки на первое помещение файла. Для быстрого fix добавьте в параметры "git commit -n " (коммит без вызова хуков) и потом последующие изменения (можно еще раз в модуле пробел добавить) будут проходить нормально.

p.s. для таких случаев есть регистрация ошибок, если несложно сделаете плиз.
42. Евгения Карук (ekaruk) 17.11.14 10:54
(41) pumbaE, Спасибо, помогло.
По регистрации, подскажите, где и как.
44. Александр Топольский (AlexanderKai) 24.11.14 17:14
Посидев с бубнами и разобравшись с V8Reader - внесли небольшие изменения;

Все эти изменения есть в архиве V8Commit.7z ?
45. Петр Базелюк (pbazeliuk) 25.11.14 00:50
(44) AlexanderKai, если вам нужен V8Reader, то вам публикация не подходит. Если нужен инструмент лучше взять - precommit1C
46. eugenie zheludkov (eugeniezheludkov) 27.02.15 07:13
все круто работает распаковывает при коммите , но как делать слияние так и не понял ? т.е к примеру вася поменял в модуле обработки , а петя поменял код в модуле формы , ну или оба меняли код модуля формы ? как это смерджится ? или для такой командной разработки не предназначено ? и как я понял для .cf подобного не существуют и все тупо ждут 8.4.1 с его эклипсом и java ?

ПС кажись понял все примеры приводятся лишь для 8.3 ? там можно .cf обратно собрать в пакетном режиме
47. Владимир Буоц (vbuots) 20.03.15 09:31
Не могу исправить ошибку.
Windows 8.1 x64
python 3.3
Git-1.9.5-preview20141217
48. Андрей (h00k) 02.07.16 17:43
(24) pumbaE,
http://mercurial.selenic.com/wiki/FixUtf8Extension , но уже и он не совместим с последними версиями.

Собрал версию плагина FixUtf8 работающую с Mercurial 3.8 и перевел описание на русский язык. Результат редварительного тестирования - работает корректно, проверял на ERP 2.1 и своих расширениях/ внешних обработках.
49. Евгений Сосна (pumbaE) 07.07.16 11:32
(48) h00k, спасибо. Попробую. К сожалению, ребята с Японии забросили портирование ядра hg https://www.mercurial-scm.org/wiki/WindowsUTF8Plan
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа