Учебное пособие по непрерывной доставке - построение конвейера непрерывной доставки с помощью Jenkins

Непрерывная доставка:

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

пойти отсортировать c ++

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

Позвольте нам быстро понять, как работает непрерывная доставка.

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

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

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

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

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

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

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

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

Тестирование белого ящика:

Под эту категорию подпадают два типа тестирования.

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

Тестирование черного ящика:

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

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

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

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

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

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

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

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

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

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

Узнайте, как создавать конвейеры CI / CD с помощью Jenkins On Cloud

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

Зачем нужна непрерывная доставка?

Давайте разберемся в этом на примере.

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

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

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

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

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

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

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

Постановка задачи:

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

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

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

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

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

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

Хватит теории, теперь я покажу вам, как создать конвейер непрерывной доставки с помощью Jenkins.

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

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

Этапы демонстрации:

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

Предварительные условия:

• Машина CentOS 7
• Дженкинс 2.121.1
• Докер
• Tomcat 7

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

Давайте начнем с создания проекта Freestyle в Jenkins. Рассмотрим снимок экрана ниже:

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

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

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

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

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

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

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

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

mvn чистый пакет

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

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

компилировать

Рассмотрим снимок экрана ниже:

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

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

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

Шаг - 2 Модульное тестирование:

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

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

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

• Запускается, только если сборка стабильна
• Сработать, даже если сборка нестабильна
• Запуск даже при сбое сборки

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

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

тестовое задание

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

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

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

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

** / цель / surefire-reports / *. xml

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

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

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

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

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

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

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

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

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

mvn пакет

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

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

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

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

Затем вы найдете возможность добавить учетные данные. Щелкните по нему и добавьте учетные данные.

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

Щелкните ОК.

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

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

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

Ссылка - http: // localhost: 8081 / gof

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

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

Щелкните значок плюса, чтобы создать новое представление.

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

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

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

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

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

Для создания конвейеров CI / CD вам необходимо овладеть широким спектром навыков Овладейте необходимыми навыками DevOps прямо сейчас