Статьи

Построение конвейера непрерывной доставки с использованием Jenkins

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

  • Что такое непрерывная доставка?
  • Типы тестирования программного обеспечения
  • Разница между непрерывной интеграцией, доставкой и развертыванием
  • Какая необходимость в непрерывной доставке?
  • Практическое использование Jenkins и Tomcat

Давайте быстро поймем, как работает Непрерывная доставка.

Что такое непрерывная доставка?

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

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

  • Скрипты автоматической сборки будут обнаруживать изменения в управлении исходным кодом (SCM), такие как Git.
  • Как только изменение обнаружено, исходный код будет развернут на выделенном сервере сборки, чтобы убедиться, что сборка не дает сбоев, и все тестовые классы и интеграционные тесты работают нормально.
  • Затем приложение сборки развертывается на тестовых серверах (подготовительных серверах) для пользовательского приемочного теста (UAT).
  • Наконец, приложение вручную развертывается на производственных серверах для выпуска.

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

Типы тестирования программного обеспечения

Вообще говоря, есть два типа тестирования:

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

Есть два типа тестирования, которые подпадают под эту категорию.

  • Юнит-тестирование: это тестирование отдельного юнита или группы связанных юнитов. Программист часто выполняет тестирование того, что реализованная им единица выдает ожидаемый результат при заданном входе.
  • Интеграционное тестирование. Это тип тестирования, при котором группа компонентов объединяется для получения выходных данных. Кроме того, взаимодействие между программным и аппаратным обеспечением проверяется на наличие связи между программными и аппаратными компонентами. Он может подпадать под тестирование белого ящика и черного ящика.

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

  • Функциональное / приемочное тестирование: оно обеспечивает работу указанной функциональности, требуемой в системных требованиях. Это делается для того, чтобы убедиться, что поставляемый продукт соответствует требованиям и работает так, как ожидал клиент.
  • Системное тестирование: оно гарантирует, что, помещая программное обеспечение в различные среды (например, операционные системы), оно все еще работает.
  • Стресс-тестирование: оценивает, как система ведет себя в неблагоприятных условиях.
  • Бета-тестирование: оно проводится конечными пользователями, командой разработчиков или публично выпускает полную предварительную версию продукта, известную как бета-версия. Целью бета-тестирования является выявление непредвиденных ошибок.

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

Различия между непрерывной интеграцией, доставкой и развертыванием

Визуальный контент достигает мозга человека быстрее и понятнее, чем текстовая информация. Итак, я собираюсь начать с диаграммы, которая четко объясняет разницу:

В Continuous Integration каждый коммит кода создается и тестируется, но не находится в состоянии, подлежащем освобождению. Я имею в виду, что приложение для сборки не развертывается автоматически на тестовых серверах для его проверки с использованием различных типов тестирования Blackbox, таких как — User Acceptance Testing (UAT).

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

Непрерывное развертывание — это следующий шаг после непрерывной доставки, когда вы не просто создаете развертываемый пакет, но фактически развертываете его в автоматическом режиме.

Позвольте мне суммировать различия, используя таблицу:

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

Но вопрос в том, достаточно ли непрерывной интеграции.

Почему нам нужна постоянная доставка

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

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

Что может быть очевидной причиной неудачи?

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

Один проницательный разработчик выбрал разумный подход

Затем один из старших разработчиков попробовал приложение на своей машине разработки. Это тоже не сработало.

Он возвращался к более ранним и более ранним версиям, пока не обнаружил, что система перестала работать три недели назад. Крошечная, неясная ошибка помешала правильному запуску системы. Тем не менее, проект имел хорошее покрытие модульных тестов. Несмотря на это, 80 разработчиков, которые обычно запускали тесты, а не само приложение, не видели проблемы в течение трех недель.

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

Позвольте мне обобщить извлеченные уроки, рассмотрев вышеуказанные проблемы:

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

Решение — конвейер непрерывной доставки (автоматический приемочный тест)

Они взяли Continuous Integration (Continuous Delivery) к следующему шагу и представили пару простых автоматизированных приемочных тестов, которые доказали, что приложение работало и могло выполнять свою основную функцию. Большинство тестов, выполняемых на этапе приемочных испытаний, являются функциональными приемочными испытаниями.

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

Достаточно теории — сейчас я покажу вам, как создать конвейер непрерывной доставки с использованием Jenkins.

Трубопровод непрерывной доставки с использованием Jenkins

Здесь я буду использовать Jenkins для создания конвейера непрерывной доставки, который будет включать следующие задачи:

Шаги, вовлеченные в демонстрацию

  • Извлечение кода из GitHub
  • Компиляция исходного кода
  • Модульное тестирование и генерация отчетов о тестировании JUnit
  • Упаковка приложения в файл WAR и его развертывание на сервере Tomcat.

Шаг 1 — Компиляция исходного кода

Давайте начнем с создания фристайл-проекта в Дженкинсе. Посмотрите на скриншот ниже:

Дайте название своему проекту и выберите Freestyle Project:

Когда вы прокрутите страницу вниз, вы найдете опцию добавления репозитория исходного кода, выберите «git» и добавьте URL репозитория; в этом репозитории есть штраф pom.xml, который мы будем использовать для создания нашего проекта. Посмотрите на скриншот ниже:

Теперь мы добавим триггер сборки. Выберите опцию опроса SCM, в основном мы настроим Jenkins для опроса репозитория GitHub каждые 5 минут на предмет изменений в коде. Посмотрите на скриншот ниже:

Прежде чем продолжить, позвольте мне дать вам небольшое введение в цикл сборки Maven.

Каждый из жизненных циклов сборки определяется различным списком этапов сборки, причем этап сборки представляет собой этап в жизненном цикле.

Ниже приведен список этапов сборки:

  • validate — подтвердить правильность проекта и получить всю необходимую информацию
  • compile — скомпилировать исходный код проекта
  • test — протестируйте скомпилированный исходный код, используя подходящую среду модульного тестирования. Эти тесты не должны требовать, чтобы код был упакован или развернут
  • package — взять скомпилированный код и упаковать его в распространяемый формат, такой как JAR.
  • проверить — выполнить любые проверки результатов интеграционных тестов, чтобы убедиться в соответствии критериям качества
  • установить — установить пакет в локальный репозиторий, для локального использования в качестве зависимости в других проектах
  • deploy — выполняется в среде сборки, копирует окончательный пакет в удаленный репозиторий для совместного использования с другими разработчиками и проектами.

Я могу запустить приведенную ниже команду для компиляции исходного кода, модульного тестирования и даже упаковки приложения в файл war:

mvn clean package

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

Итак, начнем с компиляции исходного кода. На вкладке «Построение» нажмите кнопку вызова целей maven верхнего уровня и введите следующую команду:

compile

Посмотрите на скриншот ниже:

Это извлечет исходный код из репозитория GitHub, а также скомпилирует его (фаза компиляции Maven).

Нажмите Сохранить и запустите проект.

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

Теперь мы создадим еще один Freestyle Project для юнит-тестирования.

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

Теперь на вкладке «Построить триггер» нажмите «Построить после сборки других проектов». Там введите имя предыдущего проекта, где мы компилируем исходный код, и вы можете выбрать любой из следующих вариантов:

  • Триггер только если стабильная сборка
  • Триггер, даже если сборка нестабильна
  • Триггер, даже если сборка не удалась

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

На вкладке «Построение» нажмите на вызов объектов верхнего уровня maven и используйте команду ниже:

test

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

Стандарт де-факто для отчетов о тестировании в мире Java — это формат XML, используемый JUnit. Этот формат также используется многими другими инструментами тестирования Java, такими как TestNG, Spock и Easyb. Jenkins понимает этот формат, поэтому, если ваша сборка выдает результаты теста JUnit XML, Jenkins может с течением времени генерировать хорошие графические отчеты о тестировании и статистику результатов теста, а также позволяет просматривать подробности любых неудачных тестов. Дженкинс также отслеживает продолжительность выполнения ваших тестов, как в глобальном масштабе, так и для каждого теста, — это может пригодиться, если вам необходимо отследить проблемы с производительностью.

Следующее, что нам нужно сделать, это заставить Дженкинса следить за нашими юнит-тестами.

Перейдите в раздел Действия после сборки и установите флажок «Опубликовать отчет о результатах тестирования JUnit». Когда Maven запускает модульные тесты в проекте, он автоматически генерирует отчеты о тестах XML в каталоге, называемом surefire-reports. Введите «** / target / surefire-reports / *. Xml» в поле «XML отчета о тестировании». Две звездочки в начале пути («**») — это лучший способ сделать конфигурацию более надежной: они позволяют Jenkins найти целевой каталог независимо от того, как мы настроили Jenkins для проверки исходного кода.

**/target/surefire-reports/*.xml

Снова сохраните его и нажмите «Построить сейчас».

Теперь отчет JUnit записывается в / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-поведения.

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

Шаг 3 — Создание файла WAR и развертывание на сервере Tomcat

Теперь следующий шаг — упаковать наше приложение в файл WAR и развернуть его на сервере Tomcat для проверки приемлемости пользователя.

Создайте еще один проект в стиле фристайл и добавьте URL-адрес хранилища исходного кода.

Затем на вкладке триггера сборки выберите сборку при сборке других проектов, рассмотрите скриншот ниже:

Как правило, после тестового задания этап развертывания запускается автоматически.

На вкладке сборки выберите сценарий оболочки. Введите следующую команду, чтобы упаковать приложение в WAR-файл:

mvn package

Следующим шагом является развертывание этого файла WAR на сервере Tomcat. На вкладке «Действия после сборки» выберите развертывание war / ear в контейнере. Здесь укажите путь к файлу войны и укажите контекстный путь. Посмотрите на скриншот ниже:

Выберите учетные данные Tomcat и обратите внимание на скриншот выше. Также вам необходимо указать URL вашего сервера Tomcat.

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

Нажмите на Систему и выберите глобальные учетные данные.

Затем вы найдете вариант, чтобы добавить учетные данные. Нажмите на него и добавьте учетные данные.

Добавьте учетные данные Tomcat, рассмотрите скриншот ниже.

Нажмите на ОК.

Теперь в вашей конфигурации проекта добавьте учетные данные tomcat, которые вы вставили на предыдущем шаге.

Нажмите «Сохранить» и выберите «Создать сейчас».

Перейдите по URL вашего tomcat с контекстным путем, в моем случае это http: // localhost: 8081. Теперь добавьте контекстный путь в конце, рассмотрите скриншот ниже:

Link - http://localhost:8081/gof

Я надеюсь, что вы поняли значение пути контекста.

Теперь, чтобы создать представление конвейера, рассмотрите скриншот ниже:

Нажмите на значок плюс, чтобы создать новый вид.

Настройте конвейер так, как вы хотите:

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

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

Теперь мы можем постоянно развертывать наше приложение на тестовом сервере для пользовательских приемочных тестов (UAT).