Отражаем хранилище в репозиторий git, Jenkins'ом

16.06.22

Разработка - Групповая разработка (Git, хранилище)

Описание приемов по настройке копирования хранилища 1С в репозиторий git. С помощью gitsync, под управлением Jenkins.

Предпосылки

Да, мы традиционной ориентации староверы. Работаем в Конфигураторе, пользуемся хранилищем. Но уже испорчены влиянием opensource. И уже давненько выгружаем наши конфигурации в местный git.

Зачем?...

  • Ну удобно делать codereview. Правда, это пока получается почти постфактум, когда уже продуктив актуализирован до состояния хранилища.
  • Удобно смотреть blame (вину?) - какой участок кода каким коммитом был изменен.
  • Также видна история коммитов по определенному объекту.

Несколько лет назад ввели в инфраструктуру Jenkins. Он, в том числе, занимался выгрузкой хранилищ в местный наш git.

Реализованная на тот момент инфраструктура уже устарела - и структурно, и программно. Все работало на одном сервере Jenkins, без использования slave-узлов. Использовалась старая версия gitsync (которая еще без плагинов). Наконец, git-сервер (Bonobo) предоставлял самый базовый интерфейс и функционал. Настало время уже все поменять, обновить и улучшить. Все это в Windows-окружении.

Реализация

Ребята, полного и пошагового руководства здесь не будет. Ведь есть подробные статьи на эту тему: про Jenkins [1], про gitsync [2], и книга Mastering Jenkins. Расскажу лишь некоторые моменты, которые могут помочь в ваших реализациях.

Таки вот общая картинка прохождения процесса выгрузки хранилища в git.

 

 

  • Jenkins-master дает команду своему подчиненному (Jenkins-slave) выполнить некое действие (1).
  • А именно, выполнить команду библиотеки gitsync (2). 
  • gitsync читает изменения в хранилище (3), вычитывает необходимые и отправляет их в удаленный git-репозиторий (4).

Дальнейшее повествование будет несколько хаотичным - от менее объемных описательных частей к более крупным. И прошу прощения за не слишком техническое изложение - не являюсь штатным devops-инженером, а лишь энтузиастом.

Клиент git

Администраторы нам предоставили виртуальный Windows Server. Это не тот, на котором уже крутится действующий Jenkins, это новая единица.

Поскольку мы собираемся выполнять операции с git-репозиториями, то устанавливаем git-клиент.

Сервер git

Решено новый git-сервер развернуть на этой же предоставленной виртуальной машине. Для установки выбрали Gitea.

Процесс установки подробно расписан на домашней странице продукта, трудностей не возникло. Для работы Gitea требуется использование СУБД - также развернули Postgree, из поставки 1С. Не забываем для Gitea открыть порт в брандмауэре (3000 по умолчанию).

OScript

Этим интерпретатором мы будем выполнять команды, предоставляемые библиотеками автоматизации. Одна из библиотек - это gitsync, о ней напишу чуть позже.

Лучше устанавливать не в Program files. Так меньше проблем при обновлении библиотек или при их конфигурировании.

Библиотеки замечательно устанавливаются/обновляются пакетным менеджером opm. Также можно настроить работу менеджера через прокси - об этом написано на странице проекта. Кажется, когда-то раньше работа opm через прокси не поддерживалась. Приходилось идти на поклон администраторам для временного прямого доступа в интернет.

Jenkins

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

Как описано в документации Jenkins и в различных статьях, есть несколько режимов работы агентов. Поскольку мы работаем в Windows-окружении, то изначально я планировал запускать агентов в режиме Let Jenkins control this Windows agent as Windows service. Но что-то пошло не так, пара попыток сопряжения мастера и агента так и не увенчались успехом. Это, кстати, отодвинуло реорганизацию на полгода.

Во второй (успешной) попытке решили строить взаимодействие мастера и агента в режиме Launch agent by connecting it to the controller. В этом режиме на подчиненном узле должно быть постоянно запущено java-приложение, являющееся тем самым агентом.

Как описано в [1] , в настройках безопасности задаем порты, по которым будут общаться мастер и подчиненные. Выберем статическое значение, откроем порты на мастере и подчиненном в их брандмауэрах.

В статье [1] рассматривается динамическое создание инфраструктуры. При этом происходит запуск агента средствами автоматизации развертывания. Но в нашем случае вся инфраструктура "статична". И вот каким-то образом нужно автоматически запускать приложение агента - например, при перезапуске сервера с агентом.

На помощь приходит обертка WinSW. Удобно! Работает в виде службы, может обновлять файл агента перед запуском.

Работа обертки настраивается конфигурационным xml-файлом. И тут есть нюанс - имена узлов и атрибутов регистрочувствительны. Например, вот такой фрагмент конфигурационного файла не даст запустить службу:

<stoptimeout>5000</stoptimeout>

Приведем его к требуемому:

<stopTimeout>5000</stopTimeout>

В журнале событий системы при этом пишутся ошибки с какими-то ненайденными/неточными реквизитами. Можно в документации особо и не вычитывать, а править по месту возникновения.

 
 Пример конфигурационного файла

В узле download пропишем адрес, откуда подгружать файл агента, под каким именем сохранять локально.

В настройках путей есть фрагмент %BASE% - несложно догадаться, что это каталог, где расположен исполняемый файл WinSW. В моей реализации начально скачанный файл агента я разместил именно в нем.

Над содержимым <arguments> особо думать не нужно - просто скопируйте строку запуска из предлагаемой Jenkins'ом при настройке slave-узла. Только запускающее приложение (java.exe) нужно перенести в <executable>. Где берется командная строка запуска агента - опять же, смотрим в [1].

Gitsync

Как писал выше, это одна из библиотек хаба OScript. Про установку библиотеки написано в [2]. Опять же, коснусь только специфических моментов. А именно плагинов gitsync.

По нашей задаче мы должны закинуть содержимое хранилища на удаленный git-репозиторий. Соответственно, мы должны подключить нужный плагин (sync-remote).

Инициализируем плагины:

gitsync p init

Разрешаем использование всех плагинов:

gitsync p e -a

Проверям, что у нас теперь с плагинами - выводим список активных:

gitsync p ls

Видим нечто подобное:

 
 Список плагинов

 

C:\Windows\System32>gitsync p ls
Каталог плагинов: <C:\OneScript\lib\gitsync-installed-plugins>
Список плагинов:
 [on] [1.3.0] - increment - Плагин добавляет возможность инкрементальной выгрузки в конфигурации
 [on] [1.3.0] - limit - Плагин добавляет возможность ограничения на минимальный, максимальный номер версии хранилища, а так же на лимит на количество выгружаемых версий за один запуск
 [on] [1.3.0] - check-authors - Плагин добавляет функциональность проверки автора версии в хранилище и файла AUTHORS [on] [1.3.1] - check-comments - Плагин добавляет функциональность проверки комментариев в хранилище
 [on] [1.4.1] - smart-tags - Плагин добавляет функциональность автоматической расстановки меток в git
 [on] [1.3.0] - tool1CD - Плагин заменяет использование штатных механизмов 1С на tool1CD при синхронизации
 [on] [1.3.0] - unpackForm - Плагин добавляет функциональность распаковки обычных форм на исходники
 [on] [1.3.0] - disable-support - Плагин снимает конфигурацию с поддержки перед выгрузкой в исходники
 [on] [1.3.0] - sync-remote - Плагин добавляет функциональность синхронизации с удаленным репозиторием git
 [on] [1.3.0] - edtExport - Плагин добавляет возможность выгрузки в формате EDT. Важно: Для работы плагина необходимы установленные EDT и Ring
 [on] [1.0.0] - replace-authors - Плагин добавляет функциональность замены автора коммита

 

Стоит обратить внимание на плагин edtExport. В его описании не зря написано, что:

Важно: Для работы плагина необходимы установленные EDT и Ring

Даже если вы не планируете использовать этот плагин (не будете указывать его специфические ключи), плагин все равно будет инициализироваться при выполнении команд gitsync. И это может привести к ошибке вида:

КРИТИЧНАЯОШИБКА - {Модуль C:\OneScript\lib\gitsync-installed-plugins\gitsync-plugins\src\Классы\edtExport.os / Ошибка в строке: 148 / Не заполнено имя проекта}

Поэтому плагин следует деактивировать.

А теперь про пути установленных плагинов...

Если посмотреть на лог вывода установленных плагинов, то видим, что в нем выводится путь (Каталог плагинов), где расположены установленные плагины. Если не предпринять специальных действий, то плагины будут установлены в профиле пользователя. Это может привести к тому, что отлаженный скрипт вдруг не станет работать под управлением Jenkins. Например, мы залогинились на настраиваемом сервере под своей доменной учеткой, отладили работу скрипта выгрузки хранилища. Но не приняли во внимание, что агент Jenkins у нас работает, скорее всего, под другой учеткой. Агент поищет плагины в своем профиле и, конечно, не найдет. И свалит задачу сборки с ошибкой...

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

  • GITSYNC_PLUGINS_PATH
  • GITSYNC_PLUGINS_DIR
  • GITSYNC_PL_DIR

Про эти переменные, кстати, не написано в документации - пришлось покопаться в исходниках.

Настройка сборочной линии

Самое первое - нужно определиться с учеткой, от имени которой будет работать агент. Например, у этой учетки должны быть доступы к сетевым файловым ресурсам (к хранилищу, то бишь). Соответственно, работу обертки WinSW тоже нужно настроить на запуск от имени этой учетки.

Про gitsync и его плагины написано выше. Устанавливаем по фиксированному пути, настраиваем состав плагинов.

Для задачи синхронизации хранилища с удаленным репозиторием git нужен и локальный репозиторий. Определяем (создаем) каталог с локальным репо. Инициализируем git-репозиторий - выполняем git init или пользуемся каким-либо интерактивным инструментом типа TortoiseGit.

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

fatal: unsafe repository ('C:/Jenkins/1C_confs/Конфигурация' is owned by someone else)
To add an exception for this directory, call
git config --global --add safe.directory 'C:/Jenkins/1C_confs/Конфигурация'}

Предлагаемый (git'ом) в ошибке рецепт у меня так и не сработал. Расширение прав безопасности для учетки агента тоже не дало эффект. В итоге, воспользовался материалом статьи и применил команду TAKEOWN - сделал всех администраторов владельцами репозитория:

takeown /F c:\Jenkins /A /R

Затем инициализируем этот же репозиторий командой gitsync init.

Для сборочной линии используем обычный freestyle-проект (задача со свободной конфигурацией). В этой задаче добавляем шаг сборки - Выполнить команду Windows. Пишем скрипт для выполнения синхронизации.

Для скрипта удобно воспользоваться возможностью передавать параметры скрипта через переменные окружения. И тогда скрипт будет иметь понятный вид:

set GITSYNC_STORAGE_PATH=\\DEVEL\stg\УОР\Конфигурация\
set GITSYNC_WORKDIR=1C_confs\Конфигурация
set GITSYNC_REPO_URL=http://reposerver:3000/gitsync/uor.main.stg.git
set GITSYNC_STORAGE_USER=user
set GITSYNC_DOMAIN_EMAIL=domain.ru
set GITSYNC_EMAIL=domain.ru
set GITSYNC_TEMPDIR=1C_confs\gitsync.tmp
set GITSYNC_REMOTE_PUSH_N_COMMITS=2
set GITSYNC_LIMIT=0
set GITSYNC_REMOTE_PUSH_TAGS=true
set GITSYNC_REMOTE_PUSH=true
set GITSYNC_SKIP_EXISTS_TAGS=true
set GITSYNC_TASK_PREFIX=#

gitsync s --numerator

Не забываем про метки в линии сборки и в настройках slave-узла, чтобы собрать именно на нужном сервере.

Заключение

Ну вот, с удовлетворением прочитали в консоли задачи сборки:

ИНФОРМАЦИЯ - Завершено выполнение команды <sync>
Started calculate disk usage of build
Finished Calculation of disk usage of build in 0 seconds
Started calculate disk usage of workspace
Finished Calculation of disk usage of workspace in  7 second
Finished: SUCCESS

Теперь историю разработки можем смотреть без долгих вычитываний из хранилища. Возможно, захотим еще и натравить bsl-сервер на полученный репозиторий. А может еще и замутим авто-сборку подключаемых отчетов и обработок через git-репозиторий. Но это уже другие истории.

Надеюсь, что кому-то статья поможет обойти грабли. Всем удач в автоматизации!

git gitsync хранилище jenkins

См. также

Системы контроля версий для 1С-разработчиков.

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    7010    64    4    

87

Jenkins на службе 1С

Групповая разработка (Git, хранилище) Бесплатно (free)

Основная специализация Jenkins – это, прежде всего, CI/CD. Но его можно использовать и для других важных задач: разбора хранилищ, настройки копий баз данных, раздачи прав пользователям, рестарта кластера и проверки кода проектов.

19.07.2023    1141    yukon    4    

11

Приемы быстрой работы в EDT/Git

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Статья даёт ответы на некоторые вопросы, возникающие у разработчиков, которые погружаются в океан технологий EDT и Git, омывающий царство DevOps... Сколько и какие ветки нужны? Какой репозиторий выбрать? Кто должен сливать доработки в мастер ветку или ветку версии? Как не тратить время в EDT на ресурсоёмких операциях? Зачем нам сборочный конвейер и как его построить? Зачем нам нужно тестирование и как его реализовать? Как вести разработку, если есть разработчики, не умеющие вести разработку в EDT или не имеющие технической возможности, но нам нужны их skills в 1С? Что такое фантомы и нужно ли с ними бороться? Как слить 20 доработок с конфликтами и уложиться в 4 часа? Опыт использования модных технологий в реальных проектах.

30.03.2023    6097    check2    10    

81

Получаем статистику по git-репозиторию в разрезе разработчиков

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Бесплатно (free)

Итак! Представим, что наступил момент, когда разработка через исходный код реализована на предприятии в полном объеме. Мы разрабатываем в EDT или конфигураторе (но выгружаем конфигурацию в исходный код), версионируем внешние отчеты и обработки и расширения, собираем релизы, проверяем код статическим анализом, в разработке царит гармония и мир. Красота! Но менеджерам этого мало, всегда хочется чего-то еще, и вот мне прилетает задача - дай статистику по вкладу в код каждого разработчика.

13.03.2023    1850    ardn    3    

27

Формула успешного внедрения DevOps и Agile в 1С: от неудачи к неудаче без потери энтузиазма

Групповая разработка (Git, хранилище) Управление проектом Бесплатно (free)

На конференции Infostart Event 2021 Post-Apocalypse выступил директор практики БИТ:ERP компании Первый БИТ Глеб Стальной. В ходе доклада он рассмотрел трансформацию проектного подхода в продуктовый, рассказал про имплементацию «современных» практик DevOps и продемонстрировал инструменты для разработки, взаимодействия с бизнесом и клиентами, применяемые в его команде.

27.02.2023    1640    glebushka    2    

12

Кровь, пот и GIT

Групповая разработка (Git, хранилище) Бесплатно (free)

Ведущий разработчик 1С Андрей Карпов на конференции Infostart Event 2021 Post-Apocalypse поделился ошибками, которые совершают новички в работе с GIT. В докладе четыре кейса с пошаговыми инструкциями, которые позволят не допускать конфликтов в разработке.

17.01.2023    7570    karpik666    45    

65

Прокси хранилища 1С (IIS, OneScript)

Групповая разработка (Git, хранилище) OneScript DevOps и автоматизация разработки Платформа 1С v8.3 Россия Бесплатно (free)

Избавляемся от версионной зависимости, проверяем комментарии, вызываем веб-хуки, делаем красивые пути. И все это на привычном IIS и понятном OneScript.

08.12.2022    6316    kamisov    46    

89

Что, если Continuous Integration – это прежде всего практика, а не набор инструментов?

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Бесплатно (free)

Рано или поздно многие компании приходят к практикам DevOps. И начало этому – Continuous Integration. О том, что происходит в команде специалистов 1С, когда они переходят на Git, и почему простое внедрение CI-инструментов не решает проблему подходов к разработке, в докладе на Infostart Event 2021 Post-Apocalypse рассказал руководитель компании ПрогТехБизнес Александр Анисков.

07.12.2022    1909    vandalsvq    0    

23
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Lucechiaro 17.09.22 16:03 Сейчас в теме
Большое спасибо за статью!
Хорошо, что она попалась мне вовремя. Я сэкономил кучу времени при настройке GitSync.
ImHunter; +1 Ответить
Оставьте свое сообщение