Отражаем хранилище в репозиторий 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    9149    78    4    

110

Особенности национального Workflow: Github Actions и OneScript

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

Сегодня мы посмотрим на Github Actions - встроенный инструментарий Github для автоматизации рабочих процессов. Разберем, что это такое, зачем и причем тут OneScript.

25.03.2024    1211    bayselonarrend    3    

37

Автоматизация процесса разработки с помощью сервиса GitFlic

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

GitFlic – первая в России полностью самостоятельная реализация сервиса для хранения репозиториев с исходным кодом. За три года разработки сервис GitFlic стал полноценным инструментом, которым можно заменить GitLab, GitHub и BitBucket. Расскажем о том, как выстроить в GitFlic процесс автоматического тестирования, статического анализа кода и сборки приложений.

05.03.2024    1868    user1989937    6    

15

OpenYellow - рейтинг открытых GitHub репозиториев для платформы 1С:Предприятие

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

Обновляемый топ GitHub репозиториев для 1С по всем языкам программирования и еще немного рассуждений про open-source.

05.02.2024    3785    bayselonarrend    15    

61

Насколько глубок 1С-ный GitHub?

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

Open-source проекты - важная часть мира программного обеспечения. 1С привычно держится немного в стороне от глобальных трендов, но бросить холодный статистический взгляд на положение дел мне показалось небезынтересным.

22.01.2024    7848    bayselonarrend    50    

86

TCP прокси-сервер хранилища конфигурации 1С

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

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    2784    kamisov    17    

57

Отдай корень! Библиотека OneScript для получения информации о захваченных объектах в хранилище

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

Хранилище конфигурации 1С - это инструмент групповой разработки. Работают с хранилищем следующим образом: захватывают какой-либо объект, редактируют, потом отдают его в хранилище. Хранилище помечает уже захваченные объекты и не дает возможности захватить их другим пользователям. Это рождает и самый большой недостаток хранилища - невозможность работы с одним объектом нескольких пользователей, например в случае доработки разных методов в одном большом модуле. Корень конфигурации - это самый верхний ее узел. Только захватив корень, мы можем добавить в конфигурацию новые общие модули, документы, справочники, регистры и подобное. Только захватив корень можно изменить настройки поддержки конфигурации. Соответственно, если корень захвачен одним программистом, другой программист не может добавить новые объекты или снять что-то с поддержки. Потому то и всплывает эта фраза - отдай корень, мне нужно тоже что-то добавить.

26.12.2023    1345    ardn    1    

26

Git Code Review - инструмент для рецензирования кода

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Конфигурации 1cv8 1С:ERP Управление предприятием 2 Абонемент ($m)

Git Code Review - инструмент, позволяющий быстро анализировать изменения из git-репозитория прямо в 1С

1 стартмани

20.12.2023    3963    59    salexdv    26    

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