Каталог решений - Отражаем хранилище в репозиторий git, 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>

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