что делает jenkins master

Управление задачами в Jenkins

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

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

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

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

Ниже мы рассмотрим, как упростить и ускорить создание задач в Jenkins.

Инструменты, которые будем использовать

Jenkins job builder

Это python-утилита, позволяющая описывать задачи в YAML- или JSON форматах, которые через HTTP API загружаются на сервер. Для работы достаточно установить ее на локальной машине, написать конфигурацию с подключением и описать требуемые задачи.

DSL Plugin

Это плагин для Jenkins, с помощью которого мы сможем описывать задачи на специальном языке (DSL, Domain Specific Language) и создавать их на основе этих описаний. Работает локально на самом Jenkins-сервере.

Jenkins Pipeline

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

Gitlab и Gitlab CI

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

Внутри имеется собственный CI, написанный на Go, который через специальные подключаемые агенты (runners) позволяет нам проводить различные стадии сборки и деплоя.

Итак, начнем

Для начала поставим необходимые инструменты. Jenkins-job-builder в нашем случае необходимо установить как на локальную машину, так и на машину, где будет работать агент gitlab. Можно обойтись просто локальной машиной gitlab.

Локально на linux и mac установим последнюю доступную версию:

Локально для описания нашего seed job мы сможем протестировать его работоспособность.
Добавлю, что seed job в терминологии DSL Plugin является задача типа Free-style project, которая создает остальные задачи из DSL-скриптов.

На gitlab-сервере установка будет ничем не отличаться от локальной установки на linux-машину:

На всякий случай запустим утилиту и проверим, что она работает:

Установка плагина

Теперь установим плагин в Jenkins. Для установки можно воспользоваться как классическим UpdateCenter в разделе Manage Jenkins → Manage Plugins → Available, так и используя установку с помощью curl/wget, скачав плагин с официальной страницы плагина:

Создание репозитория

Создадим репозитории под код с описанием задач.

Для начала подготовим наш seed job — так называется задача, которая генерирует из себя все остальные. Репозиторий будет состоять из следующих файлов:

jenkins.ini

job-generator.yml

.gitlab-ci.yml

Подключим gitlab-runner к нашему проекту. Поскольку интерфейс gitlab последнее время часто меняется, то рекомендуем обращаться к официальной документации.

После подключения он будет выглядеть примерно так:

Теперь закоммитим изменения и в разделе Jobs у нашего проекта увидим следующее:

Вся схема выглядит следующим образом:

Подготовим репозиторий с описанием задач. Создадим его с названием repo-dsl и плоской структурой. Все файлы располагаются как есть.
Положим в него файл с нашим pipeline:

И настроим webhook по запуску seed-job, который мы создали ранее.

В данной версии gitlab webhooks располагаются в проекте в разделе Settings → Integrations.
Создаем webhook на push (http://gitlab:pass@ci.org/project/job-generator). Схематично это выглядит вот так:

Теперь в нашем Jenkins есть две задачи:

В проекте с названием sample-project создадим Jenkinsfile следующего содержания:

В итоге готовый pipeline будет выглядеть следующим образом в интерфейсе blueocean в Jenkins:

Или так в классическом интерфейсе:

Для запуска этой задачи автоматически мы можем добавить webhook в проекте с docker-image, где после отправки изменений в репозиторий будет запускаться эта задача.

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

Источник

Учимся разворачивать микросервисы. Часть 4. Jenkins

Это четвертая и заключительная часть серии статей «Учимся разворачивать микросервисы», и сегодня мы настроим Jenkins и создадим пайплайн для микросервисов нашего учебного проекта. Jenkins будет получать файл конфигурации из отдельного репозитория, собирать и тестировать проект в Docker-контейнере, а затем собирать Docker-образ приложения и пушить его в реестр. Последней операцией Jenkins будет обновлять кластер, взаимодействуя с Helm (более подробно о нем в прошлой части).

Ключевые слова: Java 11, Spring Boot, Docker, image optimization

Ключевые слова: Kubernetes, GKE, resource management, autoscaling, secrets

Ключевые слова: Helm 3, chart deployment

Настройка Jenkins и пайплайна для автоматической доставки кода в кластер

Ключевые слова: Jenkins configuration, plugins, separate configs repository

Jenkins — это сервер непрерывной интеграции, написанный на Java. Он является чрезвычайно расширяемой системой из-за внушительной экосистемы разнообразных плагинов. Настройка пайплайна осуществляется в декларативном или императивном стиле на языке Groovy, а сам файл конфигурации (Jenkinsfile) располагается в системе контроля версий вместе с исходным кодом. Это удобно для небольших проектов, однако, часто более практично хранить конфигурации всех сервисов в отдельном репозитории.

Код проекта доступен на GitHub по ссылке.

Установка и настройка Jenkins

Установка

Существует несколько способов установить Jenkins:

War-архив с программой можно запустить из командной строки или же в контейнере сервлетов (№ Apache Tomcat). Этот вариант мы не будем рассматривать, так как он не обеспечивает достаточной изолированности системы.

Устранить этот недостаток можно, установив Jenkins в Docker. Из коробки Jenkins поддерживает использование докера в пайплайнах, что позволяет дополнительно изолировать билды друг от друга. Запуск докера в докере — плохая идея (здесь можно почитать почему), поэтому необходимо установить дополнительный контейнер ‘docker:dind’, который будет запускать новые контейнеры параллельно контейнеру Jenkins’а.

Также возможно развернуть Jenkins в кластере Kubernetes. В этом случае и Jenkins, и дочерние контейнеры будет работать как отдельные поды. Любой билд будет полностью выполняться в собственном контейнере, что максимально изолирует выполнения друг от друга. Из недостатков этот способ имеет довольно специфичную конфигурацию. Из приятных бонусов Jenkins в Google Kubernetes Engine может быть развернут одним кликом.

Хоть третий способ и кажется наиболее продвинутым, мы выберем прямолинейный путь и развернем Jenkins в Docker напрямую. Это упростит настройку, а также избавит нас от нюансов работы со stateful приложениями в Kubernetes. Хорошая статья для любопытствующих про Jenkins в Kubernetes.

Так как проект учебный, то мы установим Jenkins на локальной машине. В реальной обстановке можно посмотреть в сторону, например, Google Compute Engine. В дополнение замечу, что изначально я пробовал использовать Jenkins на Raspberry Pi, но из-за разной архитектуры «малинки» и машин кластера они не могут использовать одни и те же Docker-образы. Это делает невозможным применение Raspberry Pi для подобных вещей.

После установки Jenkins открываем http://localhost:8080/ и следуем инструкциям. Настроить Jenkins можно через UI, либо программно. Последний подход иногда называют «инфраструктура как код» (IaC). Он подразумевает описание конфигурации сервера с помощью хуков — скриптов на Groovy. Оставим этот способ настройки за рамками данной статьи. Для интересующихся ссылка.

Плагины

Для нашего проекта нам понадобится установить два плагина: Remote File Plugin и Kubernetes CLI. Remote File Plugin позволяет хранить Jenkinsfile в отдельном репозитории, а Kubernetes CLI предоставит доступ к kubectl внутри нашего пайплайна.

Установка Helm

Глобальные переменные среды

Так как у нас два сервиса, то мы создадим два пайплайна. Некоторые данные у них будут совпадать, поэтому логично вынести их в одно место. Это можно сделать, задав глобальные переменные среды, которые будут установлены перед выполнением любого билда на сервере Jenkins. Отмечу, что не стоит с помощью этого механизма передавать пароли — для этого существуют секреты.

Секреты

В предыдущей части в файле NOTES.txt нашего чарта мы описали последовательность команд для получения токена сервисного аккаунта. Вывести эти команды для кластера можно, запросив статус Helm-инсталляции ( helm status msvc-project ).

Конфигурация пайплайна

Как уже было упомянуто ранее, пайплайны описываются на Groovy, и могут быть написаны в декларативном и императивном стилях. Мы будем придерживаться декларативного подхода.

В Jenkins процесс выполнения пайплайна (билд) поделен на ряд шагов (stage). Каждый шаг выполняется определенным агентом (agent).

Наши пайплайны будут состоять из следующих шагов:

Структура файла конфигурации

Файл конфигурации будет иметь следующую структуру:

Агенты в Jenkins подчиняются типичным правилам «наследования» — если в шаге не определен агент, то будет использован агент родительского шага. Тег pipeline может рассматриваться как корневой шаг для всех остальных. Корневой шаг мы используем для объявления переменных среды и опций, которые по тому же правилу наследования будут иметь силу для всех вложенных шагов. Поэтому для тега pipeline установлен агент ‘none’. Использование этого агента подразумевает, что вложенные шаги обязаны переопределить этот агент для выполнения каких-либо полезных действий.

Агент в шагах Push Images и Trigger Kubernetes равен ‘any’. Это значит, что шаг может быть выполнен на любом доступном агенте. В простейшем случае это означает выполнение в контейнере Jenkins’а. Также эти шаги будут выполнены только для коммитов в мастер-ветку ( when < branch 'master' >).

Далее мы более пристально посмотрим на каждый из шагов, а также на блоки options и environment.

Опции

Блок опций может быть использован для настройки выполнения пайплайна или же отдельного шага. Мы используем следующие опции:

skipStagesAfterUnstable заставит Jenkins сразу прервать билд, eсли тесты были провалены. Поведение по умолчанию предусматривает установку статуса билда в UNSTABLE и продолжение выполнения. Это позволяет в сложных случаях более гибко обрабатывать подобные ситуации.

skipDefaultCheckout отключает автоматический чекаут репозитория проекта. Дефолтно Jenkins делает force чекаут репозитория для каждого шага с собственным агентом (в нашем случае Prepare Checkout, Push images и Trigger Kubernetes). То есть по сути затирает все изменения. Это может быть полезно при использовании пайплайна с несколькими различными образами. Однако нам нажно получить исходники с репозитория только единожды — на шаге Build. Применив опцию skipDefaultCheckout, мы получаем возможность произвести чекаут вручную. Также стоит заметить, что Jenkins будет автоматически переносить артефакты между шагами. Так, например, скомпилированные исходники из шага Build будут полностью доступны в шаге Test.

Переменные среды

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

В предыдущих статьях при работе с кластером мы всегда использовали наиболее свежие latest образы, но напомню, что это не лучший вариант из-за проблем при откатах к предыдущим версиям. Поэтому мы предполагаем, что в начальный момент времени кластер создается из самых свежих образов, а потом уже будет обновляться на конкретную версию. Тег IMAGE_TAG будет зависеть только от номера билда, который можно получить из предустановленной глобальной переменной среды BUILD_NUMBER. Таким образом наши версии будут составлять монотонную последовательность при условии того, что пайплайн не будет пересоздаваться (это приведет к сбросу номера билда). При неуспешных билдах BUILD_NUMBER также будет инкрементирован, следовательно последовательность версий образов может содержать «пробелы». Основное преимущество такого подхода к версионированию — его простота и удобство восприятия человеком. В качестве альтернативы можно подумать об использовании метки времени, чексуммы коммита или даже внешних сервисов.

Компиляция, тестирование, сборка

Чисто технически фазы компиляции, тестирования и сборки возможно объединить в один шаг, но для лучшей наглядности мы опишем их как отдельные шаги. С помощью плагинов Maven можно с легкостью добавлять дополнительные фазы, такие как статический анализ кода или интеграционное тестирование.

В фазе тестирования командой junit ‘**/target/surefire-reports/TEST-*.xml’ мы указываем Jenkins’у на файл с результатами тестов. Это позволит их отобразить прямо в веб-интерфейсе.

На последнем шаге мы генерируем jar-архив с нашим приложением.

Создание и отправка Docker-образа в реестр

На следующем шаге мы должны собрать Docker-образы и запушить их в реестр. Мы будем делать это средствами Jenkins, но в качестве альтернативы можно реализовать это и с помощью Maven-плагина.

Для начала нам надо доработать докер-файлы наших сервисов, которые мы разработали в первой статье цикла. Эти докер-файлы собирали приложение из исходников прямо в процессе создания образа. Сейчас же у нас имеется протестированный архив, следовательно один из шагов создания образа уже выполнен средствами Jenkins. Мы назовем этот новый файл Dockerfile-packaged.

Докер-файл для микросервиса шлюза аналогичен.

В конце шага происходит удаление установленных локально образов.

Обновление кластера Kubernetes

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

Итоговый Jenkinsfile

Jenkinsfile для микросервиса шлюза полностью аналогичен.

Подключение пайплайна

В Jenkins существует несколько видов пайплайнов. В данном проекте мы используем Multibranch pipeline. Как и следует из названия, билд будет запускаться для любого коммита в произвольной ветке.

Branch sources. Выбираем GitHub, в графе ‘Credentials’ выбираем секрет с логином/паролем от аккаунта и указываем URL репозитория с исходным кодом микросервиса.

Build Configuration. В Mode выбираем ‘by Remote File Plugin’, основное поле — Repository URL, в котором надо указать адрес репозитория с Jenkinsfile, а также Script Path с путем к этому файлу.

Scan Repository Triggers. В этом разделе настроим период, с которым Jenkins будет проверять, появились ли какие-то изменения в отслеживаемом репозитории. Недостаток этого подхода в том, что Jenkins будет генерировать трафик, даже когда в репозитории ничего не менялось. Более грамотный подход — настроить веб-хуки. При этом хранилище исходного кода само будет инициировать запуск билда. Очевидно, что сделать это можно, только если Jenkins доступен по сети для хранилища исходных кодов (они должны быть либо в одной сети, либо Jenkins должен иметь публичный IP-адрес). Подключение веб-хуков оставим за рамками данной статьи.

Запуск

После того как наш пайплайн настроен, можно его запустить. Наиболее удобно это сделать из меню Blue Ocean (Open Blue Ocean). Первый запуск может занять продолжительное время, так как потребуется время на загрузку Maven-зависимостей. После выполнения билда можно подключиться к кластеру и убедиться в том, что тег образа микросервиса был изменен ( helm get values msvc-project ).

В дальнейшем Jenkins будет отслеживать изменения в репозитории микросервиса и запускать билд автоматически.

Заключение

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

Источник

Непрерывная интеграция и развертывание (Deployment) с помощью Jenkins

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

Прежде всего, что такое Jenkins?

Jenkins — это средство автоматизации с открытым исходным кодом, которое используется для автоматизированного создания, тестирования и развертывания программного обеспечения, упрощая непрерывную интеграцию и непрерывное развертывание для пользователей.

По сути, это означает, что Jenkins (и многие другие инструменты) позволяют автоматизировать процесс развертывания или предоставления изменений в вашем программном обеспечении пользователям сразу после того, как эти изменения готовы. Представим насколько удобно пользователям видеть обновленные сайты сразу после объединения PR с master (или main).

Почему именно Jenkins?

У него сильное сообщество, поэтому найти поддержку не проблема.

Jenkins можно легко настроить, и я надеюсь доказать это в данной статье, так что читайте дальше.

В этом руководстве мы узнаем, как выполнить CI/CD для приложения Node с помощью Jenkins. Давайте начнем с определения всех шагов, которые мы предпримем, а затем подробно объясним их ниже:

Создайте репозиторий GitHub для приложения node

Создайте простое приложение node и поместите его на GitHub

Создайте приложение Heroku для развертывания

Добавьте веб-хук GitHub для внесения изменений в Jenkins

Сконфигурируйте приложение с помощью Jenkins

Добавьте плагины GitHub в Jenkins

Сконфигурируйте Jenkins для развертывания на Heroku после успешного тестирования

Необходимые условия

Учетная запись на GitHub. Можно зарегистрироваться здесь.

Учетная запись Heroku. Можно зарегистрироваться здесь.

Учетная запись на GitHub. Можно зарегистрироваться здесь.

Учетная запись Heroku. Можно зарегистрироваться здесь.

Итак, давайте начнем!

После создания репозитория, клонируйте его на локальную машину с помощью следующей команды:

Не забудьте изменить repository_url на свой.

Вы можете удалить или изменить то, что находится в блоке скриптов вашего файла package.json, и добавить start и test для запуска и тестирования приложения:

Мы будем использовать express для нашего примера приложения node, поэтому инсталлируйте его, запустив эту команду в терминале:

Далее создайте файл index.js, который будет служить точкой входа в наше приложение node, и добавьте в него следующие строки:

Запустите npm start и зайдите на http://localhost:4000/ через браузер для просмотра приложения Node, на экране появится Hello world.

Далее мы добавим пару тестов в наше приложение, впоследствии, с помощью CI, мы должны убедиться, что тесты доступны и выполняются перед тем как объединить изменения.

Итак, вернитесь в терминал, убедитесь, что вы находитесь в корневом каталоге вашего проекта, и установите пакеты jest и supertest с помощью следующей команды:

Далее в корневом каталоге проекта создайте папку и назовите ее __test__ (два знака подчеркивания, предшествующий и завершающий). Внутри этой папки __test__ создайте файл index.test.js и добавьте в него по крайней мере следующий код (вы всегда можете сделать свои тесты более полными).

Запустите npm test или npm run test в терминале, и вы убедитесь, что тест(ы) прошел(и):

Теперь, когда наш код запущен и тесты пройдены, можно закоммитить изменения и отправить их на GitHub.

Войдите в свою панель управления Heroku.

Посмотрите в правый верхний угол и нажмите на New.

Выберите Create new app (Создать новое приложение).

Добавьте App name (название приложения) по своему выбору и выберите регион (Choose a region), в котором вы находитесь.

Нажмите Создать приложение (Create app).

Вернитесь в терминал вашего проекта и login (войдите) в Heroku с помощью Heroku CLI. Если вы еще не установили Heroku CLI, вы можете прочесть эту статью.

После этого добавьте remote в ваш локальный репозиторий с помощью:

Затем введите код с помощью:

Это делается для того, чтобы убедиться, что все работает правильно, прежде чем автоматизировать его. Вы можете нажать open app (открыть приложение) на приборной панели приложения Heroku, чтобы проверить, правильно ли оно работает.

Откройте новый терминал и войдите на свой сервер под учетной записью пользователя non-root.

После этого мы можем обновить ядро с помощью следующей команды:

Выполните следующую команду для установки java runtime:

Выполните следующие команды одну за другой для установки Jenkins.

Теперь, когда Jenkins и все зависимости инсталлированы мы можем запустить его с помощью:

Вы можете проверить успешность запуска Jenkins, используя:

Он должен показать active:

Поскольку Jenkins выполняется на порту 8080, давайте откроем его с помощью ufw:

Вы можете проверить состояние ufw с помощью:

Теперь посетите сайт http://ip_address:8080 для настройки Jenkins, на котором вы должны увидеть экран Unlock Jenkins.

Чтобы разблокировать Jenkins, вернитесь к терминалу и введите следующую команду для отображения пароля. Скопируйте пароль и вставьте его в поле Administrator password (Пароль администратора).

На следующем экране отображается Customize Jenkins (Настроить Jenkins), нажмите на Install suggested plugins (Установите предложенные плагины).

После завершения установки мы перейдем к экрану Create First Admin User (Создание первого пользователя-администратора). Введите Username (имя пользователя), Password (пароль), Full name (полное имя) и E-mail address (адрес электронной почты) для вашего пользователя, затем Save and Continue (Сохранить и продолжить).

После этого введите IP-адрес сервера, т.е. http://ip_address:8080, затем Save and Finish (Сохранить и Завершить).

Ура, Jenkins готов! Нажмите на Start using Jenkins (Начать использование Jenkins).

В репозитории GitHub приложения перейдите в Settings (Настройки), затем на боковой панели нажмите на Webhooks. Нажмите на Add webhooks (Добавить веб-хуки) и введите url Jenkins с приставкой /github-webhook/ в поле Payload URL.

Выберите application/json для Content-type.

Выберите Just the push event для события, запускающего веб-хук.

Установите флажок Active и нажмите Add webhook. Теперь GitHub может успешно отправлять события в Jenkins.

Откройте новую вкладку или окно терминала и войдите на свой сервер с той же учетной записью пользователя non-root.

В том же терминале включите привилегии root, используя:

После переключения пользователя с правами root и инсталляции npm, Jenkins автоматически создает нового пользователя после завершения установки. Переключитесь на него с помощью этой команды.

Сгенерируйте новый ключ SSH с помощью следующей команды:

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

После завершения процесса распечатайте информацию об открытом ключе с помощью:

Скопируйте открытый ключ.

Теперь войдите обратно как пользователь non-root в новом терминале.

Откройте папку authorized_keys следующей командой:

Вставьте открытый ключ id_rsa и выйдите.

Чтобы убедиться, что ключи настроены правильно, переключитесь на терминал сервера jenkins и попробуйте войти в систему как пользователь non-root, используя ssh. Вы успешно войдете в систему, если будете следовать всем вышеописанным действиям.

На приборной панели Jenkins перейдите в раздел Manage jenkins (Управление jenkins), а затем нажмите на Manage plugins (Управление плагинами).

На вкладке Available найдите github и выберите Github Integration plugin (Интеграционный плагин Github).

Нажмите на Install without restart (Установить без перезагрузки), и плагин будет установлен через несколько секунд.

Теперь, когда GitHub подключен к Jenkins, мы можем создать новый проект.

На боковой панели нажмите на New Item (Новая тема), выберите Freestyle project из предложенных вариантов и нажмите OK.

Далее вы должны попасть на страницу конфигурации, но если этого не произошло, можно открыть ее, нажав Configure на левой боковой панели.

Далее прокрутите вниз до раздела Source Code Management (Управление исходным кодом), выберите Git и добавьте Repository URL с расширением .git (тот же url, который вы использовали для клонирования репозитория).

Вы можете изменить master ветвь на main или любые другие ветви, которые вам нужны для процесса развертывания.

Нажмите на кнопку Add repository (Добавить репозиторий), чтобы добавить второй репозиторий, указывающий на ваше приложение Heroku.

Чтобы получить ссылку на репозиторий приложения Heroku, перейдите в App settings (настройки приложения) на панели управления Heroku и скопируйте ссылку.

Вернитесь на приборную панель Jenkins и вставьте эту ссылку в Repository URL.

Нам понадобятся новые учетные данные, поэтому нажмите на Add, чтобы создать их для нашего приложения Heroku.

Выберите Jenkins из списка, и у вас должно появиться всплывающее окно.

Введите username (имя пользователя) по своему выбору, но лучше всего, чтобы оно было каким-нибудь описательным. Я буду использовать heroku в качестве имени пользователя.

Далее нам нужно будет добавить Heroku Api key (Api-ключ) в поле Password

(Пароль) и Save (Сохранить). Чтобы получить Heroku Api key, перейдите на приборную панель Heroku, нажмите на Account Settings (Настройки аккаунта) и прокрутите вниз, чтобы увидеть Api key. Скопируйте его и вставьте в поле Password (Пароль).

Вы можете добавить Description (Описание) для этой учетной записи, если хотите.

Нажмите Add (Добавить), чтобы завершить создание учетной записи.

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

Далее нажмите на advanced и добавьте Name, чтобы идентифицировать это хранилище среди других удаленных хранилищ. Это имя понадобится нам позже. Я назвал свое хранилище jenkinsTest, потому что это легко и понятно.

Далее прокрутите вниз до раздела Build Triggers и отметьте опцию GitHub hook trigger for GITScm polling (Триггер хука GitHub для опроса GITScm).

В разделе Build нажмите на кнопку Add build step (Добавить шаг сборки) и затем нажмите на Execute shell (Выполнить командную оболочку). Введите в оболочку следующий код:

Нажмите на Add post-build action (Добавить действие после сборки), выберите Git Publisher и укажите опцию Push Only If Build Succeeds (Запускать только в случае успеха сборки).

Нажмите на Add Branch (Добавить ветвь), введите имя ветви для развертывания в поле Branch to Push и добавьте Name, используемое для идентификации репозитория приложения Heroku, в поле Target remote name (мое имя было jenkinsTest, если вы помните, поэтому добавьте сюда свое).

Затем Save (сохраните).

Перейдите на приборную панель проекта, нажмите Build now (Построить сейчас) на левой боковой панели и с удовольствием наблюдайте за успешной сборкой вашего кода!

Внесите изменения в свой код и опубликуйте его на GitHub. Затем посмотрите, как ваш код будет автоматически развернут на Heroku.

Приглашаем всех желающих ознакомиться с онлайн-курсами, которые помогут прокачаться в JavaScript-разработке:

Источник