Jenkins на службе 1С

Меня зовут Юрий Гончарук, я работаю DevOps-инженером в компании «Финтех Решения». Одна из моих задач – это настройка Jenkins.

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

• разбор хранилищ;

• настройка развернутых копий баз – когда мы поднимаем копию базы, смотрим;

• перезагрузка кластера – мы его тоже делаем через Jenkins;

• и управление доступом к базам для дежурных разработчиков.

Разбор 40 хранилищ

Начнем с разбора хранилищ.

Мы стараемся весь код хранить в Git, но разработка у нас по-прежнему ведется в хранилищах. Соответственно, у нас около сорока различных хранилищ – от УПП до ERP. Все их нужно разбирать в Git, потому что основной формат хранения, с которым мы работаем в дальнейшем – это Git. Хранилища – это среда внесения изменений непосредственно для разработчиков.

Для мелких «исправительных» расширений у нас есть отдельные проекты, в которые мы разбираем эти расширения через precommit1c – здесь участие CI/CD не требуется.

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

При попытке контролировать разработку в сорока с лишним хранилищах, появляются вопросы:

• Как сделать так, чтобы все эти хранилища разбирались?

• Как подключить в систему разборки новое хранилище?

• Как отключить хранилище от разборки при необходимости?

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

Мы создаем новое задание – его jenkinsfile показан на слайде. Задание совершенно несложное, буквально из четырех шагов. И настраиваем его на периодический разбор – чуть дальше покажу.

Все настройки для этого задания хранятся в конфигурационных файлах.

Т.е. задание используется шаблонное, а к нему – такие маленькие конфигурации, где задано:

• какие плагины подключать;

• дополнительные настройки плагинов;

• куда подключаться;

• куда синхронизировать.

Все это задается в файле конфигурации.

Как добраться до этого файла конфигурации? Мы решили, что так как каждое задание уникальное и имеет собственное имя в Jenkins, то и файл конфигурации будет иметь точно такое же название и будет располагаться в подключаемой библиотеке.

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

Теперь – то, что касается Gitsync.

Для разбора разных хранилищ нам нужен разный набор плагинов Gitsync. Каким образом это сделать?

Мы объявляем переменную GITSYNC_PLUGINS_PATH, и в ней инициализируем плагины. У нас есть список предопределенных плагинов:

• sync-remote

• limit

• check-comments

• check-authors

• increment и прочее.

Все эти плагины у нас подключены для всех хранилищ. И дополнительно через переменную env.Plugins мы можем передать какие-то еще.

Сборочная линия проверяет, что каталог плагинов существует, и, если его нет, инициализирует необходимые плагины по списку.

Это дает нам возможность для каждого разбора иметь свой собственный набор плагинов – очень удобная вещь.

Шаг синхронизации достаточно простой.

Задаем переменные окружения.

Отдельно через Credentials передаем учетные данные. Это очень важный момент, потому что их можно задать в командной строке явно, но самым безопасным и рекомендуемым способом является передача через Credentials – Gitsync эту функцию поддерживает.

Следующий вопрос, который перед нами встал – как часто разбирать.

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

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

Разворачиваем копии

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

Что мы делаем в копии?

• Обязательно обновляем нумерацию объектов, это прямо must have.

• И затем последовательно выполняем БСП-шные функции – запрещаем выполнение регламентных заданий.

• Удаляем настройки подключений ко всем внешним сервисам, чтобы разработчик случайно не запустил синхронизацию в копии. Мы сразу удаляем все настройки подключений и убираем эту проблему.

• Если нам все-таки нужно использовать какие-то внешние сервисы, мы переключаем на mock-заглушки либо на тестовые версии внешних сервисов.

• Поскольку у нас используется механизм копий баз данных, мы отключаем копии баз данных для копии базы данных. Звучит как рекурсия, но это разные механизмы.

• Следующий момент – у нас разработчики не имеют доступ на продуктовую базу, но мы им разрешаем заходить на копию. Поэтому мы настраиваем в поднятой копии доступ тем пользователям, которым нельзя в рабочую базу, но можно в копию.

• И еще у каждой базы есть своя специфика.

Мы это реализовали достаточно просто.

• Сделали отдельный репозиторий в GitLab, где хранятся исходники внешних обработок, которые выполняют эту настройку. Они там хранятся в прямо в XML-ках и при запуске заданий собираются. Всего набралось пять таких специфичных обработок: отдельно для УПП, Бухгалтерии, ERP и так далее. В каждом типе баз свои особенности.

• Для запуска задания, которое выполняет настройку базы, используется возможность Jenkins запускать задание через вебхук.

• Когда админ разворачивает копию базы на SQL, он дергает этот вебхук, и все.

• При окончании работы задания Jenkins публикует в канале Teams уведомление, и разработчики уже могут заходить.

Вот так вот выглядит pipeline, он достаточно простой.

Мы передаем имя базы через параметр – Jenkins поддерживает такую функцию.

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

Справа показано, как у нас выглядит обработка для настройки копии базы ERP.

«Who is on duty today?» – Кто сегодня дежурный?

Разработчики у нас не имеют доступа в рабочую базу, но есть исключение – это дежурство. Дежурства бывает ночные, на выходные, но самые интересные – это дневные дежурства, которые идут в рабочее время.

• Дежурным по очереди является каждый разработчик команды, причем дневное дежурство назначается на неделю. Мы утром включаем, а вечером выключаем разработчику доступ к рабочей базе.

• Для ночных дежурных доступ в базу открывается с 18:00 до 09:00 следующего дня.

• И в выходные разработчики заступают на дежурство с вечера пятницы до утра понедельника.

Расписание дежурств задается полностью в Teams, а в Jenkins настроена задача, которая по расписанию запускается, получает информацию из расписания Teams и разрешает или запрещает вход конкретных пользователей в базу.

Для этого у нас есть две небольшие библиотечки – для работы с Teams и для работы с Jira. Мы там реализовали далеко не всю функциональность API, только то, что нужно:

• авторизация;

• получение данных из расписания Teams;

• и получение данных для выдачи дежурным разрешения работать в Jira – дежурные помимо доступа к рабочей базе должны разбирать и классифицировать новые задачи в Jira.

Сложного в принципе тут ничего нет. Все делаем по документации к API.

Рестарт кластера одной кнопкой

Следующее – это перезапуск кластера.

Jenkins умеет работать не только с cmd, чтобы запускать скрипты на OneScript, у него есть отдельная функциональность для работы через PowerShell – эту функциональность мы используем для перезапуска кластера.

Кластер у нас большой, в основном рабочем кластере содержится 5 рабочих серверов – их нужно погасить в правильной последовательности, а потом поднять в правильной последовательности.

Руками это сделать можно, но сложно, потому что это нужно делать безошибочно и каждый раз. А такая ситуация обычно возникает из серии: «У нас все упало, давайте перезагрузим».

Чтобы трясущимися руками не ошибиться, у нас есть такое задание, которое это делает автоматически:

• перезапускает кластер;

• также завершает все рабочие процессы, которые штатно не завершились;

• очищает временные каталоги и каталоги сеансовых данных у кластера;

• убирает файлы журнала регистрации из каталога кластера – это связано с тем, что у нас журнал регистрации перегоняется в GreyLog практически онлайн, поэтому хранить его постоянно на рабочем сервере смысла не имеет;

• и потом запускает в определенной последовательности.

Вот так выглядит пайплайн, который запускает скрипт PowerShell.

Опять же через Credentials мы передаем имя пользователя и пароль. И запускаем скрипт PowerShell.

На слайде показан фрагмент скрипта PowerShell – мы подключаемся к удаленному компьютеру, используя объявленные в пайплайне переменные окружения.

А это – фрагмент команды для остановки сервиса на конкретной машине.

Из интересного – обратите внимание на то, что здесь используется модификатор области видимости «$Using». Он позволяет прокинуть локальную переменную в сессию. Если забыть его указать, можно долго мучиться – удивляться, почему ничего не работает.

Сборка и тестирование

Ну и «родная» функциональность Jenkins – build, test and deploy.

Сборку проектов, разрабатываемых в хранилище, мы, конечно, не производим, потому что там конфигурацию легко получить стандартными средствами – в любой момент можно вытащить из хранилища готовый CF версии.

А для сборки проектов, которые разрабатываются в Git, мы в Jenkins используем vanessa-runner, обернутый в скрипт на OneScript – фрагмент текста этого скрипта показан на слайде. Дополнительная обертка нужна, потому что в этом скрипте помимо вызова vanessa-runner обрабатывается дополнительная логика.

Справа показан шаг сборки расширения.

При построении проекта мы меняем номер версии – добавляем в номер текущей сборки. Это очень серьезный подводный камень.

В самом CF-файле в поле версии указано четыре числа через точку, и последняя циферка всегда ноль. Но когда мы собираем конкретный файл, мы эту циферку меняем на текущий build number.

Благодаря этому бинарные файлы всегда будут иметь уникальную версию – разработчику не нужно думать, поменял он версию или нет. Она всегда будет уникальна.

Здесь показан фрагмент кода – как мы на OneScript добавляем номер сборки. Этот код, может быть, несколько костыльный, но он работает.

Важно – после того, как мы поменяли номер сборки в MDO-файле конфигурации и собрали проект, нужно не забыть отменить изменения командой:

git restore <ИмяФайлаКонфигурации>

Чтобы сохранить бинарные файлы для дальнейшего использования, есть команда «Сохранение артефактов». Потом их можно использовать в других сборках.

Собрав версию один раз, мы можем использовать этот номер в любой другой задаче. Повторно артефакт собирать не нужно – мы его уже собрали, и он там лежит. Мы его просто используем для работы.

С построением разобрались, теперь тесты.

На слайде приведен пример команды, которая подключает расширение с тестами.

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

Мы подключаем расширение и запускаем базу, а потом второй командой «Запуск тестов» запускаем тесты с помощью XUnit.

Деплоим на прод

Следующий пункт – деплой, обновление рабочей базы.

Рабочих баз у нас тоже достаточно много, но для их обновления используется одна и та же конфигурация задания Jenkins. Мы не учитываем специфику каждой базы, они все обновляются по одному и тому же сценарию.

Параметры этого сценария мы точно так же получаем по имени джобы.

На слайде показаны те шаги, которые у нас делаются:

• мы закрываем активные сеансы;

• устанавливаем блокировку сеансов;

• обновляем;

• запускаем в режиме предприятия;

• и снимаем блокировку.

Здесь мы немного применили оптимизацию шагов – видите, у нас два шага выполняются параллельно:

• мы ждем завершения сеансов;

• и параллельно у нас обновляется база из хранилища.

Следующий шаг стартует только после их завершения.

А дальше все просто – обновляем конфигурацию, запускаем в режиме предприятия и снимаем блокировку.

Со снятием блокировки интересная штука – поскольку при первоначальном запуске мы накладываем блокировку на вход в базу, мы ее обязательно должны снять.

Что бы ни случилось в нашей джобе, мы должны снять блокировку.

Поэтому все шаги внутри пайпа у нас обернуты в catchError. Если мы ловим ошибку, то помещаем конкретный шаг как ошибочный, а buildResult у всей сборки выставляем как “NOT_BUILD”.

И последний шаг всегда снимает блокировку сеансов. Видите, тут даже в опциях указано retry(3) – то есть три раза пробуй, если что-то не получилось, еще два раза сделай.

Вот такая штука у нас используется.

Непрерывная проверка SonarQube

Следующий момент – проверка кода. Мы активно используем SonarQube, он подключается у нас практически ко всем репозиториям с кодом.

У нас есть несколько сценариев работы с SonarQube:

• есть типовой маленький pipeline, который просто проверяет проект;

• реализованы шаги, которые проверяют код – как для ветки, как для проекта, так и для мерж реквеста;

• ну и отдельный пункт у нас – прохождение порога качества.

Для простого анализа у нас есть совсем простой pipeline, в котором буквально два шага – проверить и дождаться прохождения порога качества.

В этот пайплайн мы передаем параметры проверки проекта:

• сколько памяти,

• сколько ждать тайм-аута проверки

• где хранятся настройки проверки SonarQube

Сам анализ включает в себя три параллельных шага:

• первый шаг – это проверка всего проекта целиком;

• потом – проверка конкретной ветки проекта;

• и следующий момент – проверка мерж реквеста.

На слайде показана разница между этими шагами – они отличаются тем, какие параметры будут переданы в SonarQube при проверке.

Очень важно, что бесплатная версия SonarQube Community Edition поддерживает только один режим работы – это проверка целиком проекта.

Анализ веток проекта и мерж-реквестов доступен только у старших редакций SonarQube.

Но сообщество SonarQube реализовало Community Branch Plugin, который позволяет использовать эту функциональность и для младшей версии.

Без Community Branch Plugin эти два последних шага были бы нерабочими, был бы только вариант №1. Спасибо сообществу SonarQube, они помогают и 1С-никам.

Следующий момент – порог качества SonarQube.

Для большинства проектов порог качества – это скорее сообщение о том, как мы работаем.

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

Вот примеры настройки порога для таких проектов. Для ветки.

И для мерж-реквеста.

Вот как мы проверяем порог качества.

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

К примеру, у нас есть небольшой проект, в котором процент покрытия 76 процентов (сейчас уже больше 80). Для новых версий этого проекта непрохождение порога качества по покрытию является терминальным. Не прошли – все, мерж-реквест не будет принят.

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

Вопросы

Декорирование мерж-реквестов у вас работает без проблем?

Да, работает. Без проблем. Какое-то время не работало из-за того, что использовалась некорректная связка ПО, но после того, как мы обновили и GitLab, и SonarQube на последнюю версию – все отлично работает, и все показывается.

Вы сказали, что используете хранилище, при этом делаете еще артефакты и прочее. Зачем хранилище?

У нас есть проекты и на Git, и на хранилище. Артефакты мы делаем для тех проектов, в которых разработка ведется в исходных кодах.

Вы сказали, что при деплое базы, если что-то пошло не так, вы в любом случае снимаете блокировку. А вы уверены, что блокировку точно можно снимать и работать в исходном режиме? Может быть, там что-то такое случилось, что мы немного порушили то, что было?

У нас пока примеров, когда все ломалось, не было. Поскольку у нас обновление базы подразумевает, что работают роботы, а не человек, то логика такая – мы запустили обновление базы и смотрим за результатом. Если обновление упадет по той или иной причине, туда уже зайдет человек и будет смотреть, в чем дело. И дальнейшее решение принимает человек, принимает не система. Мы разрешаем вход, но если что-то упадет, всегда есть человек, который за этим смотрит.

Почему именно Jenkins? Есть же много разных инструментов, например, GitLab CI. Если у вас Enterprise версия GitLab, почему бы сразу его не использовать? По коду видно, что в большей части используются скрипты на OneScript и Powershell. Почти всю эту функциональность можно перенести и на GitLab CI.

Да, мы именно так и хотели, чтобы сама логика была реализована именно в скриптах.

Почему именно Jenkins? Наверное, потому что так исторически сложилось: Jenkins использует комьюнити Инфостарта, о нем очень много было полезных докладов и статей.

В принципе, это все можно сделать и на GitLab CI. Здесь нет никакой проблемы.

Можно сделать и на других CI платформах, здесь нет ничего уникального. Здесь интересно только то, что можно делать и так, и так, и так.

Если ничего нет, то даже Jenkins уже хорошо.

Есть ли у вас опыт использования библиотеки от Никиты Грызлова?

Мы сознательно делаем так, чтобы не реализовывать на стороне Jenkins вообще никакую логику. У нас groovy – это максимум обертка. Те шаги, которые я показывал, просто перегоняют параметры в командную строку. Никакой бизнес-логики внутри нет.

Вся логика у нас написана либо в OneScript, либо в PowerShell. На groovy у нас логики нет. Groovy и pipeline отвечают только за логику прохождения шагов, но не за логику выполнения шагов.

А почему так? Для уменьшения порога входа, чтобы 1С-ники могли это делать?

В лучших практиках Jenkins прямо написано: «Не пишите логику на groovy». Там это чуть ли не в первом же абзаце написано. Раз не нужно писать логику на groovy, тогда на чем? Ответ очевиден, на 1С (т.е. на OneScript).

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.