как установить jenkins на windows

3) Скачать и установить Jenkins

Jenkins может быть установлен на платформе Windows или Unix, но мы сосредоточимся только на установке Windows.

Предпосылки:

Прежде чем приступить к установке Jenkins в вашей системе Windows, есть некоторые предварительные условия для установки Jenkins на ваш компьютер.

Требования к оборудованию:

Требования к программному обеспечению:

Типы релизов

Jenkins выпускает два типа версий в зависимости от потребностей организации.

Долгосрочная поддержка релиза (LTS):

Долгосрочные релизы поддержки доступны каждые 12 недель. Они стабильны и широко тестируются. Этот выпуск предназначен для конечных пользователей.

Еженедельный выпуск:

Еженедельные выпуски доступны каждую неделю, исправляя ошибки в более ранней версии. Эти релизы предназначены для разработчиков плагинов.

Мы будем использовать релиз LTS, хотя процесс будет таким же, как и для еженедельного выпуска.

Как скачать Дженкинс?

Для успешной установки Jenkins необходимо выполнить следующие шаги:

Шаг 1) Перейдите на https://jenkins.io/download/ и выберите платформу. В нашем случае Windows

Шаг 3) На экране установки Jenkin нажмите Далее.

Шаг 5) Нажмите на кнопку Установить.

Шаг 6) После завершения установки нажмите «Готово».

Шаг 7) Во время процесса установки может появиться информационная панель, информирующая пользователя о том, что для полной настройки система должна быть перезагружена в конце текущей установки. Нажмите кнопку ОК, когда всплывет информационная панель:

Как разблокировать Дженкинс?

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

Шаг 1) После завершения процесса установки Jenkins откроется вкладка браузера с запросом начального пароля администратора. Чтобы получить доступ к Jenkins, вам нужно перейти по следующему пути в вашем веб-браузере.

HTTP: // локальный: 8080

Если вы можете получить доступ к указанному выше URL-адресу, это подтверждает, что Jenkins успешно установлен в вашей системе.

Шаг 2) Исходный пароль администратора должен быть найден в пути установки Jenkins (задается на шаге 4 в разделе Установка Jenkins).

Для расположения по умолчанию C: \ Program Files (x86) \ Jenkins, файл с именем initialAdminPassword можно найти в C: \ Program Files (x86) \ Jenkins \ secrets.

Шаг 4) Вставьте пароль во всплывающую вкладку браузера ( http: // localhost: 8080 / login? Form =% 2F ) и нажмите кнопку «Продолжить».

Настроить Дженкинс

Вы также можете настроить свою среду Jenkins, выполнив следующие действия:

Шаг 1) Нажмите кнопку «Установить предложенные плагины», чтобы Jenkins извлекла и установила необходимые плагины

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

Шаг 2) После установки всех предложенных плагинов откроется панель «Создать первого администратора». Заполните все поля нужными реквизитами и нажмите кнопку « Сохранить и завершить ».

Шаг 3) После того, как вы заполните указанные выше данные, наконец, он запросит информацию URL, где вы можете настроить путь к экземпляру по умолчанию для Jenkins. Оставьте это как есть, чтобы избежать путаницы позже. Однако, если другое приложение уже использует порт 8080, вы можете использовать другой порт для Jenkins и, наконец, сохранить настройки, и вы закончили установку Jenkins. Нажмите кнопку « Сохранить и продолжить »:

Поздравляем! Мы успешно установили новый сервер Jenkins. Нажмите кнопку «Начать использовать Дженкинс».

Ниже вы можете найти и запустить экземпляр Jenkins, готовый создать первые задания Jenkins:

Источник

Windows

The simplest way to install Jenkins on Windows is to use the Jenkins Windows installer. That program will install Jenkins as a service using a 64 bit JVM chosen by the user. Keep in mind that to run Jenkins as a service, the account that runs Jenkins must have permission to login as a service.

Prerequisites

Minimum hardware requirements:

1 GB of drive space (although 10 GB is a recommended minimum if running Jenkins as a Docker container)

Recommended hardware configuration for a small team:

50 GB+ of drive space

Comprehensive hardware recommendations:

For Windows operating system: Windows Support Policy

Installation steps using Windows MSI installer

Refer to the Windows section of the Downloading Jenkins page to download either an LTS release or a weekly release of the Windows installer. After the download completes, open the Windows installer and follow the steps below to install Jenkins.

On opening the Windows Installer, an Installation Setup Wizard appears, Click Next on the Setup Wizard to start your installation.

Select the destination folder to store your Jenkins Installation and click Next to continue.

When Installing Jenkins, it is recommended to install and run Jenkins as an independent windows service using a local or domain user as it is much safer than running Jenkins using LocalSystem(Windows equivalent of root) which will grant Jenkins full access to your machine and services.

To run Jenkins service using a local or domain user, specify the domain user name and password with which you want to run Jenkins, click on Test Credentials to test your domain credentials and click on Next.

Specify the port on which Jenkins will be running, Test Port button to validate whether the specified port if free on your machine or not. Consequently, if the port is free, it will show a green tick mark as shown below, then click on Next.

The installation process checks for Java on your machine and prefills the dialog with the Java home directory. If the needed Java version is not installed on your machine, you will be prompted to install it.

Once your Java home directory has been selected, click on Next to continue.

Select other services that need to be installed with Jenkins and click on Next.

Click on the Install button to start the installation of Jenkins.

Additionally, clicking on the Install button will show the progress bar of installation, as shown below:

Once the installation completes, click on Finish to complete the installation.

Jenkins will be installed as a Windows Service. You can validate this by browsing the services section, as shown below:

Post-installation setup wizard

After downloading, installing and running Jenkins, the post-installation setup wizard begins.

This setup wizard takes you through a few quick «one-off» steps to unlock Jenkins, customize it with plugins and create the first administrator user through which you can continue accessing Jenkins.

Unlocking Jenkins

When you first access a new Jenkins instance, you are asked to unlock it using an automatically-generated password.

Browse to http://localhost:8080 (or whichever port you configured for Jenkins when installing it) and wait until the Unlock Jenkins page appears.

The initial Administrator password should be found under the Jenkins installation path (set at Step 2 in Jenkins Installation).

For default installation location to C:\Program Files\Jenkins, a file called initialAdminPassword can be found under C:\Program Files\Jenkins\secrets.

However, If a custom path for Jenkins installation was selected, then you should check that location for initialAdminPassword file.

Open the highlighted file and copy the content of the initialAdminPassword file.

On the Unlock Jenkins page, paste this password into the Administrator password field and click Continue.
Notes:

You can also access Jenkins logs in the jenkins.err.log file in your Jenkins directory specified during the installation.

The Jenkins log file is another location (in the Jenkins home directory) where the initial password can also be obtained. This password must be entered in the setup wizard on new Jenkins installations before you can access Jenkins’s main UI. This password also serves as the default admininstrator account’s password (with username «admin») if you happen to skip the subsequent user-creation step in the setup wizard.

Customizing Jenkins with plugins

After unlocking Jenkins, the Customize Jenkins page appears. Here you can install any number of useful plugins as part of your initial setup.

Click one of the two options shown:

The setup wizard shows the progression of Jenkins being configured and your chosen set of Jenkins plugins being installed. This process may take a few minutes.

Creating the first administrator user

Finally, after customizing Jenkins with plugins, Jenkins asks you to create your first administrator user.

When the Create First Admin User page appears, specify the details for your administrator user in the respective fields and click Save and Finish.

When the Jenkins is ready page appears, click Start using Jenkins.
Notes:

This page may indicate Jenkins is almost ready! instead and if so, click Restart.

If the page does not automatically refresh after a minute, use your web browser to refresh the page manually.

If required, log in to Jenkins with the credentials of the user you just created and you are ready to start using Jenkins!

Troubleshooting Windows installation

Invalid service logon credentials

When installing a service to run under a domain user account, the account must have the right to logon as a service. This logon permission applies strictly to the local computer and must be granted in the Local Security Policy.

Perform the following steps below to edit the Local Security Policy of the computer you want to define the ‘logon as a service’ permission:

Logon to the computer with administrative privileges.

Open the Administrative Tools and open the Local Security Policy

Expand Local Policy and click on User Rights Assignment

In the right pane, right-click Log on as a service and select properties.

Click on the Add User or Group… button to add the new user.

In the Select Users or Groups dialogue, find the user you wish to enter and click OK

Click OK in the Log on as a service Properties to save changes.

After completing the steps above, try logging in again with the added user.

Источник

Установка Jenkins и Bonobo Git Server под ОС Windows для сборки Android приложений

Дистрибутивы

Последние приготовления

Можете с самого начала установить JDK, Git for Windows и Android SDK Tools с настройками по дефолту.

Bonobo Git Server

Простой и лёгкий git сервер под собой требует установки IIS и ASP.MVC что включает MS SQL Server Express 2008

IIS Server

Тут ничего необычного, добавляем роль Web Server (IIS):

Главное на следущей форме не пропустить добавить ASP.NET 4.5 в Feature:

ASP.NET MVC4

Попутно установится MS SQL Server 2008 Express и нас спросят пароль для УЗ sa. Надеюсь без надобности она более не потребуется:

После установки MVC нужно по новой пройтись в настройки серверных ролей (не features, а раньше) и добавить web-серверу поддержку ASP.NET4.5. До установки ASP.NET MVC 4 этого подраздела (Application Development) в компонентах IIS не было!

Bonobo Git Server

Всё, теперь можно перейти к непосредственно развёртыванию git сервера. Разархивируем содержимое дистрибутива в wwwroot IIS-сервера и даём права УЗ IIS_IUSERS на модификацию каталога App_Data:

Запускаем IIS Manager и конвертируем в приложение BonoboGitServer:

Если всё пошло так как надо справа в IIS Manager в Action жмём Browse: *:80(http) и попадаем (если вы не изменили имя и порт) на localhost/BonoboGitServer:

Логин и пароль для первого входа admin/admin. У сервера не так много настроек (во всяком случае через web-интерфейс), можно например поменять язык интерфейса:

и создать новых пользователей, например developer и jenkins. Под первым мы будем работать сами, второй нужен будущему серверу сборок.

Создадим новый репозиторий и дадим права на него разработчику и сборщику (УЗ jenkins, на скрине нет, но он там должен быть если делать всё по порядку. )

Можно создать какой-нибудь проект в Android Studio указать в качестве удалённой ветки адрес нашего репозитория. Всю эту локальную часть я пропущу.

Jenkins

Jenkins устанавливается из msi и особо ни о чём не спрашивает, в конце установки автоматически открывается страничка с адресом где нам нужно скопировать из файла initialAdminPassword и вставить пароль:

В дальнейшем пароль УЗ admin тоже можно поменять.

Пришла пора установить необходимые плагины и настроить сервер. Переходим в Manage Jenkins — Manage Plugins — Avaliable и отмечаем:

После перезапуска Jenkins необходимо перейти в раздел Manage Jenkins — Configure System и прописать путь к Android SDK в двух местах:

И в самом низу этой же странички в Android SDK root:

Если данного параметра не появилось что-то не то с Android Emulator Plugin, возможно он просто не установился.

Далее перейти на страничку конфигурации Manage Jenkins — Global Tool Configuration проверить и при необходимости указать пути к компонентам:

Git можно не трогать, если в переменной path указан путь к исполняемому файлу git и он доступен в командной строке то и Jenkins сможет его использовать:

А Gradle пусть скачается автоматически. В принципе такой же фокус можно было бы сделать с JDK но при установке Android SDK требует зарегистрированной в системе JDK, а куда Jenkins скачивает JDK я не раскопал.

Создание задачи на автоматическую сборку

В основном боковом меню Jenkins жмём New Item, придумываем название задачи с типом «Freestyle project» и жмём ок, попадаем в конфигурацию задачи. Не забываем поставить галочку Discard old builds а то наш сервер вскоре заполнится успешными билдами всех версий:

В разделе Source Code Management указываем URL репозитория git нашего проекта. Забегая вперёд, не заводим и не подставляем никакие учётные данные для доступа к репозиторию:

Будем собирать ветку master. Также можно настроить автоматическую сборку, в частности опрос репозитория ежеминутно и старт сборки в случае обнаружения новых коммитов. Отмечаем Poll SCM и пишем * * * * *:

В разделе build нажимаем Add build step и настраиваем сборку Gradle. Gradle version должен быть доступен тот, что мы указали в Global Tools Configurations. Пишем простой Task — «clean build». Это задачи, доступные нам в gradlew.bat tasks в корне проекта. Вы можете вызывать тут и другие задачи сборщика, в т.ч. с ключами.

Также добавляем одно Post-build Action — будем сохранять наши APK-шники — приложения Android. Так и пишем:

Сборка

Сохраняем и запускам сборку и видим что-то подобное, висим 10 минут и не можем достучатся в репозиторий:

Командная строка запускается от имени УЗ сеанса, Jenkins от имени System и ничего об этом не знает, в хранилище Credential Manager похоже что тоже не случится. Т.е. это не поможет:

Дополнительный поиск по сети дал несколько советов:

Авторизация git

Для этого нам потребуется PsExec.exe из набора утилит PsTools. С её помощью мы можем запустить cmd.exe из под System. Запускаем cmd.exe с повышенными правами и выполняем:

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

С помощью которых Jenkins сможет обращаться к данному репозиторию. Это та самая УЗ, которую мы создавали при настройках Bonobo Git Server наряду с developer’ом. Если в дальнейшем потребуется изменить данные учётные данные придётся пройти процедуру повторно.

Нехватка компонентов и акцептов лицензий на компоненты Android SDK

Может случится так что в SDK будут отсутствовать какие-нибудь модули и консоль сборки выдавать сообщения подобного характера:

В таком случае вам надо запустить с повышенными правами SDK Manager и установить недостающие компоненты:

Всё, после всех шаманств сборка прошла успешно!

Можете разводить команду Android-разработчиков.

Источник

Учимся разворачивать микросервисы. Часть 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 — очень гибкая система, позволяющая реализовывать процесс непрерывной интеграции и развертывания любой сложности. В этой статье мы только коснулись этого инструмента, создав простенький пайплайн для микросервисов нашего проекта. В будущем этот пайплайн можно значительно дорабатывать и улучшать, например, добавив уведомления, дополнительные шаги, веб-хуки и многое-многое другое.

Источник