Улучшаем качество разработки с помощью Jenkins

Введение

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

Jenkins – инструмент, который предназначен для улучшения жизненного цикла разрабатываемого продукта. Этот инструмент реализует требования DevOps методологии CI/CD – непрерывная интеграция и непрерывная доставка. Jenkins сводит к минимуму ошибки при интеграции, ускоряет и проводит необходимые операции для повышения качества релиза.

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

Jenkins и CI/CD

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

Понятия CI/CD обозначаются так – CI (Continuous Integration) реализует процесс проверки и сборки кода, а CD (Continuous Deployment) доставку обновлений на рабочий сервер проекта.

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

Процесс CI/CD

Эту методологию стоит внедрять на многие проекты, однако вопрос автоматизации спорный, когда:

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

Многие продукты, в числе которых GitLab, Docker, Travis-CI, Circle-CI, TeamCity уже подготовлены для работы с CI/CD, но не все используют обе практики. К тому же каждый имеет свои особенности и ограничения. Поэтому стоит выбирать инструмент, исходя из потребностей.

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

Логотип Jenkins

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

Основные возможности:

• Автономность работы и независимость системы, благодаря размещению на выделенный сервер.
• Многочисленность доступных и бесплатных плагинов с официального сайта. С их помощью можно расширить возможности сервиса и произвести интеграцию с другими системами. API сервиса позволяет устанавливать как стабильные версии плагинов, так и устанавливать старые. Также можно создать свой плагин и загрузить его в систему.
• Сервис предоставляет широкий функционал по настройке условий сборки и деплоя проекта. Допустим, перед выгрузкой изменений можно сделать резервную копию, а после переноса – запустить автотесты.
• В практиках DevOps часто рассматривается использование трех серверов разработки проекта Dev-Stage-Prod. Благодаря Jenkins можно сконструировать надежную цепочку разработки, которая обеспечит безопасность развертывания релизов на Prod сервере.
• Собственный REST API – с его помощью можно управлять и мониторить выполнение задач .

По сути Jenkins – это мост между кодовой базой и prod-сервером. Руководители проектов используют его для проверки ошибок, контроля качества кода разработчиков, мониторинга процессов интеграции и доставки обновлений.

Когда нужно использовать CI/CD

Если вы читаете эту статью, то, вероятно, уже задумываетесь о повышении качества кодовой базы и упрощении ее интеграции по методологии CI/CD. Поэтому мы создали краткий свод пунктов, которые стоит обдумать перед внедрением методологии в проект.

Основные моменты:

• После релиза часто происходят ошибки, необходимо автоматически запускать тестирование проекта.
• Сложный функционал системы, последствия ошибок сложно устранить.
• Проект требует безотказной работы и недопустимости возникновения ошибок.
• Команда состоит из 3 и более человек, сложно контролировать изменения и отлавливать ошибки.
• Часто выпускаются обновления.
• Релиз занимает много времени.
• Используются другие сервисы для контроля качества, постобработки проекта. .

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

Преимущества Jenkins

Jenkins – бесплатный сервис, который знаменит большим набором плагинов. Есть множество и других инструментов, которые в чем-то превосходят Jenkins. Большинство из них являются платными (TeamCity, Bamboo, Travis и т.п.) и предоставляют больше инструментов, но они могут быть излишни для вашего проекта.

Преимущества Jenkins:

• Бесплатный сервис.
• Обширная библиотека плагинов.
• Простая интеграция с любой внешней программой для разработки.
• Наличие поддержки.
• Подходит для больших проектов.

Если вы ранее не пользовались инструментами CI/CD, то рекомендуем воспользоваться именно Jenkins. Он практически универсален для любого проекта и подойдет для быстрого старта.

Установка Jenkins

Рассмотрим установку Jenkins на системе Centos 7 при помощи Docker.

Установка docker

Если docker не установлен, выполняем установку.

Скачиваем файл репозитория:

Запускаем установку:

Запускаем Docker и настраиваем автозапуск:

Установка контейнера

Загружаем контейнеры для Jenkins:

Запускаем контейнер:

На экране мы должны увидеть код для установки.

Код для подтверждения установки

Копируем его, открываем в браузере страницу https://server_name:8080 и продолжаем установку через веб интерфейс.

Установка в веб-версии

На первом шаге необходимо ввести пароль для установки.

Подтверждение пароля администратора

Следующим шагом будет предложено установить рекомендованные плагины, либо выбрать те, которые необходимы. Для реализации нашего примера – устанавливаем рекомендованные.

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

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

Завершение установки

Теперь в консоли прервите работу контейнера комбинацией Ctrl+С и запустите его в фоновом режиме:

Теперь Jenkins готов к настройке и работе

Главная страница

Пример настройки задачи

В этом примере мы решим простую задачу: у нас есть приватный GitHub репозиторий и одностраничный сайт. Необходимо настроить автодеплой изменений из ветки master на сайт.

Схема работы задачи по автодеплою

В Jenkins для этого создается и настраивается задание, которое будет ходить в GitHub, скачивать репозиторий в систему и затем отправлять обновление на сайт.

Для этого необходимо сперва:

• Установить плагин Publisher over SSH.
• Настроить доступ к серверу для размещения обновлений.
• Настроить доступ в git репозиторию для опроса обновлений.
• Настроить webhook в git.

Установка Publisher over SSH

Для установки плагина переходим в настройки Настроить Jenkins / Управление плагинами. Переходим во вкладку доступные и устанавливаем плагин Publisher over SSH.

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

Настройка доступа SSH доступа к серверу

После установки необходимо добавить доступы к серверу, на который будут отправляться обновления. Для этого переходим в Настройки Jenkins / Конфигурация Системы / Publisher over SSH и настраиваем доступ по SSH ключу.

Настройка приватного ключа

Настройка доступов к сайту

В Remote Directory мы указали папку, которая будет открываться после авторизации. Эта папка – корень нашего сайта. Туда будут размещаться файлы из Git.

Настройка доступа к репозиторию

Для доступа к приватному репозиторию создаем SSH ключи и добавляем публичный ключ в GitHub.

Добавление публичного ключа в Git для настройки доступа

Теперь нужно настроить доступ в Git со стороны Jenkins. Поэтому переходим в Настройки Jenkins / Manage Credentials.

Нажимаем Add Credentials и заполняем настройки к репозиторию:

• Выбираем SSH Username with private key.
• Вводим ID (необязательно).
• Заполняем Username (ваш пользователь GitHub).
• В поле Private Key вводим приватный ключ.

Настройка доступов к Git

Настройка webhook в git

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

Для этого указываем URL вебхука: http://server_name:8080/github-webhook/. Остальные настройки оставляем по умолчанию.

Настройка webhook

Теперь, когда доступы настроены, можно приступить к созданию задачи (Job). Мы создадим задание, которое будет запускаться по наличию обновлений в репозитории.

Создание и настройка задачи

На главной странице жмем Создать Item. Затем вводим название и выбираем Создать задачу со свободной конфигурацией.

Создание задачи

В пункте Управление исходным кодом ставим галочку Git и настраиваем доступ. Также указываем что изменения будут скачиваться из ветки master.

Настройка подключения к репозиторию

В пункте Триггеры сборки указываем GitHub hook trigger for GITScm polling. Это значит, что когда в GitHub появится новый коммит, задача запустится автоматически.

Настройка триггера

Далее в пункте Послесборочные операции указываем куда отправлять файлы после скачивания из GitHub. Для этого выбираем операцию Send build artifacts over SSH.

Затем указываем ранее настроенный нами SSH сервер и в поле Source files указываем какие файлы из репозитория переносить. А в Exec command указываем команду, которая будет выполняться после переноса, например, можно указать service httpd restart.

Настройка доставки обновлений

Готово. Сохраняем задачу и смотрим на главном экране результат обработки.

Монитор выполнения задачи

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

Заключение

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

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