Эта статья была спонсирована CloudBees . Спасибо за поддержку спонсоров, которые делают возможным SitePoint!
Недавно я написал серию статей о Jenkins, простой в использовании технологии непрерывной интеграции (CI) для корпоративных ИТ. В этих статьях мы кратко рассмотрели, как мы можем гарантировать качество наших проектов PHP с помощью инструмента. В этой статье мы рассмотрим плагин Jenkins «Рабочий процесс», созданный и поддерживаемый как CloudBees, так и членами сообщества Jenkins. Этот плагин с открытым исходным кодом основан на стандартной технологии CI и расширяет его до платформы с полной непрерывной доставкой (CD) со сложным управлением конвейером.
По мере того, как предприятия расширяют использование Jenkins и внедряют все больше и больше рабочих процессов в свои системы, их автоматизация может стать проблемой. Плагин Workflow помогает создавать и автоматизировать сложные рабочие процессы. С помощью сценариев вы можете смешивать несколько действий, таких как параметризованные триггеры, скопированные артефакты, продвинутые сборки и этапы условной сборки. С помощью плагина Workflow написать такой скрипт становится относительно легко.
Установка и создание рабочего процесса
Прежде чем начать, вы можете убедиться, что у вас есть базовые знания о Jenkins, прочитав мои предыдущие статьи . Если вы этого не сделали, я предлагаю оставить эти статьи открытыми в качестве ссылки.
Давайте начнем с установки плагина Workflow, чтобы получить хорошее представление об этом конкретном плагине. На странице плагина найдите Workflow: Aggregator и установите его. Все зависимости будут установлены автоматически для вас. Когда закончите, обязательно перезапустите Jenkins.
Теперь пришло время создать новую работу, щелкнув новый пункт в левом меню. Заполните форму и убедитесь, что вы выбрали рабочий процесс в качестве вашего типа. Когда закончите, отправьте форму и отправляйтесь прямо на страницу конфигурации для этой работы.
Снаружи конфигурация выглядит очень простой, но очень мощной. Самая важная часть — это поле сценария, в котором вы будете записывать свой рабочий процесс. Написание сценариев выполняется на отличном языке . Давайте начнем со старомодного примера helloworld, поэтому мы получим самые основы этого мощного плагина. Добавьте следующее содержимое в поле скрипта и нажмите «Сохранить».
echo 'Hello SitePoint!'
Если вы начнете сборку и посмотрите на вывод консоли, вы увидите следующее содержимое.
Конечно, приятно видеть, что мы можем вывести сообщение на консоль, но мы хотим написать сценарий всего процесса сборки. Допустим, мы хотим построить наш проект Jumph из предыдущей серии статей.
Если вы новичок в этом языке, как я, вы можете спросить, с чего начать. Для плагина есть генератор фрагментов, который поможет вам начать довольно быстро. Ниже поля скрипта вы увидите генератор фрагментов кода.
Установите флажок перед генератором фрагментов и выберите сборку из задания. Заполните Jumph и нажмите кнопку генерировать Groovy. Вы получите следующий вывод, который вы можете вставить в текстовую область вашего скрипта.
build 'Jumph'
Если вы сейчас запустите сборку, вы заметите, что Jumph действительно запущен. Ницца! Однако мы могли бы начать процесс сборки проекта сами. Это простой пример того, что называется шагом в терминологии рабочего процесса. Шагом также может быть просто архивация артефактов вашего проекта или отправка электронного письма, когда оно будет сделано. Давайте углубимся в рабочий процесс, чтобы лучше понять его возможности.
Допустим, мы хотим построить проект для развертывания. Мы хотим создать tar.gzfile, который позже можно будет использовать для развертывания. С помощью Workflow мы можем записать этот процесс.
def src = 'https://github.com/peternijssen/Jumph.git' stage 'Build' node { git url: src sh 'export SYMFONY_ENV=prod && composer install --no-dev --optimize-autoloader' sh 'bower install' }
В приведенном выше сценарии мы сначала определяем наш URL для репозитория Git. В текущем узле мы извлекаем этот Git-репозиторий и запускаем установку composer, в то время как мы устанавливаем рабочую среду Symfony. Затем мы запускаем Bower для установки наших внешних зависимостей. Если бы мы запустили этот скрипт, наш проект был бы готов к развертыванию.
Возможно, у вас есть такой инструмент, как Gulp или Grunt, который готовит ваш интерфейс. Вы можете легко развернуть этот сценарий для запуска нескольких сценариев, чтобы подготовить приложение к развертыванию.
Следующий шаг, который мы хотим сделать, — это упаковать приложение в файл tar.gz и переместить его в наш общедоступный корень, чтобы его можно было загрузить.
def timestamp = new Date().format(“yyyyMMddHHmmss”) def fileName = 'jumph-' + timestamp + '.tar.gz' stage 'Package', concurrency: 1 node { sh 'tar -zcvf ' + fileName + ' app/ bin/ src/ vendor/ web/' sh 'cp ' + fileName + ' /srv/builds/' mail body: 'A new build is awaiting: ' + fileName, subject: 'New build available', to: '[email protected]' }
Мы также отправляем электронное письмо и проверяем, чтобы имя нашего файла включало временную метку, поэтому мы всегда будем знать, когда файл был фактически создан.
Если мы думаем, что будем использовать эту часть более одного раза, мы можем заключить ее в «функцию».
node { packageApp(fileName) mail body: 'A new build is awaiting: ' + fileName, subject: 'New build available', to: '[email protected]' } /** * Package the app in tar.gz file * * @param fileName name of the file */ def packageApp(fileName) { sh 'tar -zcvf ' + fileName + ' app/ bin/ src/ vendor/ web/' sh 'cp ' + fileName + ' /srv/builds/' }
В итоге ваш полный скрипт будет выглядеть так:
def src = '<a href="https://github.com/peternijssen/Jumph.git">https://github.com/peternijssen/Jumph.git</a>' def timestamp = new Date().format(“yyyyMMddHHmmss”) def fileName = 'jumph-' + timestamp + '.tar.gz' <p>stage 'Build' node { git url: src sh 'export SYMFONY_ENV=prod && composer install –no-dev –optimize-autoloader' sh 'bower install' } stage 'Package', concurrency: 1 node { packageApp(fileName) mail body: 'A new build is awaiting: ' + fileName, subject: 'New build available', to: '[email protected]' } /* FUNCTIONS */ /** * Package the app in tar.gz file * * @param fileName name of the file */ def packageApp(fileName) { sh 'tar -zcvf ' + fileName + ' app/ bin/ src/ vendor/ web/' sh 'cp ' + fileName + ' /srv/builds/' }
У нас все еще есть довольно простой скрипт по сравнению с тем, что мы на самом деле можем сделать с помощью Workflow. Например, мы могли бы также начать с нескольких простых тестов, чтобы убедиться, что наша сборка имеет правильную форму, прежде чем мы на самом деле упаковываем приложение. Вместо упаковки мы могли бы развернуть приложение прямо в нашей промежуточной среде. После проверки нашей промежуточной среды мы также можем разрешить Workflow запросить у вас разрешение на ее развертывание в производственной среде.
Если вас интересуют такие потоки, вы можете посмотреть примеры Java, которые можно найти здесь и здесь .
Возможно, вы также заметили, что мы разделили сценарий на два этапа. Этап с именем build и этап с именем package. Устанавливая параллелизм равным единице на этапе пакета, мы гарантируем, что будет выполнена только самая последняя сборка, прошедшая все предыдущие этапы. Кроме того, сцена также разделит сценарий на разделы.
По мере роста всего процесса сборки вы можете себе представить, что для его завершения может потребоваться много времени. Если ваш сервер затем испытывает проблемы или отключается, весь процесс может быть нарушен. Тем не менее, рабочий процесс является приостановленным. Это означает, что Дженкинс будет помнить, в какой части сценария он остановился, и продолжит выполнение, как только он будет восстановлен. С помощью Workflow вы можете убедиться, что ваш процесс продолжает работать там, где он оставался непосредственно перед выключением.
Вывод
Как видно из статьи, Workflow — это важный шаг в эволюции Jenkins, который переходит от CI к полной непрерывной доставке от dev-to-production, что является ключевой технологией в преобразованиях DevOps. Плагин позволяет вам написать простой скрипт для создания непрерывного конвейера доставки из простой работы.
Если вам интересно, что может делать Workflow, ознакомьтесь с этим руководством, чтобы получить более полное представление. Если вы автор плагина Jenkins, вам может быть интересно, чтобы он работал в сочетании с Workflow через DSL.
Если вам нужен еще более продвинутый пакет, чем плагин Workflow, вы можете взглянуть на решение CloudBees Jenkins Enterprise на веб-сайте CloudBees .
Как Workflow улучшит ваш процесс сборки? Вы уже попробовали?