0. VladimirL 780 13.09.18 00:12 Сейчас в теме

Синхронизация хранилища 1С и git-репозитория с применением OneScript и Gitsync. Методика и пошаговая инструкция для создания скрипта и его регулярного запуска

- Настройка репозитория для работы с большими типовыми конфигурациями
- Алгоритм создания скрипта выгрузки и его исходный код
- Обработка исключительных ситуаций
- Рекомендации по дальнейшему развитию процесса

Перейти к публикации

Комментарии
Сортировка: Древо
1. VladimirL 780 14.09.18 09:23 Сейчас в теме
Методика писалась около года назад. В связи с актуальностью на новом проекте решил ее обновить с учетом новых параметров gitsync и граблей, на которые пришлось наступить, и всё-таки довести до публикации. Сейчас хотелось бы написать больше по теме совместной работы с репозиторием, но практика в достаточной степени пока не наработана и лучше оставить тему для другой публикации ) Возможно в следующий раз получится подробнее остановиться на использовании сервера сборок вместо “деревянного” планировщика.
GreenDragon; BlizD; fishca; +3 Ответить
7. theshadowco 19 14.09.18 10:50 Сейчас в теме
(1) совместаня работа - это легко, вот см картинку-пример (хранилищей нет, только git и gitflow)
Прикрепленные файлы:
9. VladimirL 780 14.09.18 11:30 Сейчас в теме
(7)
Совместная работа - это всегда сложно, независимо от применяемых инструментов )) Требуется чтобы необходимой квалификацией и, в идеале, желанием использовать подходы и инструменты обладал каждый, кто задействован в процессе. Для этого необходимо ставить процесс обучения параллельно с текущими задачами, а 1С - это мир прагматизма и замкнутой вокруг платформы 1С экосистемы ))

Вообще было бы классно увидеть пример описываемого Вами процесса на примере работы именно с кодом типовой конфигурации. Здесь тоже процесс описан https://infostart.ru/public/310640. Как применить его при работе с внешними обработками и документацией понятно. Как версионировать скрипты и фичи тоже понятно. Хотя и при этом возникают сложности описанные в публикации.

Не хватает примеров как работать с типовыми и кодом самой конфигурации. Было бы очень классно прочитать практические советы и примеры. Те же мерджи форм или кода модулей объектов из состава конфигурации.

Ввиду отсутствия открытых сообществу практических примеров и методик, сейчас при работе с типовыми конфигурациями разве что на EDT надежда есть. Но когда это будет?
56. theshadowco 19 18.09.18 15:31 Сейчас в теме
(9) Разницы "типовая" или нет нет никакой, все зависит от поставленного процесса.
А так да, любой инструмент можно применить, главное чтобы был удобен.

По поводу кейсов - есть консалтинг, обращайтесь :). А если серьезно, до определенного взросления команды смысла нет - масса примеров когда работы напрямую с продовой ИС считаются нормальными.
57. VladimirL 780 18.09.18 20:53 Сейчас в теме
(56) Если не сложно, напишите какие именно услуги консалтинга Вы предоставляете или какие Вам известны. Откровенно говоря, вероятность воспользоваться ими через компанию в ближайшее время очень низкая. На текущие процессы разработки это скорее всего не распространить. Но может быть в будущем получится. Ведь это то, чему действительно хотелось бы научиться. И знание возможностей - это первый шаг к их применению.

Да и уверен, что многим было бы интересно узнать о ситуации на рынке. Впервые слышу про такое предложение, хотя темой интересуюсь. Здесь я имею ввиду предложение по обучению работе напрямую с распределенной системой управления версиями минуя хранилище, но не отказываясь при этом от разработки в конфигураторе 1С. Если я Вас правильно понял.
58. theshadowco 19 18.09.18 22:24 Сейчас в теме
(57) конфигуратор можно, но не обязательно
59. theshadowco 19 18.09.18 22:26 Сейчас в теме
(57) а так, приходите на IE - если буду с ноутом, смогу показать :)
22. GreenDragon 15.09.18 15:05 Сейчас в теме
(1) Огромное вам человеческое спасибо! Как раз начал внедрять методики разработки с применением git у нас в отделе. Куплены и практически курсы от серебрянной пули по промышленной разработке, а тут ещё и ваша статья подоспела. Ещё раз спасибо!
39. VladimirL 780 17.09.18 09:55 Сейчас в теме
(22) Действительно желаю успехов в этом. Очень надеюсь, что таких команд станет больше.
2. fishca 1122 14.09.18 10:29 Сейчас в теме
Огромное спасибо за огромную проделанную работу по написанию данного материала! Архиполезно!
GreenDragon; CSiER; Evil Beaver; VladimirL; +4 Ответить
3. artbear 1067 14.09.18 10:29 Сейчас в теме
Очень хороший лонг грид :)
Спасибо за использование нашего инструмента gitsync.

Он сейчас переживает очередное рождение - 4 или 5 :) ??
5. VladimirL 780 14.09.18 10:38 Сейчас в теме
(3) Артур, Вам спасибо за его создание. Без него всё было бы сложнее, если вообще возможно. Барьер вхождения в эту тему определенно был бы выше.
4. artbear 1067 14.09.18 10:30 Сейчас в теме
И про KDiff3 отличный совет, сам его использую почти 20 лет.
VladimirL; +1 Ответить
6. nixel 509 14.09.18 10:40 Сейчас в теме
Труд, достойный внимания и прочтения :)

Пара комментариев по гитсинку:
* работа по tcp и http доступна в gitsync 3.0
* временные файлы все же уже чистятся :)

Если честно, не совсем понятно, зачем вы писали скрипт, который просто пробрасывает переданные параметры командной строки в ... командную строку гитсинка.
Часть дополнительных проверок, которые вы описали, можно упаковать в виде плагинов к гитсинку, оставив на верхнем уровне только собственно запуск гитсинка. Но дело ваше.

В любом случае, спасибо за статью и интерес к теме!

P.S. Вижу, что курс не прошел зря :)
Evil Beaver; JohnyDeath; artbear; +3 Ответить
8. VladimirL 780 14.09.18 11:17 Сейчас в теме
(6)
Часть дополнительных проверок, которые вы описали, можно упаковать в виде плагинов к гитсинку

Никита, о механизме плагинов к gitsync узнал только сейчас из Вашего комментария. Спасибо за замечание, буду изучать вопрос.

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

курс не прошел зря

Курс был полезен, спасибо. Рекомендую его в публикации для знакомства с Jenkins. Изначально ставил этот процесс полностью как описано в публикации. Но после прохождения понял какие преимущества будут в результате подключения сервера сборок к этому процессу и в том числе подогнал скрипт под использование в сборочной линии. Головную боль с докером до сих пор вспоминаю, но с положительной стороны )) Тоже было очень полезно, познакомился наконец с 1С в Linux.

временные файлы все же уже чистятся

Работу с временными файлами проверял на версии gitsync 2.4.3. Сейчас ведь она актуальна. Временные файлы сохраняются. Возможно есть какой то ключ для их удаления? Подскажите, если так.

Тут еще один момент. Удаление временных файлов на 1C: ERP может занимать несколько минут, если речь идет не про SSD диск. Возможно при применении HDD их целесообразнее делать после git push. По той же причине, по которой применяется параметр -limit 1 - это ускоряет появление и доступность коммита в Gitlab/Fisheye/Upsource и позволяет быстрее двигать задачи на разработку дальше.

работа по tcp и http доступна в gitsync 3.0

Возможность работать с хранилищем по TCP в версии 3.0 - это отлично! Надо будет проверить.
10. nixel 509 14.09.18 12:18 Сейчас в теме
(8)
Работу с временными файлами проверял на версии gitsync 2.4.3. Сейчас ведь она актуальна. Временные файлы сохраняются.



кто-то недавно божился, что поправлено)

если это не так, то стоит в первую очередь проверить на версии 3.0, поддержка ветки 2.х сейчас осуществляется ооочень неохотно, т.к. силы разработчиков брошены на полировку 3.0 и наконец-то выкатку в релиз.
11. nixel 509 14.09.18 12:33 Сейчас в теме
(10) я кажется вспомнил. был момент, что временные файлы очищались не после запуска, а *перед* следующим запуском. то есть при использовании limit и периодическом запуске переполнения можно избежать. но не ручаюсь :)
46. GreenDragon 18.09.18 02:53 Сейчас в теме
(6)
* работа по tcp и http доступна в gitsync 3.0

Если не ошибаюсь, gitsync 3.0 живёт пока что в ветке develop. Думаю, стоит подождать мердж в master/
(6)
12. Evil Beaver 5252 14.09.18 22:06 Сейчас в теме
Фундаментально, спасибо!
VladimirL; +1 Ответить
13. PerlAmutor 30 15.09.18 06:38 Сейчас в теме
Спасибо за публикацию. Тема довольно сложная.

По практике выгрузка каждого коммита ERP без SSD диска занимает 45 - 60 минут, с SSD диском 15-20 минут.

Эта заметка настораживает. Конечно, если делать коммиты раз в день, то проблем быть не должно. А для оперативного исправления бага с предыдущего коммита ничего не останется как лезть напрямую в рабочий конфигуратор и править там по-старинке.

Я правильно скажу, что основная цель всех этих мучений заключается в том, чтобы:
1. Избавиться от захватов объектов и вести параллельную разработку, а не просить отпустить объект, когда человек ушел в отпуск?
2. Красивое представление изменений в веб-интерфейсе
3. Качественное комментирование кода конфигурации

?
15. VladimirL 780 15.09.18 13:57 Сейчас в теме
(13)
Эта заметка настораживает. Конечно, если делать коммиты раз в день, то проблем быть не должно.

Если делать закладки в хранилище раз в час то проблем тоже не будет. А при использовании нормального железа и раз в 15 минут проблем не вызовет. При работе с небольшими конфигурациями и раз в 5 минут можно. Если сделано две закладки подряд, то они все равно обработаются, просто за 10-40 минут.

У gitsync есть инкрементальная выгрузка. Добавил о ней информацию в публикацию. Она позволит делать выгрузку очень быстро. Но тогда надо регулярно делать автоматическую задачу на полную выгрузку. Если 15-20 минут - время которое устраивает, то можно не использовать инкрементальную выгрузку.

для оперативного исправления бага с предыдущего коммита ничего не останется как лезть напрямую в рабочий конфигуратор и править там по-старинке


Для оперативного исправления бага так придется делать в любом случае. Если под оперативностью понимается 5-10 минут. Для этого рабочая конфигурация должна быть отключена от хранилища или подключена к другому хранилищу, отличному от того, в котором ведется разработка. В случае использования другого хранилища появляется та самая ветка master, которая создавалась в публикации. Это правильный подход и предлагается в том числе фирмой 1С в книге Методическое пособие по эксплуатации крупных информационных систем на платформе «1С:Предприятие 8»

Уже затем исправленный баг должен по всем правилам работы с задачами на разработку пройти через базу разработчика и хранилище для разработки и дойти до релизного cf-ника или exe-файла поставки. В идеале еще и тестами покрыт, если в команде дошло дело до таких продвинутых штук как покрытие тестами.

основная цель

Пожалуйста, прочитайте первый абзац этой публикации. Думаю лучше обратиться к приведенным в нем ссылкам, цель этой публикации другая.
14. tsukanov 65 15.09.18 08:09 Сейчас в теме
По практике выгрузка каждого коммита ERP без SSD диска занимает 45 - 60 минут, с SSD диском 15-20 минут.


Жесть какая. Выгрузка коммитов в платформе не оптимизирована как обычная выгрузка? Или с чем это связано?
16. VladimirL 780 15.09.18 14:03 Сейчас в теме
(14)
Время работы не будет таким большим при работе с конфигурациями, меньшими по размеру, чем ERP. Для УТ 11 это время можно сократить до 5 минут.

Время работы во многом связано со следующим алгоритмом:
* Выгружается нужная версия хранилища в виде cf-файла
* Загружается во временную файловую базу (здесь появляются проблемы с лицензиями).
* Разбирается на исходники путем выгрузки во временный каталог.
* Затем идет обработка этого временного каталога, удаляются файлы из рабочего каталога репозитория, файлы туда переносятся из временного каталога.
* Делается коммит изменений и отправка в удаленный репозиторий.
* Удаляется множество мелких файлов из временного каталога.

Выше также написал, у gitsync есть инкрементальная выгрузка. Она работает много быстрее, просто потребует второй автоматической задачи на полную выгрузку раз в день.
17. tsukanov 65 15.09.18 14:23 Сейчас в теме
(16) Не совсем понимаю. А для чего все это делается?
Пардон за глупые вопросы. Я могу чего-то недопонимать.
Я предполагал, что версия из хранилища сразу выгружается в XML. Платформа этого не позволяет?
Ну и если бы оно выгружалось в XML, то весь процесс кажется не больше минуты бы занимал.

"инкрементальная выгрузка" - это то, как я описал?
18. VladimirL 780 15.09.18 14:34 Сейчас в теме
(17)
Да, инкрементальная выгрузка ведет себя именно так, как Вы описали. Но тогда переименования объектов отслеживать сложнее. Неактуальные версии файлов остаются в выгрузке до вечера, когда отработает задание по полной выгрузке. Про нее подробнее написано в конце страницы здесь: https://github.com/oscript-library/gitsync

При полной выгрузке gitsync помогает оперативно отслеживать переименования и удаления файлов. Мне показалось целесообразнее поработать над размером конфигурации, описанными в публикации методами, чем создавать отдельное задание на полную выгрузку (очистку неактуальных файлов). Ведь в таком случае информация об удалении файлов уйдет в GitLab / Fisheye либо от анонимного пользователя, либо от последнего, кто делал нормальный коммит. В общем будет неудобно смотреть историю изменений. Ведь конечная цель именно в том, чтобы корректно видеть изменения в увязке к задаче в таск-трекере, например Jira, проводить объективное ревью в системах вроде Upsource или Crucible и не получить проблем при загрузке конфигурации из репозитория, например на сервере сборок типа TeamCity.

За одно решается проблема с занимаемым базами разработчиков дисковым пространством. Если таких баз много, то вычищение из ERP лишних драйверов и древних макетов объемом по 20-40 Мб каждый, приносит пользу.

Но, если проблема с переименованием и удалением объектов медатаданных не кажется важной, то быстрая инкрементальная выгрузка подойдет.
19. tsukanov 65 15.09.18 14:38 Сейчас в теме
(18) Спасибо. Понял в чем проблема. Я просто думал что платформа при инкрементальной выгрузке сама удаляет файлы. Удивлен что это не так.
20. VladimirL 780 15.09.18 14:42 Сейчас в теме
(19)
Может быть что-то уже изменилось в новых версиях платформы. Там уже 8.3.14 готовят. Надо будет посмотреть. Новости по этой теме не отслеживал.
21. tsukanov 65 15.09.18 14:59 Сейчас в теме
(20) Проверил на 12 платформе. Файлы удаляются...
24. VladimirL 780 15.09.18 19:47 Сейчас в теме
(21)
Не могли бы Вы подсказать, какую последовательность действий выполняете? У меня не удается заставить платформу при инкрементальной выгрузке удалять неактуальные файлы вплоть до платформы 8.3.12.1529. Указываю ключ -update при выгрузке для инкрементальной выгрузке вместо полной. Файлы со старыми именами также сохраняются.

Скриншот прикрепляю. На нем виден путь к платформе и результат выгрузки справочников. В итоге переименовал все справочники. Каталог выгрузки содержит как файлы с новыми именами, так и со старыми.
25. tsukanov 65 15.09.18 20:19 Сейчас в теме
(24) Платформа 8.3.12.1595 (64)

Выгружал тупо через меню в конфигураторе )

Проверял так:
1. Добавил константу > выгрузил > файлы появились
2. Удалил константу > выгрузил > файлы удалились

ps Сейчас даже перепроверил. И удаление и переименование. Все отрабатывает как надо.
26. tsukanov 65 15.09.18 20:37 Сейчас в теме
(24) Проверил еще 8.3.10.2772
Тоже все работает

ps Сейчас еще из командной строки проверю
27. VladimirL 780 15.09.18 20:54 Сейчас в теме
(26)
Через конфигуратор выполняется полная выгрузка. Та же, что выполняется через gitsync в режиме полной выгрузки. Для инкрементальной необходимо указание ключа -update в командной строке, как на скриншоте выше. https://wonderland.v8.1c.ru/blog/inkrementalnaya-vygruzka-konfiguratsii-v-xml/. Получается, что в этом случае платформа, к сожалению, до сих пор не анализирует наличие "линших" неактуальных файлов и не удаляет их.

Поэтому и для gitsync все еще потребуется второе "ночное" задание для полной выгрузки, которое не сможет корректно проставить авторов изменений.
28. tsukanov 65 15.09.18 21:01 Сейчас в теме
(27) Ну пусть полная. Не в названии дело. Но она же идет меньше минуты на ERP и удаляет файлы.

ps Правда меньше минуты только в случае если были только добавления и изменения. При удалении оно дольше.
30. VladimirL 780 15.09.18 22:04 Сейчас в теме
(28)
О, действительно, добавление объекта метаданных приводит к тому что весь процесс при выполнении из конфигуратора выполняется очень быстро. Выходит при добавлении объекта выполняется инкрементальная выгрузка. Но стоило мне переименовать константу, как платформа снова начала выгружать конфигурацию полностью.

Однако если добавить еще одну константу, закрыть конфигуратор и выполнить команду 1cv8.exe config /F"E:\Databases\УТ 11.4" /N"Admin" /DumpConfigToFiles E:\ut_dump (без -update) то все же запускается полная выгрузка даже при наличии файла ConfigDumpInfo.xml. Даже если ничего в конфигурации не менять и снова выполнить эту команду - будет происходить полная выгрузка.

На платформе 8.3.12 она по субъективным ощущениям выполняется быстрее. Но при использовании gitsync время же тратится не только на выгрузку. Еще выполняется получение версии конфигурации (cf-файла) из хранилища, его загрузка в файловую базу и только потом выгрузка. Ускорение процесса в целом будет не так велико.

Надо будет смотреть что в версии gitsync 3.0 будет нового.
33. tsukanov 65 15.09.18 22:25 Сейчас в теме
(30)
Но стоило мне переименовать константу, как платформа снова начала выгружать конфигурацию полностью.


Ну видимо чисто технически инкрементальная выгрузка не всегда возможна (подозреваю это связано с ролями, например). Но у вас в gitsync это очевидно ровно также.
Тут уж ничего не поделать.

Еще выполняется получение версии конфигурации (cf-файла) из хранилища, его загрузка в файловую базу и только потом выгрузка. Ускорение процесса в целом будет не так велико.

Платформа сразу версию не умеет выгружать?
Я не в курсе. Ни разу не делал этого.
38. tsukanov 65 16.09.18 08:12 Сейчас в теме
(30)
Еще выполняется получение версии конфигурации (cf-файла) из хранилища, его загрузка в файловую базу и только потом выгрузка. Ускорение процесса в целом будет не так велико.


Судя по докам думаю вам стоит попробовать использовать ключ /ConfigurationRepositoryUpdateCfg.
Не нужно будет выгружать cf и загружать в файловую базу.

Последовательность действий одной выгрузки:
1. /ConfigurationRepositoryUnbindCfg
2. /ConfigurationRepositoryUpdateCfg -v <нужная версия>
3. /DumpConfigToFiles -update

Теоретически будет быстрее
29. tsukanov 65 15.09.18 21:19 Сейчас в теме
(27) В общем так. Платформа 8.3.10.2772 (64) из командной строки тоже все работает с инкрементальной выгрузкой

Последовательность действий в повершеле:
$1c = "C:\Program Files\1cv8\8.3.10.2772\bin\1cv8.exe"
$ArgList = @('DESIGNER', '/F C:\Users\admin\Documents\InfoBase', '/DumpConfigToFiles C:\temp\test_dump -Format Hierarchical')
Start-Process $1c -ArgumentList $ArgList
# Тут открыл конфигуратор и руками удалил объект
$ArgList = @('DESIGNER', '/F C:\Users\admin\Documents\InfoBase', '/DumpConfigToFiles C:\temp\test_dump -Format Hierarchical -update')
Start-Process $1c -ArgumentList $ArgList
# Тут файлы успешно удалились
Показать


ps Ну и дальше с ключом -update тоже все отрабатывает. Файлы добавляются/удаляются. Вроде как все норм.
31. VladimirL 780 15.09.18 22:11 Сейчас в теме
(29)
Посмотрите время изменения всех остальных файлов в выгрузке. Поменялось ли оно и стало ли совпадать со временем выполнения последней команды выгрузки?
32. tsukanov 65 15.09.18 22:19 Сейчас в теме
(31) Какая разница полная она или нет? )
Оно происходит быстро и удаляет файлы. Мне остальное не важно )

Я же делаю с ключом -update. Уж что там платформа делает без понятия.
34. VladimirL 780 15.09.18 22:29 Сейчас в теме
(32)
Да механизм хотелось бы понимать. Если бы у меня получилось воспроизвести Ваш результат, то вопросов было бы меньше. У меня же файлы не удаляются, что видно и на скриншоте выше и вот еще на этом. Мистика ) В любом случае, спасибо за исследование. Надо будет лучше изучить вопрос.

35. tsukanov 65 15.09.18 22:34 Сейчас в теме
(34) Я же приложил вам код на повершеле. Не знаю чем еще помочь.
36. tsukanov 65 15.09.18 22:43 Сейчас в теме
(34) Вопрос (чисто любопытство): как так получилось, что вы используете cmd и винду 7 в 2018 году?
37. VladimirL 780 15.09.18 23:20 Сейчас в теме
(36)
Много всего привязано к операционке, в основном курсов на uvfPlayer. У Курсов-по-1С можно запросить еще ключи при смене ОС, но многие поставщики курсов такого не позволяют. Тот же Инфостарт не выдает вторые ключи на курсы. Фактически вторую ОСь надо ставить или вторую машинку брать. Windows 10 на виртуалке запускаю.
23. sergey.novikov 50 15.09.18 15:54 Сейчас в теме
А не возникало проблем, что конфигурация, выгруженная из хранилища и загруженная в файловую версию, не сохраняется из-за превышения допустимой длины ключа индекса?
Недавно выхватил такую беду
40. sergey.novikov 50 17.09.18 12:05 Сейчас в теме
(23) Я к тому, что гитсинк 2.4.3 не поднимает эти эксепшены наверх, в результате трудно опередлить причину ошибки....
бывают и ошибки формата потока и прочая ересь
41. VladimirL 780 17.09.18 12:24 Сейчас в теме
(40) Да, с тем, что настоящая причина ошибки не всегда доступна из вызвавшей программы были проблемы. В таких случаях приходится выполнять команду экспорта вручную и если консольный вывод с параметром -verbose on все еще не дает нужной информации, то глубже зарываться. Например выгружать и загружать конфигурацию вручную. К счастью это бывает редко, если с конфигурацией, жестким диском и ключом или сервером лицензирования в целом всё в порядке.
42. sergey.novikov 50 17.09.18 12:40 Сейчас в теме
(41) Пробую сейчас играть с gitsync 3.0.0, пока в этом плане больше нравится, он более понятно сообщает в чем именно проблема
44. Evil Beaver 5252 17.09.18 19:36 Сейчас в теме
(23) Да, все косяки файловой версии, включая длину индекса и уже упомянутые тут лицензии будут всплывать на шаге загрузки cf во временную файловую базу.

gytsync не умеет работать с выделенной серверной базой для этого, насколько мне известно.
43. aleximuson 17.09.18 18:41 Сейчас в теме
Я вот немного не понял роль Jenkins'а...
Вы сборку/тестирование руками запускаете?
Или Jenkins здесь используется как продвинутый шедулер?

Просто я из прочитанной мною информации о Jenkins вывел для себя следующий сценарий его использования:
0. Для Git{Hub,Lab, etc} настраивается хук, которой соединяет репозиторий с Jenkins'ом
1. Коммитится что-то в репозиторий
2. git-хук дергает Jenkins API
3. Jenkins реагирует на это, запускает сборку/тестирование/деплой

Или я что-то не так понял?
45. VladimirL 780 17.09.18 23:45 Сейчас в теме
(43) Jenkins упомянут как следующий шаг развития системы, также как и интеграция с инструментами для код-ревью и системами учета задач на разработку. Чтобы не перегружать публикацию эту тему развивать не стал. В примерах, приведенных в публикации он не используется, за исключением одного скриншота.

Можно использовать его как продвинутый шедулер вместо планировщика Windows. В этом случае в качестве преимущества мы получим лучшее визуальное представление логов исполнения и визуальное представление сборок. Обработка хранилища, которая привела к появлению новых коммитов в репозитории, будет отображаться синим. Те запуски, которые не привели к новым коммитам - красным. Хотя это конечно зависит от Вашей реализации. Сервер сборок можно использовать и для более сложных сценариев, например, чтобы запускать другие задачи после обработки следующей версии хранилища. Запуск можно производить средствами самого сервера сборок.

Скрипт написан таким образом, чтобы код возврата после его выполнения был не равен 0 в случае, если в результате выгрузки из хранилища не произошло изменений или возникла исключительная ситуация. В Jenkins в декларативной сборочной линии или пайплайне следующими шагами могут быть отправка изменений в origin и/или запуск тестирования последней обработанной версии хранилища. Для декларативной сборочной линии эти послесборочные операции должны быть с признаком Push Only If Build Succeeds (для отправки изменений в origin) и Trigger only if build is stable (для задачи тестирования).

Можно вызывать задачу Jenkins и из самого скрипта или гит-хука через POST-запрос. В этом случае наверное будет проще передать в качестве параметра номер версии хранилища или хеш коммита. А можно и вызывать задачу как послесборочную операцию. Мне больше нравится последний вариант. Но здесь множество вариантов на любой вкус ))
47. aleximuson 18.09.18 06:51 Сейчас в теме
(45) Большое спасибо за развернутый ответ и вообще в целом за публикацию!
48. aleximuson 18.09.18 07:10 Сейчас в теме
Пока я вижу следующие проблемы, препятствующие использовать методику, описанную в статье:
1. Версия платформы. Думаю у многий полно легаси конфигураций, написанных и работающих в 8.2. Которые работают и даже поддерживаются. Насколько я понимаю gitsync работает только с 8.3 (?) В readme.md gitsync'а не нашел информации о требованиях к системе в целом и к платформе в частности.
2. Дергать хранилище при каждом чихе. Мне кажется не самой хорошей идеей периодически трогать хранилище и выгружать из него изменения. При подготовке к релизу в хранилище выкладываются тонны кода, разными группами, все это без того вызывает конфликты блокировок, так еще gitsync будет подноги лезть?.
3. Сборка при каждой закладке хороша, если используется методология от 1С, упомянутая в статье, где каждая закладка влечет за собой изменение версии конфигурации. Если в Вашей компании другой подход, например так называемый "релизный поезд". Все готовые фичи выкладываются в хранилище по мере их готовности, раз в неделю специально обученный человек говорит "баста, это будет новая версия". Захватывает корень, меняет версию конфы, ставит соответствующую метку. Вот тут, и только тут бы запустить сборку/тестирование/деплой всей конфигурации в целом.

ИМХО
50. VladimirL 780 18.09.18 09:55 Сейчас в теме
(48) Искренне не хотелось бы вызвать холивар. Но кажется указанные проблемы с невозможностью перейти с 8.2 на 8.3 и неверным, хотя и обычным для 1С, подходом к разработке в целом связаны.

При подготовке к релизу в хранилище выкладываются тонны кода

раз в неделю .... вот тут, и только тут бы запустить сборку/тестирование/деплой всей конфигурации в целом


Никакое автоматизированное тестирование применяться не будет, если его выполнение предполагается только перед релизом, а не хотя бы каждый день. Потому что пару раз сорвав обещанные сроки подготовки функционала из-за того, что тестирование перед релизом сообщило об ошибках, и наспех поправив эти ошибки, вызвав тем самым новые, идея непрерывного тестирования будет дискредитирована. Как в глазах руководства, так и в глазах разработчиков. Дальше под каким-нибудь предлогом типа нехватки времени или сложности написания тестов она будет заметена под ковёр. О фактической причине - неверном процессе, никто и не скажет ))

Никакое ревью кода не заработает, если оно будет выполняться после слива в хранилище большого количества готового, по мнению разработчиков, функционала. Просто не будет времени отключиться от прочих задач и несколько часов делать ревью. Даже если это будет делать один человек - толку мало. Внимание нельзя удерживать на коде коллеги столько времени, ошибки будут пропущены, особенно логические. В этом случае ревью перестает быть регулярным коллективным процессом, встроенным в общий процесс разработки. Опять же будет заметено под ковёр под благовидным предлогом типа "мы профессионалы и доверяем коду друг друга" , "ну оно же работает, а код мы исправим потом, лет через пять" и прочие социально приемлемые отмазки. Прибавьте к этому что разработчики обычно изначально больше мотивированы почитать Инфостарт или Хабр, нежели код друг друга.

Иначе говоря при таком процессе выгрузка в Git и подключение Upsource/Gitlab/Crucible в целом смысла не имеет.

Дергать хранилище при каждом чихе. Мне кажется не самой хорошей идеей периодически трогать хранилище и выгружать из него изменения.

Поверьте, хранилище не обидится за это. Вежливо предупредите его, что его файлы будут трогаться только на чтение, то есть на посмотреть. Если же оно проявит признаки испуга, то можно действовать постепенно. Может быть начать с раза в день, а не раза в 2-5 минут. Потом, когда хранилище привыкнет к такому дерганию можно будет и почаще подергать. Вот что делать с износом диска при чтении файлов хранилища и их последующем раскладывании на исходники, я не знаю. Можно конечно на RAM диски пересесть ))
nixel; Redokov; JohnyDeath; Evil Beaver; artbear; +5 Ответить
51. Aleximus_III 18.09.18 11:25 Сейчас в теме
(50) Легаси код - наследие предков, когда-то в бородатые времена написанная конфигурация. Мне встречались в основном отраслевые решения, аналогов которых не было на тот момент, написанные с нуля. Этот черный ящик как-то работает, есть не просит, но и его приходиться поддерживать и даже что-то дорабатывать/исправлять баги.
Никто не говорит что перевести это все на 8.3 невозможно. Просто никто на это не даст денег. Ну или не те и не так продают :)
Если Вы с такими конфигурациями не сталкивались, я Вам завидую :).

Автоматическое тестирование - да, слышали. Весь покрытый тестами, абсолютно весь, где-то в индустрии есть :)))
Но я не писал про автоматическое тестирование, просто тестирование, отделы целые имеются в компаниях, руками все тестируют. Ужасно? Каменный век? Бесспорно!

Про кодревью я тоже ничего не говорил. В целом много всякого пишут про процесс кодревью и хорошее и плохое, кто-то полностью за, и без этого разработка - не разработка. А кто-то говорит что люди злые, обижают тонкие чувства творца, и не так понимают процесс кодревью и его цели, и т.д. :))
Тут уже от команды и культуры отдельных разработчиков зависит. Надо оно или нет решать сугубо им.

Тут хотя бы с малого начать, с автоматической сборки поставки после изменения версии конфигурации. Что бы не руками обновлять тестовые базы. А уж потом думать о высоком (для индустрии, не из мира 1С, обыденном): автотесты, кодревью...

В общем хорошо когда все хорошо, и конфигурация на базе БСП, и версия платформы свежая, и программисты слышали такие слова как git, docker, CD/CI. А когда все это пока только Цель, а инструменты описанные в статье хочется использовать здесь и сейчас...

Что-то меня грусть и тоска одолела :(
52. VladimirL 780 18.09.18 12:50 Сейчас в теме
(51) Дело в том, что основной смысл применения Git в коллективе разработчиков 1С - это совместная работа над качеством кода, правильностью алгоритмов, структур данных. Снижение технического долга, о чем есть замечательный доклад Никиты Грызлова Управление техническим долгом - Концепция Continuous Inspection

Тот же быстрый доступ к истории кода имеет смысл только когда этой возможностью пользуются. А это невозможно, если коллеги воспринимают код друг друга согласно антипаттерну "Это-Не-Моя-Правка" : http://lurkmore.to/Анти-паттерн.

Если про это не говорить, то есть ли смысл вообще говорить про Git?

Автоматизированное тестирование и даже сборку можно сделать и без применения Гита. Достаточно фиксировать в каком-нибудь файле последнюю обработанную версию хранилища. Затем делать выгрузку следующей версии и обрабатывать ее. Для выгрузки версии хранилища в cf-файл есть простая консольная команда. Если начиная с определенной версии хранилища объявляется готовность именно этой версии к релизу, то это более простой вариант для выдергивания версии хранилища для релиза, чем через посредничество гита для этого. Это подход "в лоб" но если система уже работает так и менять процессы нет желания, то применить такой подход быстрее всего.


Если действительно хочется начать применять описанные инструменты - начните с код-ревью, ретроспектив и работы над процессом. С фиксации технического долга, возврата задач на доработку по причине некорректного/неоптимального кода, а не только по жалобам пользователей. С проверки на соответствие стандартам https://its.1c.ru/db/v8std. Начать кстати можно даже не выходя из экосистемы 1С : Автоматизированная проверка конфигурации

А дальше и остальные инструменты можно подключать постепенно.

Здесь основная проблема - отсутствие желания и/или мотивации работать над внутренним качеством, ввиду наличия во многих командах упомянутого выше антипаттерна, мотивированностью исключительно "внешними" потребностями пользователей, заточенностью исключительно на подход "ну работает же" и скорость разработки. А также нежелание делиться лучшими практиками, подходами с коллегами, приоритет более бытовых тем для разговоров, перед обсуждением кода. В крупных компаниях после этого бывает приглашают эксперта по технологическим вопросам в развивающемся красном плаще, чтобы нашел многолетние косяки и исправил ))


Если же в Вашей команде подобных антипаттернов нет или вы решили взяться за их исправление, то вероятность успеха высокая. Не думайте, что есть мега крутые команды, где взяли и покрыли всё тестами и за ними теперь не угнаться. Многие только в начале или середине пути. Это процесс постепенный и движется, если есть к нему интерес и регулярные усилия. Главное понимать без чего именно это "не взлетит". И это не только инструменты ))

За пределами 1С всё, о чем мы говорим, вообще воспринимается как должное и как неотъемлемая часть разработки. Java, .Net, даже PHP-разработчики во всю используют эти подходы и делают круглые глаза, когда узнают том, как сильна наша замкнутость на экосистеме 1С. А ведь у них тоже базы данных есть и релиз не всегда означает изменение только кода на PHP. У них тоже код часто связан со структурами данных в БД и должен меняться синхронно с изменением структуры БД.
nixel; Evil Beaver; aleximuson; +3 Ответить
54. Evil Beaver 5252 18.09.18 13:28 Сейчас в теме
(51)
а инструменты описанные в статье хочется использовать здесь и с

Инструменты в массе своей написаны еще во времена 8.2. И практически все развиваются с сохранением поддержки 8.2.
Есть редкие исключения, но gitsync поддерживает 8.2 и неуправляемые формы.
53. Evil Beaver 5252 18.09.18 13:25 Сейчас в теме
(48) мы гитсинкаем уже 3 года. Вы не правы. Правда, мне уже лень объяснять почему.. Вы пытаетесь рассуждать о вкусе молока по фотографии.
49. bash08 18.09.18 08:16 Сейчас в теме
Статья хорошая. Мы тоже в организации начинаем процесс модернизации разработки. Используем в разработке расширения. Сколько всего перечитал, нигде нет методики использования гит + расширения. Только если разрабатывать на EDT. Мы пока не готовы перевести всю разработку на EDT. Может быть у кого то есть опыт использования git + расширения?
55. Evil Beaver 5252 18.09.18 13:29 Сейчас в теме
(49) опыт в сообществе есть, но если брать именно автоматический gitsync (как утилиту с конкретной версией и функциональностью), то сейчас он этого делать не умеет. Ждет своего автора.
60. strange2007 132 19.09.18 11:11 Сейчас в теме
Отмечу только про обновление (личный опыт):
- Конфигурацию снимать с поддержки и вообще забыть про неё.
- Перед обновлением стандартную конфу снять с поддержки.
- Накатить свою подсистему на стандартную конфигурацию (предыдущий пункт)
- Обновить рабочую конфу или тестовую, которая в хранилище.
Всё. Никаких усложнений с поддержками и прочими танцами.

А статья интересная. Большая работа проделана. Такая глобальная разработка... не каждому под силу
VladimirL; +1 Ответить
61. elu.viro36 21.09.18 09:42 Сейчас в теме
А вывод из исходников обратно в базу каким образом происходит?
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Салехард
зарплата от 80 000 руб. до 200 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата от 100 000 руб.
Полный день


Программист 1С
Санкт-Петербург
Полный день

Программист 1С
Санкт-Петербург
Полный день