Что такое Jenkins?

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

Что такое Jenkins?

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

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

Jenkins достигает непрерывной интеграции с помощью плагинов. Плагины позволяют интегрировать различные этапы DevOps. Если вы хотите интегрировать определенный инструмент, вам нужно установить плагины для этого инструмента. Например: Git, проект Maven 2, Amazon EC2, HTML-издатель и т. д.

На изображении ниже показано, что Jenkins интегрирует различные этапы DevOps:

Преимущества Jenkins включают в себя:

Это инструмент с открытым исходным кодом с большой поддержкой сообщества.
Его легко установить.
Он имеет более 1000 плагинов для облегчения вашей работы. Если плагин не существует, вы можете написать свой плагин и поделиться с сообществом.
Jenkins бесплатен.
Он построен на Java и, следовательно, работает на всех основных платформах.

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

Ключевые моменты Jenkins.

Ниже приведены некоторые факты о Jenkins, которые делают его лучше, чем любые другие инструменты непрерывной интеграции:

Выбор многих: Jenkins широко распространен, имеет более 147 000 активных установок и более 1 миллиона пользователей по всему миру.
Плагины: Jenkins связан более чем с 1000 плагинами, которые позволяют интегрировать его с большинством инструментов разработки, тестирования и развертывания.

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

Что такое непрерывная интеграция?

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

Каждый коммит, сделанный в хранилище, затем создается. Это позволяет командам обнаруживать проблемы на ранней стадии. Помимо этого, в зависимости от инструмента Continuous Integration, есть несколько других функций, таких как развертывание приложения сборки на тестовом сервере, предоставление заинтересованным группам результатов сборки и тестирования и т. д.

Чтобы понять важность непрерывной интеграции, давайте взглянем на один из вариантов использования.

Я уверен, что вы все пользовались телефонами Nokia в какой-то момент вашей жизни. В проекте Nokia по разработке программного продукта был процесс под названием Nightly builds., Ночные сборки можно рассматривать как предшественника непрерывной интеграции. Это означает, что каждую ночь автоматизированная система извлекает код, добавленный в общий репозиторий в течение дня, и создает этот код. Идея очень похожа на Continuous Integration, но, так как код, который создавался ночью, был довольно большим, поиск и исправление ошибок было настоящей болью. В связи с этим Nokia приняла технологию непрерывной интеграции (CI). В результате каждый коммит, сделанный с исходным кодом в репозитории, был собран.

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

Сейчас самое время понять, как в Jenkins работает непрерывная интеграция.

Непрерывная интеграция с Jenkins

Давайте представим сценарий, в котором полный исходный код приложения был собран, а затем развернут на тестовом сервере для тестирования. Это звучит как идеальный способ разработки программного обеспечения, но этот процесс имеет много недостатков. Я постараюсь объяснить их один за другим:

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

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

Сначала я объясню вам общую схему непрерывной интеграции с Jenkins, чтобы она стала понятной, как Jenkins преодолевает вышеуказанные недостатки:

Сначала разработчик фиксирует код в хранилище исходного кода. Тем временем сервер Jenkins регулярно проверяет наличие изменений в хранилище.
Вскоре после того, как происходит фиксация, сервер Jenkins обнаруживает изменения, произошедшие в репозитории исходного кода. Дженкинс потянет эти изменения и начнет готовить новую сборку.
Если сборка не удалась, соответствующая команда будет уведомлена.
Если сборка прошла успешно, Jenkins развертывает встроенный тестовый сервер.
После тестирования Jenkins генерирует обратную связь и затем уведомляет разработчиков о результатах сборки и тестирования.
Он продолжит проверять хранилище исходного кода на предмет изменений, внесенных в исходный код, и весь процесс будет повторяться.

Теперь вы знаете, как Jenkins преодолевает традиционные недостатки SDLC. В таблице ниже показано сравнение между «До и после Jenkins».

До Jenkins	После Jenkins
Весь исходный код был построен и затем протестирован. Поиск и исправление ошибок в случае сбоя сборки и тестирования было трудным и занимало много времени, что, в свою очередь, замедляло процесс доставки программного обеспечения.	Каждый коммит, сделанный в исходном коде, создается и тестируется. Таким образом, вместо проверки всего исходного кода разработчикам нужно сосредоточиться только на конкретном коммите. Это приводит к частым выпускам нового программного обеспечения.
Разработчики должны ждать результатов испытаний	Разработчики знают результат тестирования каждого коммита, сделанного в исходном коде на ходу.
Весь процесс ручной	Вам нужно только зафиксировать изменения в исходном коде, и Jenkins автоматизирует остальную часть процесса для вас.

О том что такое CI, вы можете познакомиться здесь.

Здесь содержится инструкция по установке jenkins без контейнера.

О том как установить Docker в CentOS8/RHEL8, мы говорили тут.