Быстро в Jenkins

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) – у нас такие особенности ведения проекта.

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

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

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

jenkins-lib – https://github.com/firstBitMarksistskaya/jenkins-lib
onec-docker – https://github.com/firstBitMarksistskaya/onec-docker
Валерий Максимов «CI/CD для 1С проектов, унифицировано, с кастомизацией» – //infostart.ru/1c/articles/1198146/
Антон Степанов «Конвейер проверки качества кода» – //infostart.ru/public/1117485/
Никита Федькин «1С on demand – скажи "нет" постоянным билд-агентам» – //infostart.ru/1c/articles/1368078/

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

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

+95 –

См. также

Онлайн-интенсив "DevOps для 1С". с 4 октября по 19 ноября 2024 г.

DevOps для 1С DevOps и автоматизация разработки Программист Стажер Платные (руб)

Данный онлайн-курс (интенсив) предусматривает изучение процессов, инструментов и методик DevOps, их применение при разработке на платформе 1С.

2500 руб.

20.06.2023 22264 2 4

310

SALE! 50%

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

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

Использования систем контроля версий — стандарт современной разработки. На курсе научимся использованию Хранилища 1С и GIT при разработке на 1С:Предприятие 8. Разберем подходы и приемы коллективной разработки, научимся самостоятельно настраивать системы и ориентироваться в них.

~~4900~~ 2450 руб.

29.06.2022 11931 99 4

131

Автотесты для типовых конфигураций 1С:ЗУП КОРП 3 и ЗУП 3 (vanessa automation)

DevOps и автоматизация разработки Тестирование QA Программист Пользователь Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Зарплата и Управление Персоналом 3 и версии КОРП: 3.1.30.57.

2160 руб.

05.08.2024 1277 12 1

Управление сборкой интеграция с GitLab по API для конфигурации СППР

DevOps и автоматизация разработки Логистика, склад и ТМЦ Системный администратор Программист Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 1С:Франчайзи, автоматизация бизнеса Платные (руб)

Подсистема «Управление сборкой GLI» предназначена для динамического формирования сборочных линий Gitlab и отслеживания процесса доработок систем на базе1С:Предприятия Позволяет упростить выпуск новых релизов системы, подготовить описание доработок системы. Интегрируется с GitLab API по событиям Push, Merge-request, Pipeline. Уведомляет пользователей о результатах сборки/тестирования сборочных конвейеров через СВ, либо при её недоступности или отсутствию по E-Mail. Поможет при отправке исправлений ошибок в общую базу тестирования, сформирует запросы на слияние в ветку версии только по протестированному и подтверждённому функционалу. Подсистема рассчитана исключительно на клиент - серверную архитектуру тестовых ИБ. Поддерживаемая версии СППР 2.0.4.15, платформа не ниже 8.3.17.1549, 2.0.7.3 / не ниже 8.3.21.1664, начиная с релиза 1.0.4.30 требуется платформа не ниже 8.3.23 рекомендуемый релиз 8.3.23.1997

7000 руб.

26.08.2022 12553 10 10

Автотесты для типовых конфигураций ERP 2 и КА 2 (для vanessa automation)

Тестирование QA DevOps и автоматизация разработки Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.17.113.

2400 руб.

04.07.2022 8367 38 1

Автотесты для типовых БП КОРП 3.0 и БП 3.0 (vanessa automation)

Тестирование QA DevOps и автоматизация разработки Программист Пользователь Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.156.30.

1800 руб.

20.01.2022 7783 19 0

Сервер 1С в контейнерах или другое направление DevOps

DevOps и автоматизация разработки Программист Платформа 1С v8.3 Бесплатно (free)

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

18.09.2024 1721 antonov_av 6

Сказ о создании информационной базы для разработки и тестирования

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

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

28.08.2024 6584 yuraid 28

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. biimmap 2019 22.06.22 11:49 Сейчас в теме

Коллега, я правильно понимаю, что статья написана для тех, кто уже пользовался jenkins, отгрёб проблем - и тут Вы помогаете в его настройке?

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

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

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

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

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

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

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

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

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

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

Ответить

2. mas_kot 77 22.06.22 12:49 Сейчас в теме

(1) Ваши вопросы уместны и логичны, но по-мойму вы сейчас скидываете в одну кучу всё: и претензии, которые имеют место быть, и просто претензии вида "не нужОн мне ваш этот интернет. Что, на мой взгляд очень странно, учитывая уровень ваших статей и, соответственно, уровень опыта.

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

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

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

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

Ответить

3. biimmap 2019 22.06.22 12:56 Сейчас в теме

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

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

P.S. Благодарю за оценку моих статей) скоро будет продолжение последней серии статей про ЗУП.

5. mas_kot 77 22.06.22 13:31 Сейчас в теме

(3) Хорошо, если больше из конкретики:

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

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

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

6. biimmap 2019 22.06.22 13:44 Сейчас в теме

(5) получается плюс Ванессы - автоматическая генерация набора данных... и потом автоматическая проверка алгоритма. ОК.
Но ведь лучший тест - это реальные данные! Я слабо верю в то, что учли все ньюансы и человеческий фактор (который только на реальных данных вылазит).

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

Что касается jenkins я так понимаю это довольно не простая история в освоении? Наверно изучать такую историю нужно только на практической задаче? Верно? Или имеет смысл почитать что-то

7. mas_kot 77 22.06.22 13:56 Сейчас в теме

(6) Там была обработка, которая тест для ванессы генерировала. Ну а ваннеса - тест прогоняла.

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

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

8. biimmap 2019 22.06.22 14:09 Сейчас в теме

(7) Вот с тем что сценарии работы нужно продумывать до разработки - очень правильная мысль! Я в несколько статей своих такую мысль вставлял, и при случае буду ещё вставлять)

4. user1414030 22.06.22 13:21 Сейчас в теме

(1) Из личного опыта могу ответить на первый пункт. SonarQube - Вы действительно помните все стандарты наизусть и сами проверяете каждую строчку кода на полное им соответствие? Просто я их читаю, но помню основные. SonarQube дает отличный контроль соблюдения этих стандартов. Должен ли разработчик знать эти стандарты - да, должен. Нужно ли их постоянно держать в голове? Сомневаюсь. Время на внедрение SonarQube на самом деле небольшое. Время анализа зависит уже от размеров проекта. Первый раз настройка у меня заняла много времени, последующие, когда уже было понимание что и как, занимала около часа. Подключение нового проекта (без запуска анализа) при уже настроеном SonarQube - минуты две.

9. nixel 1433 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/ - Атака сервера кнопонажималкой

Ответить

10. Dach 382 23.06.22 10:09 Сейчас в теме

(0) Никита, в какой функции есть код интеграции с телегой?

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

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

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

11. nixel 1433 23.06.22 10:13 Сейчас в теме

(10)

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

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

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

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

HTTP Requests

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

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

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

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

https://github.com/firstBitMarksistskaya/jenkins-lib/blob/develop/vars/pipeline1C.groovy

12. ImHunter 327 23.06.22 19:51 Сейчас в теме

А можно ли сделать multibranch из нескольких pipeline1c() ? Это про обновление основной конфигурации и расширений.

13. nixel 1433 23.06.22 20:08 Сейчас в теме

(12) не совсем понимаю вопрос.

14. ImHunter 327 23.06.22 20:40 Сейчас в теме

(13) Не, multibranch тут не стоит городить. Ну тогда про последовательное выполнение. Типа так:

node() {
    stage("Обновляем основную конфигурацию"){
        pipeline1c()
    }
    stage("Обновляем расширение 1"){
        pipeline1c()
    }
    stage("Обновляем расширение 2"){
        pipeline1c()
    }
}

Показать

15. nixel 1433 23.06.22 22:21 Сейчас в теме

(14) все еще не понимаю вопрос. pipeline1c делает много больше, чем просто обновление иб. и да, вы там можете задать шаги по обновлению расширений, через init-секцию конфигурационного файла.

16. ImHunter 327 24.06.22 07:50 Сейчас в теме

(15) Обновлять расширения через init-секцию? Это initInfobase.additionalInitializationSteps ? Но ведь нужно будет прописывать где-то дополнительно, например, данные о хранилищах расширений.

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

17. nixel 1433 24.06.22 07:55 Сейчас в теме

(16)

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

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

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

Он уже есть.

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

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

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

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

18. nixel 1433 24.06.22 07:58 Сейчас в теме

(16)

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

Ну... Кажется, нужно просто сделать несколько сборочных линий, разве нет? Каждой конфигурации по своему проекту на гит-сервере и сервере сборок, у каждого свой jobConfiguration.json

19. ImHunter 327 24.06.22 08:01 Сейчас в теме

(18) Да, видимо, так... Но при этом кол-во линий сборки может значительно увеличиться:( Плюс добавится сборка верхнего уровня, которая будет в нужной последовательности собирать компоненты инфобазы.

20. ImHunter 327 24.06.22 08:09 Сейчас в теме

(18) Но в любом случае. Мега-полезная библиотека! Буду таки на нее мигрировать со своей самописки.

21. sparhh 30.06.22 17:12 Сейчас в теме

Спасибо за инструмент!

По расширениям:
Можете здесь как пример написать кусок скрипта для jobConfiguration.json, чтобы в момент инициализации базы к нему цеплялось расширение?

Это было бы очень полезно.

22. nixel 1433 30.06.22 18:54 Сейчас в теме

(21) что-то в духе:

{
  "stages": {
    "initSteps": true
  },
  "initInfobase": {
    "additionalInitializationSteps": [
      "compileexttocfe  --src ./cfe/myCfe --out myCfe.cfe",
      "run --command "$workspaceRoot/myCfe.cfe,build/loadExt.log" --execute $runnerRoot\epf\ЗагрузитьРасширение.epf"
    ]
  }
}

Показать

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

50. fddi 02.02.24 13:18 Сейчас в теме

(22)
Тоже долго бодался с этим шагом - на всякий случай оставлю здесь работающий пример для таких же страждущих как и я в свое время (пути, само собой, можно переменной заменить)

   "initInfobase": {
        "initMethod": "fromSource",
        "additionalInitializationSteps": [
            "compileexttocfe -s ./src/cfe/Дополнения -o c:/jenkins/workspace/Дополнения.cfe",
            "compileexttocfe -s ./src/cfe/Интеграции -o c:/jenkins/workspace/Интеграции.cfe",
            "run --command \"Путь=c:/jenkins/workspace/Дополнения.cfe\" --execute \"c:/Program Files/OneScript/lib/vanessa-runner/epf/ЗагрузитьРасширениеВРежимеПредприятия.epf\"",
            "run --command \"Путь=c:/jenkins/workspace/Интеграции.cfe\" --execute \"c:/Program Files/OneScript/lib/vanessa-runner/epf/ЗагрузитьРасширениеВРежимеПредприятия.epf\""
        ]
    },

Показать

51. nixel 1433 02.02.24 16:42 Сейчас в теме

(50)
1) почему отказались от использования относительных путей?
2) что не так с $runnerRoot?

52. fddi 04.02.24 17:06 Сейчас в теме

(51)
Все так и с $runnerRoot и с относительными путями. Просто когда без особого опыта только-только погружаешься в специфику данного процесса, то и на "воду дуешь" - т.е. чтобы получить "зеленую сборку" готов прибить пути гвоздями :) А вот когда оно заработало - можно уже начинать играться и с относительными и с переменными. Соотвественно, комментарий выше был ровно для таких же как я перестраховщиков которые мало понимают что делают, но хотели бы получить положительный результат. Ибо гугл про CI/CD в 1С только на Инфостат ссылки и выдает в общем-то...

53. nixel 1433 04.02.24 17:14 Сейчас в теме

(52) рад, что у вас все получилось!

23. eufes 02.08.22 23:36 Сейчас в теме

Доброго дня. Подскажите, пожалуйста (пытаюсь освоить темы, но никак не соображу), а где указывается путь к хранилищу проекта?
В конфигурационном файле вроде как секреты по ним как-то определяется путь? (с гитом и дженкинсом пока не очень много опыта).
И еще вопросик: если я хочу проводить BDD на базе в которую хочу загрузить готовый dt, то это отдельные шаги надо дописывать файлы groovy наподобие того как указано в (22) ?

24. nixel 1433 03.08.22 00:03 Сейчас в теме

(23)

а где указывается путь к хранилищу проекта?

в credentials в jenkins. создаете новый credential, задаете ему идентификатор согласно соглашению об именовании секретов, jenkins-lib сам его подхватит. Либо прописываете идентификатор созданного credential в секции secrets (STORAGE_PATH)

(23)

И еще вопросик: если я хочу проводить BDD на базе в которую хочу загрузить готовый dt, то это отдельные шаги надо дописывать файлы groovy наподобие того как указано в (22) ?

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

25. Olenevod 33 11.08.22 10:12 Сейчас в теме

Позволю себе небольшой пост нытья)

Все же нужно много дополнительных знаний, как выходит :)
Вроде бы кое как разобрался с Java, поставил Jenkins, настроил перечитав статьи (и смежные штуковины).
Делаю запуск задания. Ошибки. Вижу лог.
Но вот как понять, что ему не нравиться, почему и, самое главное, что делать? Есть ли что-то, что может помочь в этом?)
Тут даже в интернете информации не очень много. А ведь наверняка еще будут подобные.
Получается, что нужны какие-то дополнительные навыки "разбирательства в логах".

Не призываю помочь мне, но для примера (может есть секрет(ы)), что должен (или как) сделать человек, чтобы разбираться вот с такими проблемами:
Значит получил такой лог (кусок):

org.jenkinsci.plugins.workflow.cps.CpsCompilationErrorsException: startup failed:
file:/C:/ProgramData/Jenkins/.jenkins/jobs/Empty/builds/10/libs/36ad4020d4be0b69592042ff4a0c5978a0a1cf8ab87c2bf2597bb308fe6b6ee9/src/ru/pulsar/jenkins/library/IStepExecutor.groovy: 3: unable to resolve class jenkins.plugins.http_request.HttpMode
 @ line 3, column 1.
   import jenkins.plugins.http_request.HttpMode

Такое же и с
org.jenkinsci.plugins.pipeline.utility.steps.fs.FileWrapper
jenkins.plugins.http_request.ResponseContentSupplier
jenkins.plugins.http_request.MimeType

При этом на остальные он не ругнулся:
import org.jenkinsci.plugins.workflow.support.actions.EnvironmentAction
import org.jenkinsci.plugins.workflow.support.steps.build.RunWrapper

По ошибке в интернете удалось найти что-то более менее внятное:
https://stackoverflow.com/questions/45072923/groovy-unable-to-resolve-class
Но как это "пожарить" не хватает знаний)

Одна из моих конвульсивных попыток
На ум пришло, что за плагин такой http_request. Решил поставить вручную, но эффекта 0.

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

27. nixel 1433 27.08.22 15:40 Сейчас в теме

(25) есть задачка на описание списка обязательных плагинов, в ней перечислена часть. Но прям в ридми такого списка так и нет :(

26. ImHunter 327 27.08.22 15:18 Сейчас в теме

(25) Ага, "нытье" не без оснований.
Тоже напоролся на отсутствие плагинов Allure Jenkins Plugin, Pipeline Utility Steps.

28. ImHunter 327 05.09.22 17:36 Сейчас в теме

(1) А почему pipeline1C в декларативном стиле?

29. nixel 1433 05.09.22 18:15 Сейчас в теме

(28) 1. Мне он больше нравится. 2. Scripted pipiline не развивается. 3. Blue ocean

30. fetch19 22.09.22 11:20 Сейчас в теме

Подскажите как найти раздел Global Pipeline Libraries ? у меня его в настройках http://localhost:8080/manage/configure просто нет
да и по остальным настройкам нет
jenkins версия 2.361.1 устанавливал сам права полные
или этот функционал добавляется каким и то плагинами?

32. nixel 1433 21.11.22 16:16 Сейчас в теме

(30) да, нужен плагин. Pipeline: groovy libraries.

31. ad_hoc 21.11.22 15:48 Сейчас в теме

Эта библиотека просто находка! Автору огромный респект за работу, очень профессионально! Статья написана так, что нужно все же разобраться во многих деталях прежде чем сможешь все настроить, но если читать логи, думать и чуть-чуть гуглить то все получится, так намного полезнее чем просто следование инструкции. Разобрался за несколько дней и подключил конфигурацию c gitlab-а в формате edt на синтаксический контроль, остается только масштабироваться и внедрять)
Кто-нибудь уже успел собрать рабочий jobConfiguration для подключения расширений?

33. nixel 1433 21.11.22 16:18 Сейчас в теме

(31)

jobConfiguration

Кажется, кроме (22) пока больше никто ничего в публичке не писал :)

Надеюсь, доберусь до этой темы вскоре, есть потребность.

34. magic1s 12 28.11.22 03:29 Сейчас в теме

Прочитал 1/4. Ничего не понял.
Для кого статья?

Подпись: программист 1С.

35. magic1s 12 28.11.22 03:30 Сейчас в теме

Может сделаете пару вводных абзацев про то, что это такое и кому нужно?

36. nixel 1433 28.11.22 07:51 Сейчас в теме

(35) это библиотека для дженкинса, упрощающая построение сборочной линии - не нужно думать о том как написать и реализовать процесс сборки, лишь провести ряд настроек.
Ну и да, читать стоит до конца :)

37. ad_hoc 29.11.22 12:27 Сейчас в теме

А есть ли возможность запустить проверку sonar на CommunityEdition версии? Там ведь ограничение работы насколько мне известно только с master веткой. Пробую запустить проверку у себя но даже на master ветке получаю "To use the property "sonar.branch.name" and analyze branches, Developer Edition or above is required". Это связано с тем что в jenkins используется Multibranch Pipeline?

38. nixel 1433 29.11.22 12:30 Сейчас в теме

(37) либо поставить бесплатный плагин, добавляющий поддержку бранчей в ce-версию сонара, либо переключить настройку использования конфигурации бранч плагина в auto в jobConfiguration.json

39. alexey_kurdyukov 165 08.12.22 10:02 Сейчас в теме

Для того, чтобы собрать конфигурацию 1С, её нужно сначала разобрать, в отличии от большинства других систем. Так почему же вы не пишете, что у вас "конвейер РАЗБОРКИ"? Ведь для приложения, например, на C++/WinAPI сборка - это естественная часть процесса, а для 1С - противоестественная.

40. nixel 1433 08.12.22 10:07 Сейчас в теме

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

41. alexey_kurdyukov 165 08.12.22 10:12 Сейчас в теме

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

42. nixel 1433 08.12.22 10:16 Сейчас в теме

(41)
> про то, что можно материал для сборки получить каким-то ещё способом?

Можно из хранилища, из файла, из базы, из исходников в формате едт, из исходников в формате конфигуратора.

> почему код не тестируется и не ревьюится в том месте, где он разрабатывался до помещения его в хранилище?

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

43. ad_hoc 27.02.23 17:40 Сейчас в теме

Пытаюсь безуспешно запустить выполнение bdd тестов на линии сборки, может кто-то может подсказать куда копать?
Всякий раз зависает на шаге в логах:
ИНФОРМАЦИЯ - Тестирую поведение с помощью фреймворка Vanessa-ADD (Vanessa Automation Driven Development)
ИНФОРМАЦИЯ - Выполняю команду/действие в режиме 1С:Предприятие
При выполнении из командной строки все отрабатывает быстро и без ошибок при выполнении из jenkins висит.

44. nixel 1433 27.02.23 18:17 Сейчас в теме

(43) как запущен дженкинс агент? Какая ось?

45. ad_hoc 27.02.23 18:59 Сейчас в теме

(44) Windows Server 2019 Datacenter, jenkins запущен в самом простом варианте, все на оной машине и сам jenkins и агент. Перед шагом bdd у меня еще идет initsteps который тоже отрабатывает без проблем.

46. nixel 1433 27.02.23 19:15 Сейчас в теме

(45) в init steps нет взаимодействия с тест клиентом
1с не хватает возможностей графического окружения для полноценной работы. Запускайте дженкинс батником, либо делайте отдельный агент (тоже батником), либо играйтесь с powershell, либо переходите на линукс/докер и поднимайте полноценное окружение

47. ad_hoc 27.02.23 19:22 Сейчас в теме

(46) Но почему тогда на том же сервере, под тем же пользователем командой через cmd все выполняется отлично?

48. nixel 1433 27.02.23 19:23 Сейчас в теме

(47) потому что cmd запущен в графическом окружении

49. ad_hoc 01.03.23 16:56 Сейчас в теме

(48) Оказалось, что графического окружения хватает. Как я до этого дошел долгая история, но по итогу все заработало, после того как создал новый vrunner.bat копированием и назвал его vrunner1.bat ну и поправил его имя в VRunner.groovy. Будем разбираться с сами сервером. Отдельное спасибо Никита за быстрые ответы! Библиотека бомба!

Оставьте свое сообщение

E-mail:

Автор:

Никита Федькин (nixel)

Рейтинг: 1433

Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот

Публикация:

№ 1681427

Создание 21.06.22 20:52

Обновление 21.06.22 20:52

Статистика:

Просмотры 14800

Загрузки 0

Рейтинг 95

Комментарии 53

Характеристики:

Код открыт Да

Рубрики DevOps и автоматизация разработки

Кому Системный администратор ,
Программист

Тип файла Нет файла

Платформа Платформа 1С v8.3

Конфигурация Конфигурации 1cv8

Операционная система Не имеет значения

Страна Не имеет значения

Отрасль Не имеет значения

Налоги Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)