«Pipeline-as-code» — принцип, который позволяет Jenkins обрабатывать пайплайны как обычные файлы. Существует два способа описания пайплайнов: скриптовый и декларативный. В этой статье поговорим о Jenkins Scripted Pipeline: проанализируем его структуру и разберём варианты использования.  Jenkins Scripted Pipeline — первая версия принципа «Pipeline-as-code». Она представляет собой Groovy-скрипт с использованием Jenkins Pipeline DSL и обеспечивает выдающийся уровень мощности и гибкости.  Скриптовые пайплайны имеют меньше структурных ограничений. В них всего два базовых блока: «node» и «stage». Нода указывает машину, на которой выполняется конкретный пайплайн. Стейдж используется для группировки атомарных шагов, представляющих отдельную операцию.  Шаги для скриптового пайплайна могут быть сгенерированы с помощью Snippet Generator. Поскольку такой тип пайплайна не содержит директив, вся логика отображается в шагах. Для простых пайплайнов это позволяет сократить общий объём кода. «CI/CD с Jenkins» Для начала войдите в систему и выберите «New Item» на панели слева: Введите название пайплайна и выберите «Pipeline» из предложенных вариантов. Нажмите «OK», чтобы перейти к следующему шагу: Теперь вы можете приступать к работе со скриптом пайплайна: Красное поле — то место, где вы можете начать писать скрипт. Пайплайны содержат конкретные предложения или элементы для определения разделов скрипта, которые следуют синтаксису Groovy. Первый раздел для определения — «node»: «Node» — часть архитектуры распределённого режима Jenkins, где рабочая нагрузка может быть делегирована нескольким агент-нодам. Мастер-нода обрабатывает все задачи в среде. Агент-ноды Jenkins выгружают сборки с мастер-ноды, тем самым выполняя всю работу в пайплайне. Подробно об этом написано в Jenkins Distributed builds. Следующий раздел — «stage»: Пайплайн состоит из нескольких шагов, которые можно сгруппировать по этапам сборки. Среди этапов выделяют: извлечение кода из репозитория; создание проекта; развёртывание приложения; выполнение функциональных тестов; выполнение тестов производительности. Каждый из них может включать в себя более одного действия. Например, этап развёртывания приложения может состоять из копирования файлов в определённую среду для функциональных тестов и на выделенный сервер для тестов производительности. Как только файлы будут успешно скопированы, вы приступите к развёртыванию. Каждый этап сборки определяет задачи, необходимые для выполнения. Например, полный скриптовый пайплайн может выглядеть так: Такой скрипт имеет следующие этапы: 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», вы создадите нужное предложение, которое можно сразу добавить в скрипт. Jenkinsfile — простой текстовый файл с кодом на языке Groovy, который используется для конфигурации пайплайна. Редактировать его можно через веб-интерфейс Jenkins или с помощью текстового редактора.  Вы можете настроить Jenkins для автоматического опроса репозитория и запуска новых сборок при обнаружении обновлений. Эта опция доступна на экране конфигурации вашего проекта в разделе «Build triggers»: Включение «Poll SCM» позволяет ввести cron-подобное выражение в Schedule text box. Однако настройка Jenkins для автоматического опроса репозитория не является чистым и эффективным способом получения обновлений — вместо этого лучше использовать Git Hooks. В этом документе вы найдёте информацию, как настроить Git Hooks.  Опция «Use Groovy Sandbox», доступная на вкладке Jenkins Scripted Pipeline, позволяет запускать скрипты любому пользователю без прав администратора. В этом случае скрипт запускается только с использованием внутренних доступных API. Если флажок снят, а в сценарии есть операции, требующие одобрения, администратор должен предоставить их. Этот метод известен как «Script approval». По умолчанию все пайплайны Jenkins выполняются в Groovy sandbox. Когда этот параметр установлен, и происходят несанкционированные операции, скрипт завершается ошибкой при запуске.  Декларативные пайплайны — более поздний подход к принципу «Pipeline-as-code». Он предназначен для упрощения разработки и обслуживания кода за счёт предоставления более осмысленного синтаксиса.  Как выглядит структура декларативного пайплайна: pipeline — определение декларативного пайплайна; agent — агент, на котором будет осуществлена сборка; stages — стадия сборки; steps — атомарные шаги для сборки.  Если описать это в виде кода:  Одно из преимуществ декларативного пайплайна заключается в том, что он позволяет определить действия после каждого стейджа или после всей сборки. Его рекомендуют использовать при описании пайплайнов на верхнем уровне. Ещё одна важная особенность — директивы. Они позволяют добавлять инструменты в пайплайн, а также помогают с настройкой триггеров, переменных среды и параметров.  Сила декларативных пайплайнов во многом исходит как раз из директив. Так, с помощью директивы «script» декларативные пайплайны могут использовать возможности скриптовых пайплайнов. Эта директива выполняется строки внутри в виде скриптового пайплайна. Несмотря на различия в синтаксисе, скриптовые и декларативные пайплайны преследуют одну и ту же цель. По сути, это два разных инструмента для решения одной проблемы, поэтому их можно считать взаимозаменяемыми.  Краткий синтаксис декларативных пайплайнов обеспечивает более быстрый и плавный вход в CI/CD. Однако скриптовые пайплайны предлагают больше возможностей для опытных пользователей. Чтобы получить лучшее из «обоих миров», вы можете использовать декларативные пайплайны со скриптовыми директивами.  «DevOps Tolls для разработчиков»  Редактор в MobileUp