Заключительные этапы нашего конвейера развертывания подразумевают развертывание нашего продукта (в случае войны JEE или войны ) в производственной среде, для UAT или в производственной системе после выпуска продукта.
В этой статье мы увидим, как мы можем настроить Jenkins для правильного управления развертыванием Java Enterprise Application.
Первое, что нужно сделать, это создать приложение, в данном случае очень простое веб-приложение на Java (на самом деле это всего лишь один jsp, который печатает сообщение Hello World !! ) и преобразовать его в файл war ( bar.war ), когда пакет цель выполнена.
Затем нам нужно создать задание Jenkins (называемое bar-web ), которое отвечает за компиляцию и запуск модульных тестов.
После этого задания появятся другие задания, такие как запуск интеграционных тестов, запуск дополнительных тестов, статический анализ кода (он же качество кода) или загрузка артефактов в репозиторий артефактов, но здесь они не будут показаны.
И, наконец, последние шаги, которые подразумевают развертывание предыдущего сгенерированного кода в промежуточной среде (например, для запуска пользовательских приемочных тестов ) и после того, как ключевые пользователи дали согласие на развертывание в производственной среде.
Итак, давайте посмотрим, как создать эти последние шаги в Jenkins . Обратите внимание, что двоичный файл, созданный на предыдущих шагах (в нашем случае bar-web ), должен использоваться на всех этих шагах. Это объясняется двумя причинами: первая заключается в том, что конвейер развертывания должен выполняться максимально быстро, и, очевидно, компиляция на каждом этапе кода не лучший способ его получить, а вторая — то, что каждый раз, когда вы компилируете исходные коды , увеличивает вероятность того, что не будут компилироваться источники предыдущих шагов. Для достижения этой цели мы можем следовать двум стратегиям, первая из которых — загрузка двоичных файлов в хранилище артефактов (например, Nexus или Artifactory ) и получение оттуда в каждой работе. Второй использует плагин Jenkins для копирования артефактов, чтобы получить двоичные файлы, сгенерированные предыдущим шагом.
Давайте посмотрим, как настроить Jenkins для первого подхода.
При использовании подхода к хранилищу артефактов требуется загрузить версию, которую мы хотим развернуть, из хранилища, а затем развернуть ее во внешней среде; в нашем случае развертывание на веб-сервере. Все эти шаги выполняются с помощью maven-cargo-plugin .
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
<build> <plugins> <plugin> <groupId>org.codehaus.cargo<groupId> <artifactId>cargo-maven2-plugin<artifactId> <version>1.0<version> <!-- Container configuration --> <container> <containerId>tomcat6x<containerId> <type>remote<type> <container> <configuration> <type>runtime<type> <properties> <cargo.remote.username>admin<cargo.remote.username> <cargo.remote.password><cargo.remote.password> <cargo.tomcat.manager.url>http:localhost:8888manager<cargo.tomcat.manager.url> <properties> <configuration> <deployer> <deployables> <deployable> <groupId>com.lordofthejars.bar<groupId> <artifactId>bar-web<artifactId> <type>war<type> <deployable> <deployables> <deployer> <plugin> <plugins><build><dependencies> <dependency> <groupId>com.lordofthejars.bar<groupId> <artifactId>bar-web<artifactId> <type>war<type> <version>${target.version}<version> <dependency><dependencies> |
Тогда нам нужно только создать новое задание Jenkins с именем bar-to-staging, которое будет запускать cargo: повторно развернуть цель Maven , а плагин Cargo будет отвечать за развертывание bar-web на веб-сервере.
Этот подход имеет одно преимущество и один недостаток. Основным преимуществом является то, что вы не связаны с Jenkins , вы можете использовать только Maven или любой другой CI , поддерживающий Maven . Основным недостатком является то, что используется репозиторий артефактов, и это планирует новую проблему, конвейер развертывания включает в себя много шагов, и между этими шагами (обычно если вы создаете версию моментального снимка) новый артефакт может быть загружен в репозиторий артефактов с той же версией. и используйте его в середине выполнения конвейера. Конечно, этого сценария можно избежать, управляя разрешениями в хранилище артефактов.
Другой подход — использовать плагин Jenkins , называемый copy-artifact-plugin . В этом случае Jenkins выступает в качестве хранилища артефактов, поэтому артефакты, созданные на предыдущем шаге, используются на следующем шаге без использования какого-либо внешнего хранилища. Используя этот подход, мы не можем использовать maven-cargo-plugin , но мы можем использовать deploy-jenkins-plugin в сочетании с copy-artifacts-plugin .
Итак, давайте посмотрим, как реализовать этот подход.
Прежде всего, создайте задание сборки Jenkins ( bar-web ), которое создает файл войны . Обратите внимание, что определены два действия после сборки , во-первых, это Архивация артефактов , которая используется для хранения сгенерированных файлов, чтобы плагин копирования артефактов мог копировать их в другое рабочее пространство. Другой — это Построение других проектов , которое в этом случае вызывает задание, которое отвечает за развертывание файла войны в промежуточный каталог ( панель развертывания в промежуточный ).
Следующее, что нужно сделать, это создать сборку с развертыванием в промежуточное задание, основным действием которого является развертывание файла war, сгенерированного предыдущим заданием сборки, на сервер Tomcat .
Для этого второго задания по сборке вы должны настроить плагин «Копировать артефакты» для копирования ранее созданных файлов в текущее рабочее пространство, поэтому в разделе «Сборка» в разделе « Копирование артефактов из другого раздела проекта » мы задаем, из какого задания сборки мы хотим скопировать артефакт (в нашем случае bar-web ) и какие артефакты мы хотим скопировать. И, наконец, в разделе «Действия после сборки» мы должны указать , какой файл следует развернуть в Tomcat ( bar.web ), запомнить, что этот файл скомпилирован и упакован предыдущими заданиями сборки, и, наконец, установить параметры Tomcat . И конвейер выполнения выглядит примерно так:
Обратите внимание, что добавлено третье задание на сборку , которое развертывает файл war на рабочий сервер.
Этот второй подход является противоположностью первого подхода, вы можете быть уверены, что артефакт, использованный на предыдущем этапе конвейера, будет использоваться на всех этапах, но вы привязаны к Дженкинсу / Хадсону .
Таким образом, если вы собираетесь создать политику в своем хранилище артефактов, чтобы только конвейерный конвейер мог загружать артефакты в хранилище, первый подход лучше, но если вы не используете внешний репозиторий артефактов (вы используете Jenkins как есть), тогда второй подход — это Лучше всего убедиться, что упакованный артефакт на предыдущих шагах не изменяется параллельными шагами.
После развертывания файла на сервере, приемочные тесты или тесты UAT могут быть выполнены без каких-либо проблем.
Я бы хотел, чтобы теперь мы могли безопасно и качественно решить последние этапы процесса развертывания.
Ссылка: Развертывание артефактов JEE с Дженкинсом от нашего партнера по JCG Алекса Сото в блоге One Jar To Rule All .