
Непрерывная интеграция является наиболее важной частью 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, мы говорили тут.