«Pipeline-as-code» — принцип, который позволяет Jenkins обрабатывать пайплайны как обычные файлы. Существует два способа описания пайплайнов: скриптовый и декларативный. В этой статье поговорим о Jenkins Scripted Pipeline: проанализируем его структуру и разберём варианты использования. 

Что такое Scripted Pipeline в Jenkins

Jenkins Scripted Pipeline — первая версия принципа «Pipeline-as-code». Она представляет собой Groovy-скрипт с использованием Jenkins Pipeline DSL и обеспечивает выдающийся уровень мощности и гибкости. 

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

Шаги для скриптового пайплайна могут быть сгенерированы с помощью Snippet Generator. Поскольку такой тип пайплайна не содержит директив, вся логика отображается в шагах. Для простых пайплайнов это позволяет сократить общий объём кода.

«CI/CD с Jenkins»

Как создать Jenkins Scripted Pipeline

Для начала войдите в систему и выберите «New Item» на панели слева:

Введите название пайплайна и выберите «Pipeline» из предложенных вариантов. Нажмите «OK», чтобы перейти к следующему шагу:

Теперь вы можете приступать к работе со скриптом пайплайна:

Красное поле — то место, где вы можете начать писать скрипт.

Jenkins Pipeline Script

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

Node Blocks

Первый раздел для определения — «node»:

node {
}

«Node» — часть архитектуры распределённого режима Jenkins, где рабочая нагрузка может быть делегирована нескольким агент-нодам. Мастер-нода обрабатывает все задачи в среде. Агент-ноды Jenkins выгружают сборки с мастер-ноды, тем самым выполняя всю работу в пайплайне. Подробно об этом написано в Jenkins Distributed builds.

Stage Blocks 

Следующий раздел — «stage»:

stage {
}

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

• извлечение кода из репозитория;

• создание проекта;

• развёртывание приложения;

• выполнение функциональных тестов;

• выполнение тестов производительности.

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

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

node {
		stage (‘Build’) {
			bat "msbuild ${C:\\Jenkins\\my_project\\workspace\\test\\my_project.sln}"
		}

stage('Selenium tests') {
dir(automation_path) {  //changes the path to “automation_path”
bat "mvn clean test -Dsuite=SMOKE_TEST -Denvironment=QA"
}  
}
	}

Такой скрипт имеет следующие этапы:

• Build stage: bat «msbuild…». Вы создаёте проект, указав файл решения Visual Studio. 

• Selenium tests stage: dir(automation_path). Изменяете текущий каталог на значение, установленное в переменной Automation_path.

• Selenium tests stage: bat «mvn clean test …». Вызываете maven для выполнения тестов, указанных в «SMOKE_TEST», с использованием значений, определенных в «QA». Также флаг «clean» очищает сборку.

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

Предположим, вы хотите создать скрипт-команды для выполнения пакетного файла Windows:

Нажав на «Generate Pipeline Script», вы создадите нужное предложение, которое можно сразу добавить в скрипт.

The Jenkinsfile 

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

Вы можете настроить Jenkins для автоматического опроса репозитория и запуска новых сборок при обнаружении обновлений. Эта опция доступна на экране конфигурации вашего проекта в разделе «Build triggers»:

Включение «Poll SCM» позволяет ввести cron-подобное выражение в Schedule text box. Однако настройка Jenkins для автоматического опроса репозитория не является чистым и эффективным способом получения обновлений — вместо этого лучше использовать Git Hooks. В этом документе вы найдёте информацию, как настроить Git Hooks. 

Безопасность Jenkins Scripted Pipeline

Опция «Use Groovy Sandbox», доступная на вкладке Jenkins Scripted Pipeline, позволяет запускать скрипты любому пользователю без прав администратора. В этом случае скрипт запускается только с использованием внутренних доступных API.

Если флажок снят, а в сценарии есть операции, требующие одобрения, администратор должен предоставить их. Этот метод известен как «Script approval». По умолчанию все пайплайны Jenkins выполняются в Groovy sandbox. Когда этот параметр установлен, и происходят несанкционированные операции, скрипт завершается ошибкой при запуске. 

Jenkins Scripted Pipeline vs. Declarative Pipeline

Декларативные пайплайны — более поздний подход к принципу «Pipeline-as-code». Он предназначен для упрощения разработки и обслуживания кода за счёт предоставления более осмысленного синтаксиса. 

Как выглядит структура декларативного пайплайна:

• pipeline — определение декларативного пайплайна;

• agent — агент, на котором будет осуществлена сборка;

• stages — стадия сборки;

• steps — атомарные шаги для сборки. 

Если описать это в виде кода: 

pipeline {
	agent any 
	stages {
stage(‘Build’) {
	steps {
		//…
	}
	}
	stage (‘Test’) {
	steps {
		//…
	}
	}
}
}

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

Ещё одна важная особенность — директивы. Они позволяют добавлять инструменты в пайплайн, а также помогают с настройкой триггеров, переменных среды и параметров. 

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

Коротко о главном

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

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

«DevOps Tolls для разработчиков»