Правила написания pipelines и шагов#

Главное понимать, что результаты/логи работы job читает не только разработчик pipeline, но и пользователь и администратор. Код должен быть человекочитаемым и переиспользуемым. Для этого необходимо соблюдать ряд правил.

Логирование. Ключевые моменты должны быть выделены цветом. Подробнее можно прочитать в разделе «События системного журнала» документа «Руководство по системному администрированию».

Валидация. Обязательные параметры должны быть провалидированы в рамках шага Validation.groovy (описанного в подразделе «Шаги» раздела «Дополнительная документация» текущего документа). В случае их отсутствии pipeline должен прекращать выполнение после выполнения шага Validation.groovy, а не когда дойдет до использующего этот параметр шага. Ниже будет описан процесс валидации параметров.

Полезные методы, которые потенциально могут быть переиспользованы (к примеру, работа с JIRA, архивация, публикация дистрибутивов) выносятся в отдельную библиотеку и размещаются в src/ru/sbrf/devops/, и именуется в соответствии с назначением. К примеру, JiraRequester.groovy. Перед тем, как реализовывать собственный метод, рекомендуем прочитать документацию по библиотекам, описанным в подразделе «Библиотеки методов» раздела «Дополнительная документация» текущего документа (JiraRequester.groovy, DevCommon.groovy, ConfluenceRequester.groovy,ExecutorUtils.groovy, Helper.groovy,Nexus.groovy), так как в этой документации вы найдете информацию о типовых методах, реализованных командой разработки SMDL. Это позволит реализовывать собственные шаги и pipelines, использую существующие наработки и практики.

Jenkins имеет собственные плагины и библиотеки, которые позволяют упрощать разработку pipelines. Доступные инструменты можно посмотреть меню „Pipeline Syntax“ Jenkins Job. Также в разделе tools меню „Pipeline Syntax“ можно посмотреть доступные SDK.

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

Обратите внимание, что в Groovy можно объявлять параметры без типа — def. Также можно объявлять переменную без def, что сделает ее глобальной. Использование глобальных переменных может приводить к ошибкам и усложнению диагностики, при совпадении имен переменных.

При разработке собственных шагов, если разработчик считает что есть действия, которые можно выполнять параллельно, то разработчику, при реализации шагов, рекомендуется использовать декларативную возможность многопоточности Jenkins — parallel (https://www.jenkins.io/doc/book/pipeline/syntax/#parallel).