Быстро в Jenkins

Публикация № 1681427 21.06.22

Приемы и методы разработки - DevOps и автоматизация разработки

Написать свою сборочную линию для решения на 1С – задача нетривиальная: собрать конфигурацию из исходников, конвертировать между форматами, запустить множество инструментов, агрегировать результаты, сформировать отчеты... А хочется ведь просто ЗапуститьСвоюСборку()... Можно? Можно! О том, как создать сборочную линию за 5 минут в формате «Далее-далее-готово» на конференции Infostart Event 2021 Moscow Premiere рассказал Никита Федькин.

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

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

Я очень надеюсь, что у вас уже есть какие-то элементы контура CI/CD или как минимум вы собираетесь в скором времени начать настройку этого контура.

Предположим, что у вас уже:

  • установлен Jenkins;

  • есть какой-то Git-сервер, например, GitLab;

  • есть пустой SonarQube;

  • файлы конфигурации уже хранятся на Git-сервере;

  • есть сценарии тестирования на Vanessa Automation;

  • и есть скрипты для Vanessa-runner.

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

Мой доклад будет про то, как связать все эти элементы между собой, как начать использовать Jenkins с минимумом усилий и кода, если вдруг (с чего бы это, не правда ли?) вас занесло в 1С.

 

Как выглядит сборочная линия в 1С, и в чем проблема масштабировать сборочные линии между командами и проектами

 

 

В основе работы с серверами сборок лежит понятие «Сборочная линия» или в английском варианте - «pipeline». Второй популярный перевод этого термина на русский язык – конвейер.

Наш код преобразуется прямо как продукт на конвейерном производстве:

  • сначала из россыпи исходников возникает некий бинарный артефакт (конфигурация);

  • конфигурация развертывается в какой-то базе тестовом окружении;

  • путем запуска тестов база преобразуется в протестированное решение;

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

 

 

На слайде пример простейшей сборочной линии в интерфейсе Jenkins, взятый из интернета.

Храбрым ребятам из туториалов даже сборка релиза не нужна. Они собрали артефакт, протестировали и сразу на прод деплоят, без каких-либо промежуточных шагов.

Складывается ощущение, что сборочная линия – это просто.

И да, чаще всего это просто – для других языков программирования, для других экосистем и других типов приложений. Но не в 1С. Разве у нас когда-нибудь было просто?

 

 

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

  • нам нужно базу создать;

  • нужно загрузить туда правильную конфигурацию;

  • нужно нажать на синий бочонок;

  • потом эту базу нужно запустить, чтобы там выполнить все нужные миграции.

И только после этого мы можем там что-то запускать.

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

 

 

В-третьих, все еще больше усложняется, если у вас появляется несколько проектов или несколько команд.

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

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

 

 

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

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

Мне в какой-то момент все это надоело. Надоело копипастить все эти скрипты из проекта в проект. Надоело объяснять, что значит то, что здесь написано.

Хочу проще.

 

 

Хочу одной простой командой pipeline1C(), как на слайде.

 

Предпосылки появления jenkins-lib

 

 

Итого при настройке Jenkins для 1С мы имеем три указанные проблемы:

  • многослойность самого процесса;

  • масштабирование на другие проекты и команды;

  • и сложность имеющихся скриптов Jenkinsfile.

 

 

На Инфостарте есть несколько статей на тему унификации сборочных линий, крутящихся вокруг идеи единой сборочной линии для всех проектов.

Валерий Максимов на Infostart Event в 2019 году выступил с прекрасным докладом, где представил идею «библиотечного» Jenkinsfile, который загружается извне репозитория, и на который накладываются настройки из файла внутри репозитория.

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

 

 

Хочу представить вам проект под названием «jenkins-lib».

Проект опубликован на GitHub, имеет открытую лицензию MIT. В репозитории помимо исходного кода можно найти и инструкцию по использованию.

 

 

Что же такое jenkins-lib?

Это библиотека для Jenkins, которая создана по специальной технологии разработки библиотек под названием shared library.

jenkins-lib представляет собой готовую сборочную линию для 1С, с помощью которой вы можете настроить процессы непрерывной проверки качества вашего программного решения.

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

 

 

Цель проекта довольно проста. Сделать так, чтобы использование Jenkins и 1С перестало быть адским мучением.

 

 

А стало райским наслаждением.

 

Возможности и особенности библиотеки jenkins-lib

 

 

Что вам может дать эта библиотека?

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

  • во-первых, библиотека поддерживает два формата исходников – она умеет работать и в формате EDT, и в формате выгрузки из конфигуратора;

  • она может создать информационную базу, может ее проинициализировать и выполнить операции по первоначальному запуску;

  • операции проверки качества вашего решения выполняются параллельно;

  • в рамках проверки доступен запуск BDD-сценариев с помощью Vanessa Automation или bddRunner из Vanessa-ADD, запуск дымовых тестов;

  • есть поддержка статического анализа средствами EDT и вырезание из результатов ошибок в модулях на поддержке;

  • есть синтаксический контроль конфигуратора;

  • есть запуск анализа SonarQube.;

  • все это сопровождается публикацией результатов сборки – либо в Allure, либо в jUnit

  • и отправкой результата сборки в телеграм или электронную почту.

 

 

В основе библиотеки лежит понятие «соглашения по конфигурации». Оно базируется на трех довольно простых принципах.

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

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

  • И в-третьих, у вас всегда остается возможность подтюнить какие-то настройки под особенности именно вашего проекта.

Если вы знаете и понимаете правила, по которым работает библиотека, и ваш Jenkins корректно (с точки зрения библиотеки) настроен, вы можете свести изменение настроек к минимуму.

 

 

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

Казалось бы, что там устанавливать? Но никогда не стоит забывать про кучу дополнительных галочек.

 

 

Настройку библиотеки можно разделить на два больших блока.

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

Для начала, нужно вообще рассказать Jenkins, что такая библиотека где-то существует, как ее можно подключить и как использовать. Делается это довольно просто. В настройках Jenkins в разделе «Конфигурация системы» находите подраздел Global Pipeline Libraries и добавляете туда новую строчку:

  • указываете имя библиотеки;

  • указываете, из какой ветки, тега или хэша коммита брать версию по умолчанию;

  • отмечаете флаг «Load implicitly», чтобы ее можно было загружать автоматически во все ваши сборочные линии без каких-либо дополнительных шагов;

  • отмечаете флаг «Allow default version to be overridden» – оставляете возможность переопределения версии;

  • и указываете репозиторий проекта
    https://github.com/firstBitMarksistskaya/jenkins-lib.git.

Что вообще такое «версия по умолчанию»? Как я сказал, вы можете выбрать конкретную ветку, тег или хэш коммита. Я рекомендую вам использовать конкретный релиз – это защитит вас от возможных изменений в новых версиях. Несмотря на то, что библиотека разрабатывается уже больше полутора лет, в настройки иногда вносятся изменения, ломающие обратную совместимость. А если вы останетесь на каком-то конкретном релизе, то вы сможете плавно мигрировать на новую версию, и при этом не порушить ваши остальные проекты сборки.

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

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

 

 

Как вы, наверное, знаете, все задачи сборки выполняются на так называемых «агентах».

По своей сути, это обычные подключенные к Jenkins рабочие машины с установленным на них дополнительным софтом.

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

 

 

jenkins-lib в своей работе опирается именно на метки агентов – причем ему нужно несколько меток:

  • Для минимального запуска библиотеки у вас должен быть агент с меткой «agent». Никаких специальных настроек на этом агенте выполнять не нужно, это может быть буквально любая машина, которая подключена к вашему Jenkins – лишь бы у него была такая метка. На агенте с меткой «agent» будет выполняться минимальный ряд операций по преднастройке вашей сборочной линии.

  • Если вы планируете выполнять операции, требующие установленной платформы 1С, у вас должен быть агент с меткой, совпадающей с маской версии платформы – например, «8.3» или «8.3.18». На этом агенте должна стоять платформа указанной версии (в том числе конфигуратор) и OneScript. Версию платформы вы всегда сможете указать вплоть до конкретного билда – просто помните, что, если вы хотите собирать на конкретном билде, у вас должен быть агент, который называется точно так же.

  • Хотите анализировать проект на SonarQube – нужен агент с меткой «sonar».

  • Также логично, что для работы и для статанализа EDT нужен агент с меткой «edt».

  • И для ряда служебных операций по трансформации результатов нужен агент с меткой «oscript». В принципе, это может быть тот же самый агент, на котором стоит платформа, но у него значительно меньшие требования по вычислительным мощностям, поэтому я выделил его отдельно.

 

 

Вы можете поднимать агенты любым удобным вам способом – главное, чтобы на них были нужные метки.

Это могут быть как железные сервера, так и виртуальные машины или контейнеры. Если вы готовы с развлечению с Docker, могу посоветовать посмотреть мой доклад с Infostart Meetup Kazan 2020, где я рассказывал про то, как собрать Docker-образы агентов и подключить их к Jenkins с помощью плагина Docker Swarm, работающего по концепции Cloud Provider.

 

Настройка сборочной линии для проекта

 

 

Когда мы настроили Jenkins, можно переходить к созданию сборки под ваш конкретный проект.

Библиотека заточена под работу в задачах сборки с типом Multibranch pipeline.

Как следует из названия, Multibranch pipeline – это в первую очередь pipeline, задача, все шаги которой описывается скриптом в файле Jenkinsfile.

Во-вторых, это мультибранч, такой тип задачи, который поддерживает параллельную работу сразу с несколькими ветками. У каждой ветки будет свой статус сборки.

Причем всю работу по созданию сборок под каждую ветку Jenkins берет на себя. Вам лишь нужно будет указать, как часто опрашивать репозитории, чтобы узнать, что там появились новые изменения в ветках. В самом простом варианте вы можете сказать, что мы просто раз в пять минут смотрим, поменялось ли что-нибудь в репозитории и запускаем сборки. Или вы можете настроить веб-хуки со стороны GitLab, например,

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

 

 

И конечно же, нам нужен сам Jenkinsfile.

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

Просто мечта, на мой взгляд.

 

 

Что произойдет, если вы запустите такую сборку без каких-либо дополнительных настроек?

Если все настроено правильно, то через несколько секунд Jenkins порадует вас зеленой сборкой.

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

Но если серьезно, то под капотом выполнилось несколько довольно важных операций.

  • Во-первых, на единственном зеленом шаге с именем «pre-stage» Jenkins попробует склонировать ваш репозиторий. Это тоже может случиться не всегда, если вдруг оказались неправильные настройки по авторизации на Git-сервере в Jenkins или неправильные настройки на машине агента для диспетчера учетных данных (Git Credential Manager для Windows).

  • Во-вторых, библиотека попыталась прочесть конфигурационный файл с настройками jobConfiguration.json в корне папки проекта. У вас его пока нет, поэтому применились настройки по умолчанию. И в этих настройках по умолчанию никакие шаги сборки далее не выполняются. Соответственно, все шаги пропустились, и сборка успешно завершилась.

 

Анализ на SonarQube

 

 

Знаете, что мы будем запускать в первую очередь? Всем же нужен Sonar? Давайте с него и начнем.

Базовая настройка Jenkins на анализ в SonarQube в принципе не отличается от этой настройки для других способов построения сборочных линий.

В глобальных настройках Jenkins в разделе «Конфигурация системы» нужно добавить сервер SonarQube и указать:

  • его имя;

  • URL-адрес;

  • токен аутентификации.

А уже в каждом вашем конкретном проекте в корень репозитория вам нужно положить файлик «sonar-project.properties», где указать параметры анализа:

  • sonar.projectKey – ключ проекта (его краткое имя);

  • sonar.sources – относительный путь к папке исходников;

  • sonar.sourceEncoding – кодировку исходников;

  • sonar.inclusions и sonar.exclusions – маски файлов, которые мы включаем/выключаем из анализа. Не забываем ограничивать расширения анализируемых файлов, ведь ненужный анализ XML и HTML можно ждать вечно.

Теперь переходим к самому интересному – как же заставить Jenkins запустить этот статический анализ?

 

 

Для включения шага сборки нам нужно в корне репозитория разместить JSON-файл с названием jobConfiguration.json.

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

Для включения шага анализа с помощью SonarQube создадим элемент «stages» и его параметру «sonarqube» установим значение «true».

 

 

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

Например, с помощью параметра useSonarScannerFromPath для шага sonarqube можно не искать sonar-scanner в переменной окружения PATH, а сказать Jenkins, чтобы он устанавливал sonar-scanner на агент, используя механизм установки утилит.

 

Автодополнение при составлении конфигурационного файла

 

 

Для вашего удобства библиотека содержит файл schema.json, который сильно помогает в редактировании этого конфигурационного файла в текстовых редакторах.

При составлении своего конфигурационного файла вы можете в начало добавить строку:

"$schema": "https://raw.githubusercontent.com/firstBitMarksistskaya/jenkins-lib/master/resources/schema.json"

В результате при добавлении в этот файл новых опций будет доступно автодополнение.

На скриншоте пример из Visual Studio Code. Здесь открыто окно автодополнения, в котором как раз доступен список параметров на самом верхнем уровне файла.

 

 

Мы выбираем «stages» – получаем список доступных для включения шагов.

 

 

Выбираем шаг «sonarqube» – видим значения, которые мы можем установить этому параметру.

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

В подсказке также работает проверка типов – если вдруг вы в параметре, в котором нужно ввести строку, укажете число, Visual Studio Code заботливо вас предупредит волнистой линией и красным крестиком – скажет, в какой строчке у вас произошла ошибка.

 

 

Итак, мы добавили в корень нашего репозитория файл sonar-project.properties и строчку про шаг sonarqube в конфиг jobConfiguration.json.

Что на выходе?

На выходе наша сборочная линия, которая обзавелась новым зеленым кружочком «SonarQube».

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

 

Анализ EDT

 

 

Но это только начало!

Идем дальше – как насчет подключения статического анализа средствами EDT? Видели же, когда вы код редактируете, у вас EDT-шный линтер сразу показывает, где есть ошибки. Вы это можете автоматизировать с помощью утилиты ring, которая входит в состав EDT.

С точки зрения библиотеки вам нужно всего лишь в конфигурационный файл добавить параметр edtValidate и поставить ему значение true.

Что мы получаем на выходе:

  • У нас закрасился зеленым кружочек «Трансформация в формат EDT», что в принципе логично – раз изначальная конфигурация лежит в репозитории в формате выгрузки из конфигуратора, значит, ее нужно сконвертировать для EDT, чтобы EDT понимала, что с ней делать.

  • Затем закрасился кружок «EDT контроль» в секции «Проверка качества», в котором как раз и запускается валидация средствами утилиты ring и EDT.

  • И дальше закрасился шаг «Трансформация результатов», где по умолчанию из результатов анализа вырезаются файлы на поддержке (те, которые с «полным замочком»).

И заметьте, все это – без единого скрипта с вашей стороны.

 

 

На стороне SonarQube появятся новые замечания с маркером «EDT», привязанные к конкретным файлам и строкам в коде.

А на стороне Jenkins в артефактах сборки у вас останутся файлы:

  • .log – лог рабочей области;

  • edt-generic-issue.json – результат анализа в формате generic-issue

  • edt-validate.out – результат анализа в родном формате для EDT, в csv.

 

Синтаксический контроль модулей 1С

 

 

Теперь давайте все-таки попробуем подключить нашу сборочную линию к 1С.

Какая самая простая проверка, которую может дать нам 1С? Синтаксический контроль! В него же встроена и проверка модулей.

Надеюсь, вы догадались, к чему я веду. Мы взводим новый флаг «syntaxCheck» в значение «true» – и вуаля!

На этот раз шаг «Синтаксический контроль» у нас подкрашивается желтым, что символизирует о том, что обнаружились какие-то ошибки.

Конфигурации без ошибок не бывает, поэтому неудивительно.

 

 

Результаты синтаксического контроля сохраняются в формате jUnit.

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

Отдельно в артефактах сборки у вас сохраняется лог проверки от конфигуратора syntax.xml.

А вас в запуске конфигуратора ничего не смущает? В том, что мы взяли и запустили конфигуратор. Откуда взялась база? Мы же вроде ничего не создавали.

 

Подготовка базы

 

 

Давайте разберемся, что вообще происходит на этапе подготовки информационной базы?

Если вы успели рассмотреть скриншот сборочной линии с предыдущего слайда, там еще закрасились зеленым кружочки «Создание ИБ» и «Архивация ИБ».

Сначала создается пустая информационная база в текущей рабочей области сборки.

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

Туда вы можете внести два новых секрета:

  • путь к хранилищу – секрет с типом secret text;

  • связка логин-пароль для хранилища – секрет с типом username with password.

Но затем возникает вопрос – как сборочная линия узнает идентификаторы получившихся секретов? Для этого есть два решения:

  • Когда вы по умолчанию заводите секрет, у него идентификатор генерируется в виде UUID. Вы можете эти UUID-ы указать в файле jobConfiguration.json в специальной секции «secrets» и библиотека будет использовать их в процессе сборки.

  • Второй вариант – вы можете сразу “правильно” указать идентификаторы этих секретов в Jenkins и тогда библиотека подберет их автоматически.
    Предположим, что ваш проект живет где-то на вашем Git-сервере по пути git.my.com/infostart/erp, где Infostart – это группа проектов, а ERP – это сам проект.

    • Если вы заведете секрет «infostart_erp_STORAGE_PATH», библиотека поймет, что это путь к хранилищу и будет его использовать для создания информационной базы.

    • То же самое для секрета «infostart_erp_STORAGE_USER» – библиотека воспримет этот секрет как логин/пароль от хранилища, явно указывать его в конфигурационном файле не потребуется.

 

 

Либо же вы можете не использовать хранилище, а просто загрузить информационную базу из исходников. Для этого в отдельной секции по инициализации информационной базы вам нужно указать метод инициализации «fromSource».

Также поддерживается комбинированный вариант «defaultBranchFromStorage», когда основная ветка загружается из хранилища, а остальные подтягиваются из исходников.

 

Запуск BDD-сценариев

 

 

Переходим к запуску BDD-сценариев.

Обычно перед тем, чтобы хоть как-то работать интерактивно в базе, ее нужно предварительно подготовить.

Как минимум, после создания базы и наката на нее конфигурации, при первом запуске БСП от нас требует согласиться с тем, что мы легально получили обновления конфигурации, чтобы у нас запустились обработчики по миграции версии информационной базы.

jenkins-lib и используемый ею Vanessa-runner берет эту задачу на себя, если вы в конфигурационном файле включаете флаг «initSteps». В этом случае на шаге «Инициализация ИБ» библиотека понимает, что нужно запустить базу, дождаться, пока там выполнятся все обработчики, и только потом переходить к следующим шагам.

Также если в каталоге tools вашего репозитория будут лежать конфигурационные файлы запуска vanessa-runner с магическими init-именами vrunner.init.json (их может быть несколько, например, с номерами vrunner.init2.json и т.д.), то библиотека их также автоматически запустит, чтобы доинициализировать данные в вашей информационной базе. Например, создаст пользователей, контрагентов – все то, что у вас будет написано в ваших init-скриптах для vanessa-runner.

А включение флага «bdd» в конфигурационном файле запустит bdd-тестирование, используя файл tools/vrunner.json.

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

 

 

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

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

Вы создали небольшой конфигурационный файл, в котором указали, какие шаги вам нужно включать. Если что-то у вас там нестандартное – переопределили, и все.

А для тех, кто хочет узнать, как это устроено внутри, или даже захочет доработать, прислать какой-то пулл-реквест, есть следующие несколько слайдов.

 

Устройство библиотеки

 

 

Исходники библиотеки можно изучить, скачав их из репозитория https://github.com/firstBitMarksistskaya/jenkins-lib.

Основной язык, используемый при написании jenkins-lib – это groovy, довольно «сладкий» язык (в том смысле, что в нем много синтаксического сахара), который работает поверх виртуальной машины Java.

Как и большинство библиотек, которые пишутся для Jenkins по технологии shared library, jenkins-lib содержит каталог vars, в котором опубликованы скрипты, доступные для вызова из вашего Jenkisfile. В частности, здесь находится самый главный скрипт – pipeline1C.groovy, в котором и указаны все stages – все шаги, которые будут запускаться в вашей сборочной линии.

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

  • фильтр о необходимости запуска шага;

  • собственно вызов нижестоящего скрипта.

 

 

Вся сложная логика вынесена в так называемые groovy-классы. Это полноценные классы с точки зрения объектно-ориентированного программирования, где вы можете сохранять состояние, строить нормальную декомпозицию, выносить какие-то утилитные методы или целые объекты в другие места. Это уже больше похоже на Java-разработку, чем на какое-то скриптописание.

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

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

 

 

Также в этом репозитории можно найти те самые настройки по умолчанию – файл resources/globalConfiguration.json.

По структуре это такой же json-файл jobConfiguration.json, который вы кладете в корень своего проекта, только здесь описаны все-все секции. По сути, это все параметры, которые вы можете переопределить.

Какие-то шаги имеют мало параметров для переопределения, какие-то – например, syntax-check – выглядят немного объемнее.

 

Планы развития

 

 

Что можно сказать о будущем библиотеки?

Планов, как обычно, громадье – как и у всех в Open Source.

В GitHub-репозитории есть раздел Issues, где можно посмотреть задачи, которые уже стоят перед библиотекой.

Из наиболее интересных могу отметить:

  • поддержку сбора покрытия кода тестами, используя утилиту CodeCoverageFor1C;

  • запуск дымовых и Unit-тестов – сейчас их библиотека не поддерживает, но добавить их не так уж сложно (Прим. из 2022-го года: дымовые тесты уже работают!);

  • уведомления о результатах сборки на почту, в телеграм, какие-нибудь другие мессенджеры (Прим. из 2022-го года: отправка в телеграм и почту уже реализована!);

  • недавно у одного из контрибьютеров появилась идея генерировать статичный сайт с программным интерфейсом вашей конфигурации. Например, у вас есть общие модули с областью программного интерфейса, и вы их можете превратить в HTML-описание с рубрикатором как на ИТС - полная информация о том, что в этих общих модулях есть. Такое описание можно автоматом генерировать с помощью специальной обработки. Либо, если у вас есть REST-сервисы, то по ним можно сгенерировать сайт с описанием в формате OpenAPI (Swagger).

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

 

Вместо итогов

 

jenkins-lib в целом помогла решить озвученные в начале доклада проблемы.

  • Вместо сложносочиненного Jenkinsfile у нас теперь одна строчка.

  • Вместо проблем по добавлению новых блоков в этот Jenkinsfile, разработчикам теперь нужно завести один-два параметра в маленьком конфигурационном файле.

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

 

 

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

От рассмотренного ранее примера она отличается буквально тремя моментами:

  • указывается конкретная версия платформы «v8version» и имя ветки по умолчанию «defaultBranch»;

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

  • из результатов анализа EDT вырезаются не только файлы на замках, но и файлы просто с «желтым кубом» (“supportLevel”: 1) – у нас такие особенности ведения проекта.

Вроде бы ничего сложного и страшного. Приглашаю попробовать и рассказать о впечатлениях :)

 

Полезная информация

 

Обещанные полезные ссылки на репозитории и доклады.

 

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Moscow Premiere. Больше статей можно прочитать здесь.

Приглашаем всех 6-8 октября принять участие в INFOSTART EVENT 2022 в Санкт-Петербурге: //infostart.ru/events/1573038/

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

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. biimmap 493 22.06.22 11:49 Сейчас в теме
Коллега, я правильно понимаю, что статья написана для тех, кто уже пользовался jenkins, отгрёб проблем - и тут Вы помогаете в его настройке?

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

-- Sonar Qube. да его многие используют... НО! Можно ли считать, что код-ревью выполнен после него? Уверен что нет. Причём те вещи которые он показывает говорит о низком уровне кодеров. Почему не дать кодерам почитать стандарты разработки? Зачем автоматизировать теплокодерство? Самое главное для чего выполняется код-ревью - это логика кода и его быстродействие. Ни одну ни вторую задачу этот инструмент не решает. Зачем использовать не могу понять, т.к. время на его внедрение довольно немаленькое. Штрафы за ошибки работают куда эффективней. Меня лет 10 назад двумя штрафами по 5000 излечили от теплокодерства на всю жизнь!

-- Vanessa Automation. Опять же зададим вопрос: "Можно ли считать доработку протестированной по итогам тестов?". Очевидный ответ - НЕТ. Тогда какую же задачу она выполняет? Понажимать все кнопочки чтоб ничего не сломалось? Новая разработка = новый тест. Настройка одного теста не такое уж и быстрое дело. При этом консультант на эти кнопки может понажимать за 2 минуты. И опять же: почему разработчик имеет возможность отдать на тестирование доработку, в которой он не проверил работоспособность смежного функционала (имеется ввиду кнопочки в рамках дорабатываемого объекта)? Здесь опять проблема с дисциплиной! Зачем автоматизировать бардак? Чтоб был автоматизированный бардак?

Аналогичные вопросы к каждому из подключаемых инструментов.

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

3. Какие задачи должны покрываться такими масштабными проверками? Вряд ли разработку на 10 часов нужно покрывать таким количеством инструментариев?!

4. На сколько мне известно, каждый из инструментов позволяет решить задачу не далее чем наполовину. А кто решает вторую половину?

Даже если посмотреть как устроен процесс сборки типовых конфигураций, то у них есть АПК... Но код-ревью ВСЕГДА делает человек. И чаще всего не один! Т.к. один смотрим на соблюдение стандартов и логики кода, а второй смотрит на производительность, анализирует планы запросов, тестирует на большом объёме данных.

Прошу не воспринимать мой коммент как хейт или стёб! Есть реальное желание понять степень полезности инструментария и сферу его применения. По моему опыту использование этого инструментария не приводит к качественному результату. К нему приводит дисциплина в команде и нетерпимость к халатности и разгильдяйству!

Поэтому прошу ответить на вопросы по сути и желательно развернуто. Может это тема для отдельной статьи, а не для ответа в комментах.
Bessondo; Saipl; sapervodichka; +3 Ответить
2. mas_kot 25 22.06.22 12:49 Сейчас в теме
(1) Ваши вопросы уместны и логичны, но по-мойму вы сейчас скидываете в одну кучу всё: и претензии, которые имеют место быть, и просто претензии вида "не нужОн мне ваш этот интернет. Что, на мой взгляд очень странно, учитывая уровень ваших статей и, соответственно, уровень опыта.

"Зачем автоматизировать теплокодерство?" А зачем вы подменяете понятия? Сонары и АПК - это просто анализаторы кода - они проверяют текст. Если есть ошибки, опечатки, опять же невыполнение фиксированных стандартов - они это покажут. Причём ещё могут сразу виновнику торжества на мыло постучаться - "исправь это". Не Архитектор ли отвечает за качество кода отвечает? Сколько у него времени уйдёт на проверку опечаток, неканонического написания слов или на неиспользуемые процедуры? Может лучше это время потратить на более полезные вещи? Или "меня штрафанули на 5000 тысяч пару раз и всё встало на места" - ну так а кто ошибки то выискивать будет потом? Вам делать заниматься надо, а не ошибки выискивать в написании. Тем более, когда от таких штрафов половина разработчиков уволится. Код-ревью никто не отменял, но использование статистических анализаторов кода позволяет не обращать внимание проверяющему на самые "дурацкие" ошибки, а сосредоточится на логике и функционале. Тем более развернуть Сонар в файловом режиме - 2-4 часа времени для джуниор разработчика.

"Можно ли считать доработку протестированной по итогам тестов?" - вы дали правильный ответ - "нет". Ни один тест вам не скажет что у вас нет ошибок. Тест вам покажет, что в рамках заданного сценария нет ошибок. Если у вас при нажатии кнопки выскакивает ошибка деления на ноль - бейте по рукам разработчика. Но если у вас большой функционал, который ещё и до сих пор обрастает новой функциональностью - сценариев использования куча - вы либо загоните аналитика (особенно если тест подразумевает вбивание большого количества данных), либо у вас к пользователю пойдёт недопроверенный функционал и да поможет вам Бог.

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

Если у вам команда разгильдяев - дополнительная автоматизация может помочь вам избежать многих проблем связанных с вашим продуктом. Если у вас и так отличная команда - то эти вещи могут её ещё больше усилить и избежать кучи бессмысленной работы.
fatman78; mrChOP93; karpik666; user1414030; biimmap; +5 Ответить
3. biimmap 493 22.06.22 12:56 Сейчас в теме
(2) у меня есть цель: разобраться в реальной пользе этого функционала. По чесноку скажу я ничем этим не пользуюсь, и всё чаще меня в это тыкают, хотя на качестве моей работы это не сказывается. Поэтому прошу всё же ответить более конкретно на мои вопросы.

Из услышанного - SonarQube быстро разворачивается. ОК, принято к сведению!

P.S. Благодарю за оценку моих статей) скоро будет продолжение последней серии статей про ЗУП.
karpik666; +1 Ответить
5. mas_kot 25 22.06.22 13:31 Сейчас в теме
(3) Хорошо, если больше из конкретики:

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

Пример 2: у нас куча серверных тестовых баз нашего решения, завязанных на хранилища, или на конечные релизы (полностью на поддержке) для нужд аналитиков, отдела сопровождения или отдела обучения. Один человека-месяц программиста стажёра в сумме с освоениями oscripta и функциональности jenkins и вот они уже автоматически сами обновляются или перезаливаются из dt по расписанию, экономя несколько часов в неделю для нуждающихся. Это было сделано в 18-м году и до сих пор работает как надо - все знают в какой базе что проверять, какая база для чего. Вот вам из хаоса (каждый разворачивает себе базы, там такой релиз, там другой) мы получаем порядок.

Тут все истории про работу в долгую. Если вам надо быстро сделать одноразовую историю, и вас никто это сопровождать не просит - то вам это вам и не надо. А если уж у вас кто-то спрашивает за качество, а вы уверены что у вас всё отлично - скормите один раз конфигурацию сонаркубу, да покажите людям эти 38 попугаев - и люди спокойны и вы при своём остались.
mrChOP93; d.pag; +2 Ответить
6. biimmap 493 22.06.22 13:44 Сейчас в теме
(5) получается плюс Ванессы - автоматическая генерация набора данных... и потом автоматическая проверка алгоритма. ОК.
Но ведь лучший тест - это реальные данные! Я слабо верю в то, что учли все ньюансы и человеческий фактор (который только на реальных данных вылазит).

Есть какая-то возможность задавать критерии правильности алгоритма? или просто проверяет выполнился или нет?

Что касается jenkins я так понимаю это довольно не простая история в освоении? Наверно изучать такую историю нужно только на практической задаче? Верно? Или имеет смысл почитать что-то
7. mas_kot 25 22.06.22 13:56 Сейчас в теме
(6) Там была обработка, которая тест для ванессы генерировала. Ну а ваннеса - тест прогоняла.

"Но ведь лучший тест - это реальные данные!" - так генерируйте реальные данные. "Вася Петров" введённый реальным пользователем ничем не отличается от "Васи Петровым" прогоняемым тестом. Ванесса эмулирует действия пользователей - считайте вы задаёте последовательность действий от пользователя. Если вся последовательность прошла - значит всё хорошо. Не прошла (Сценарий ожидал что "Вася Петров" мальчик, а он девочкой оказался"), тест упал попутно сделав скриншот и сохранив описание ошибки. Что потом с этой ошибкой делать уже решаете вы - либо признаёте это ошибкой конфигурации, либо ошибкой данных.

"Правильный алгоритм" - это тот который у вас по процессу и должен быть. В идеале он должен писаться ещё до того, как вообще разработка начнётся. И разработчик должен опираться на этот "правильный алгоритм". И чем больше вариантов работы он изначально покрывает - тем лучше.
8. biimmap 493 22.06.22 14:09 Сейчас в теме
(7) Вот с тем что сценарии работы нужно продумывать до разработки - очень правильная мысль! Я в несколько статей своих такую мысль вставлял, и при случае буду ещё вставлять)
4. user1414030 22.06.22 13:21 Сейчас в теме
(1) Из личного опыта могу ответить на первый пункт. SonarQube - Вы действительно помните все стандарты наизусть и сами проверяете каждую строчку кода на полное им соответствие? Просто я их читаю, но помню основные. SonarQube дает отличный контроль соблюдения этих стандартов. Должен ли разработчик знать эти стандарты - да, должен. Нужно ли их постоянно держать в голове? Сомневаюсь. Время на внедрение SonarQube на самом деле небольшое. Время анализа зависит уже от размеров проекта. Первый раз настройка у меня заняла много времени, последующие, когда уже было понимание что и как, занимала около часа. Подключение нового проекта (без запуска анализа) при уже настроеном SonarQube - минуты две.
9. nixel 1255 22.06.22 18:18 Сейчас в теме
(1) выше уже есть несколько ответов на ваши вопросы, но попробую накидать дополнительной информации.

> Можно ли считать, что код-ревью выполнен после него?

Нет, можно считать, что код частично проанализирован на соответствие стандартам разработки, и если SQ показывает зеленый результат и 0 new code smells/bugs, то можно переходить к реальному код-ревью с проверкой логики и архитектуры вместо "Васян, ну еклмн, опять запросы в цикле и проверки на обмен данными нет. Иди переделывай быстро!".

> Почему не дать кодерам почитать стандарты разработки?

Читают. Толку-то. :)

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

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

Безусловно. Для этого требуется сценарное/модульное тестирование и нагрузочное тестирование. Это инструменты другого класса.

> т.к. время на его внедрение довольно немаленькое.

Недавно опубликовали скрипт моего мастер-класса по развочиванию сонара+гитсинка за полтора часа с разбором сценариев использования и типичных проблем. Рекомендую ознакомиться. https://infostart.ru/1c/articles/1661973/

---

> "Можно ли считать доработку протестированной по итогам тестов?"

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

> Тогда какую же задачу она выполняет? Понажимать все кнопочки чтоб ничего не сломалось?

Нет, проверить, что при выполнении определенного сценария работы в системе (не важно, в пользовательском режиме, или каким-то алгоритмом), система выдает ожидаемый разработчиком/тестировщиком ответ.

> Настройка одного теста не такое уж и быстрое дело.

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

> При этом консультант на эти кнопки может понажимать за 2 минуты.

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

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

Если речь про тесты - любой. Если речь про SQ - для ошибок - любой. Для код смеллов - если вы собираетесь его сопровождать в дальнейшем.

> Какие задачи должны покрываться такими масштабными проверками? Вряд ли разработку на 10 часов нужно покрывать таким количеством инструментариев?!

А какая разница, если это все делается автоматизированно и скриптами? Ткнули кнопку и поехало само, останется только результат посмотреть.

> На сколько мне известно, каждый из инструментов позволяет решить задачу не далее чем наполовину

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

> Даже если посмотреть как устроен процесс сборки типовых конфигураций, то у них есть АПК... Но код-ревью ВСЕГДА делает человек. И чаще всего не один! Т.к. один смотрим на соблюдение стандартов и логики кода, а второй смотрит на производительность, анализирует планы запросов, тестирует на большом объёме данных.

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

Рекомендую еще ознакомиться с моими выступлениями на эвентах прошлых лет:
* https://infostart.ru/1c/articles/622617/ - Управление техническим долгом - Концепция Continuous Inspection
* https://infostart.ru/1c/articles/1086369/ - Тестирование интеграций между системами
* https://infostart.ru/1c/articles/1182048/ - Атака сервера кнопонажималкой
fatman78; mrChOP93; biimmap; salexdv; user896890; pavlov_dv; +6 Ответить
10. Dach 347 23.06.22 10:09 Сейчас в теме
(0) Никита, в какой функции есть код интеграции с телегой?

"Рассылка результатов сборки на почту и в Telegram."

И какой плагин в J надо воткнуть для этого и как работает - надо бота создать или канал?

И еще, есть ли примеры параллельного выполнения шагов и где смотреть, в какой процедуре/функции?
11. nixel 1255 23.06.22 10:13 Сейчас в теме
(10)

> в какой функции есть код интеграции с телегой?

это не функция, это класс.
https://github.com/firstBitMarksistskaya/jenkins-lib/blob/develop/src/ru/pulsar/jenkins/library/steps/Telegra­mNotification.groovy

Вызывается из общей функции sendNotifications

> И какой плагин в J надо воткнуть для этого

HTTP Requests

> как работает - надо бота создать или канал?

Бота, через bot_father. Его токен авторизации в секреты. В своем чате/канале узнать id комнаты (тоже какой-то бот был для этого) и тоже прописать его в секреты (в ридми есть название секретов).

> И еще, есть ли примеры параллельного выполнения шагов и где смотреть, в какой процедуре/функции?

Весь маршрут сборочной линии описан в главной функции pipeline1c:

https://github.com/firstBitMarksistskaya/jenkins-lib/blob/develop/vars/pipeline1C.groovy
12. ImHunter 241 23.06.22 19:51 Сейчас в теме
А можно ли сделать multibranch из нескольких pipeline1c() ? Это про обновление основной конфигурации и расширений.
13. nixel 1255 23.06.22 20:08 Сейчас в теме
(12) не совсем понимаю вопрос.
14. ImHunter 241 23.06.22 20:40 Сейчас в теме
(13) Не, multibranch тут не стоит городить. Ну тогда про последовательное выполнение. Типа так:
node() {
    stage("Обновляем основную конфигурацию"){
        pipeline1c()
    }
    stage("Обновляем расширение 1"){
        pipeline1c()
    }
    stage("Обновляем расширение 2"){
        pipeline1c()
    }
}
Показать
15. nixel 1255 23.06.22 22:21 Сейчас в теме
(14) все еще не понимаю вопрос. pipeline1c делает много больше, чем просто обновление иб. и да, вы там можете задать шаги по обновлению расширений, через init-секцию конфигурационного файла.
16. ImHunter 241 24.06.22 07:50 Сейчас в теме
(15) Обновлять расширения через init-секцию? Это initInfobase.additionalInitializationSteps ? Но ведь нужно будет прописывать где-то дополнительно, например, данные о хранилищах расширений.

Похоже, что я это к тому, что нужен опциональный параметр, чтобы можно было вызвать Pipeline1C(string fileName = null) с другими настройками. Где fileName - это другой конфигурационный файл jobConfigurationXXX.json.
И тогда при наличии расширений мы сможем их отдельно обновить и проанализировать (например, натравить на их исходники SQ) или, наоборот, не захотим анализировать.
Тогда pipeline будет состоять из нескольких вызовов Pipeline1C(). Каждый из вызовов отработает свою конфигурацию - обновит какую-то базу, запустит или не запустит тесты, сделает или пропустит анализ исходников.
17. nixel 1255 24.06.22 07:55 Сейчас в теме
(16)

> Но ведь нужно будет прописывать где-то дополнительно, например, данные о хранилищах расширений

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

> что нужен опциональный параметр, чтобы можно было вызвать Pipeline1C(string fileName = null)

Он уже есть.

> например, натравить на их исходники SQ

Это решается конфигурацией sonar-project.properties

> Тогда pipeline будет состоять из нескольких вызовов Pipeline1C()

А вот так не получится. Эта функция сама по себе возвращает pipeline, её нельзя вызвать несколько раз в рамках одной сборочной линии
18. nixel 1255 24.06.22 07:58 Сейчас в теме
(16)

> Каждый из вызовов отработает свою конфигурацию - обновит какую-то базу, запустит или не запустит тесты, сделает или пропустит анализ исходников.

Ну... Кажется, нужно просто сделать несколько сборочных линий, разве нет? Каждой конфигурации по своему проекту на гит-сервере и сервере сборок, у каждого свой jobConfiguration.json
19. ImHunter 241 24.06.22 08:01 Сейчас в теме
(18) Да, видимо, так... Но при этом кол-во линий сборки может значительно увеличиться:( Плюс добавится сборка верхнего уровня, которая будет в нужной последовательности собирать компоненты инфобазы.
20. ImHunter 241 24.06.22 08:09 Сейчас в теме
(18) Но в любом случае. Мега-полезная библиотека! Буду таки на нее мигрировать со своей самописки.
Оставьте свое сообщение

См. также

APDEX 1C + Prometheus + Grafana + Superset, а точнее наоборот

DevOps и автоматизация разработки v8 Россия Бесплатно (free)

Вы не задумывались о том, что расчет APDEX должен быть онлайн? Онлайн для всех - от бизнес-пользователей до команды разработки. Если задумывались - то в статье мы расскажем, зачем это делать, и поделимся наработками, как подключить 1С+APDEX к такой штуке, как Prometeus.

16.02.2022    4866    digital-samolet    42    

Как начать разработку проекта 1С, чтобы легко перейти к DevOps-практикам

DevOps и автоматизация разработки v8 1cv8.cf Бесплатно (free)

Многие рутинные операции при работе над проектом 1С можно автоматизировать – довериться готовым инструментам и уменьшить количество нажимаемых кнопок. О том, как с помощью готового шаблона проекта настроить окружение для разработки на митапе «DevOps в 1С» рассказал технический директор Инфостарта Артур Аюханов.

22.06.2021    6542    artbear    2    

Docker для 1Сника

DevOps и автоматизация разработки v8 Бесплатно (free)

На онлайн митапе «DevOps в 1С» Руслан Жданов рассказал, для чего 1С-нику нужен Docker, как его применять, какие сервисы можно вынести в контейнеры и как организовать взаимодействие контейнеров друг с другом.

07.06.2021    7940    ZhdanovR    33    

Осторожный DevOps

DevOps и автоматизация разработки v8 Бесплатно (free)

Начальник отдела разработки в компании «Билайн» Игорь Сухоруков на Meetup Infostart DevOps поделился особенностями работы своего ИТ-подразделения и рассказал о том, как устроено производство и внедрение ПО в режиме нон-стоп в компании, подразделения которой работают по всей России: от Москвы до Владивостока.

24.05.2021    3205    ig1082    3    

Шпаргалка установки сервера взаимодействия без MSI(9.0.33) использованием Postgresql в docker-compose

DevOps и автоматизация разработки v8 Бесплатно (free)

Какой бы не был бизнес - он нуждается в коммуникации. У кого-то Telegram, у других - Whatsapp, у кого то - электронные письма. Возникла задача наладить общение между пользователями базы 1С без мессенджеров. Скачав самую свежую версию на момент написания статьи 9.0.33, обнаружились некоторые подводные камни при установке.

07.04.2021    2174    yaroslavkravets    1    

Управление конфигуратором в режиме агента с помощью python

Инструменты администратора БД Архивирование (backup) DevOps и автоматизация разработки v8 1cv8.cf 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

Управление конфигуратором 1С:Предприятие в режиме агента. Опыт применения с реализацией на языке python. Результат получен с использованием интерактивной сессии оболочки через invoke_shell().

06.08.2020    2469    Alex10166    2    

Jenkins: конфигурируем сервер и подключаем к нему виртуальные машины. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 4

DevOps и автоматизация разработки v8 Бесплатно (free)

Выполним основные настройки Jenkins как CI-сервера. Подключим к нему развёрнутые через Vagrant виртуальные машины в качестве сборочных узлов.

13.03.2020    24265    Vladimir Litvinenko    8    

DevOps. Как это выглядит у нас

DevOps и автоматизация разработки v8 1cv8.cf Россия Бесплатно (free)

DevOps в департаменте разработки 1С в крупной компании.

01.10.2019    12783    Repich    19    

Конвейер проверки качества кода

Инструментарий разработчика v8 1cv8.cf Абонемент ($m)

Jenkinsfile для выполнения проверки качества кода. Собирает информацию с АПК, EDT и BSL-LS. Сопоставляет ошибки с гит-репозиторием, выгруженным ГитКонвертором. Отправляет в Сонар.

3 стартмани

04.09.2019    43900    31    Stepa86    46    

Сказ про то, как я DevOps-ом занимался (OneScript, Deployka, Jenkins)

OneScript DevOps и автоматизация разработки v8 1cv8.cf ИТ-компания Бесплатно (free)

Решаем задачу: автоматизировать обновление тестовых баз 1С из хранилища конфигурации при появлении в нём новых изменений. Данная статья родилась в муках хождения по граблям и поиска безопасного форватора среди подводных камней. Изложение постарался представить в виде инструкции для новичка, в которой собрал всё, с чем пришлось столкнуться. Сам я не DevOps-ер, ни на что не претендую, просто делюсь опытом :)

17.06.2018    26547    stas_ganiev    37    

Автоматизация процесса 1С-разработки

DevOps и автоматизация разработки v8 Бесплатно (free)

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

07.06.2017    28051    ekaruk    9    

Автоматическая интеграция внешних обработок в конфигурацию 1C

DevOps и автоматизация разработки v8 1cv8.cf Бесплатно (free)

Вот уже некоторое время мы ведем разработку через git-flow. Все очень нравится. Но есть один момент - когда выходит релиз и ветка develop мигрирует в ветку master, очень лень подключать новые внешние обработки к базе вручную. Вот поэтому я решил немного подковырять Jenkins для небольшой автоматизации процесса.

06.11.2014    12828    akomar    1