1. Обзор
В этом руководстве мы рассмотрим процесс непрерывной интеграции/непрерывного развертывания (CI/CD) и реализуем его основные части.
Мы создадим простое приложение Spring Boot, а затем отправим его в общий репозиторий Git. После этого мы построим его с помощью службы интеграции зданий, создадим образ Docker и отправим его в репозиторий Docker.
В конце концов, мы автоматически развернем ваше приложение в службе PaaS (Heroku).
2. Контроль версий
Важнейшей частью CI/CD является система контроля версий для управления нашим кодом. Кроме того, нам нужна служба хостинга репозитория, с которой будут связаны наши шаги по сборке и развертыванию.
Давайте выберем Git в качестве VCS и GitHub в качестве нашего поставщика репозиториев, поскольку они наиболее популярны на данный момент и бесплатны в использовании.
Во-первых, нам нужно создать учетную запись на GitHub.
Кроме того, мы должны создать репозиторий Git . Давайте назовем его baeldung-ci-cd-process . Кроме того, давайте выберем публичный репозиторий, так как он позволит нам получить доступ к другим сервисам бесплатно. Наконец, давайте инициализируем наш репозиторий с помощью README.md .
Теперь, когда наш репозиторий создан, мы должны клонировать наш проект локально. Для этого давайте выполним эту команду на вашем локальном компьютере:
git clone https://github.com/$USERNAME/baeldung-ci-cd-process.git
Это инициализирует наш проект в каталоге, в котором мы выполнили команду. На данный момент он должен содержать только README.md файл.
3. Создание приложения
В этом разделе мы создадим простое приложение Spring Boot, которое будет участвовать в этом процессе. Мы также будем использовать Maven в качестве инструмента сборки.
Во-первых, давайте инициализируем наш проект в каталоге, в котором мы клонировали репозиторий управления версиями.
Например, мы можем сделать это с помощью инициализатора Spring , добавив модули web и actuator .
3.1. Создание Приложения вручную
Или мы можем добавить зависимости spring-boot-starter-web и |/spring-boot-starter-actuator вручную:
org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-starter-actuator
Во-первых, необходимо ввести конечную точку REST, а во-вторых, конечную точку проверки работоспособности.
Кроме того, давайте добавим плагин, который позволит нам запускать наше приложение:
org.springframework.boot spring-boot-maven-plugin
И, наконец, давайте добавим основной класс Spring Boot:
@SpringBootApplication
public class CiCdApplication {
public static void main(String[] args) {
SpringApplication.run(CiCdApplication.class, args);
}
}3.2. Толчок
Независимо от того, используете ли вы Spring Initializr или вручную создаете проект, теперь мы готовы зафиксировать и перенести наши изменения в наш репозиторий.
Давайте сделаем это с помощью следующих команд:
git add . git commit -m 'Initialize application' git push
Теперь мы можем проверить, существуют ли наши изменения в репозитории.
4. Автоматизация сборки
Другая часть процесса CI/CD-это служба, которая будет создавать и тестировать наш код.
Мы будем использовать Travis CI здесь, но любая строительная служба также будет работать.
4.1. Обертка Maven
Давайте начнем с добавления обертки Maven в наше приложение. Если мы использовали Spring Initializr, мы можем пропустить эту часть, так как она включена по умолчанию.
В каталоге приложений давайте сделаем:
mvn -N io.takari:maven:0.7.7:wrapper
Это добавит файлы-оболочки Maven, включая файлы mvnw и mvn.cmd , которые можно использовать вместо Maven.
В то время как у Travis CI есть свой собственный Maven, другие строительные службы могут этого не делать. Эта обертка Maven поможет нам быть готовыми к любой ситуации. Кроме того, разработчикам не придется устанавливать Maven на свои машины.
4.2. Строительная служба
После этого давайте создадим учетную запись на Travis CI, войдя в с вашей учетной записью GitHub. В дальнейшем мы должны разрешить доступ к нашему проекту на GitHub.
Затем мы должны создать файл .travis.yml , который будет описывать процесс построения в Travis CI. Большинство строительных сервисов позволяют нам создать такой файл, который находится в корне нашего репозитория.
В нашем случае давайте скажем Трэвису использовать Java 11 и оболочку Maven для создания нашего приложения:
language: java jdk: - openjdk11 script: - ./mvnw clean install
Свойство language указывает, что мы хотим использовать Java.
Свойство jdk указывает, какой образ Docker следует загрузить из Docker Hub, openjdk 11 в данном случае.
Свойство script указывает, какую команду запускать – мы хотим использовать нашу оболочку Maven.
Наконец, мы должны перенести наши изменения в репозиторий. CI Travis должен автоматически инициировать сборку.
5. Докеризация
В этом разделе мы создадим образ Docker с вашим приложением и разместим его на Docker Hub как часть процесса CD. Это позволит нам с легкостью запустить его на любой машине.
5.1. Хранилище изображений Docker
Во-первых, мы должны создать репозиторий Docker для наших изображений.
Давайте создадим учетную запись на Docker Hub . Кроме того, давайте создадим репозиторий для нашего проекта, заполнив соответствующие поля:
- имя: baeldung-ci-cd-process
- видимость: Публичная
- Настройка сборки: GitHub
5.2. Изображение докера
Теперь мы готовы создать образ Docker и отправить его на DockerHub.
Во-первых, давайте добавим | плагин jib-maven , который создаст и отправит наше изображение с приложением в репозиторий Docker (замените DockerHubUsername |/правильным именем пользователя):
deploy-docker true com.google.cloud.tools jib-maven-plugin 2.2.0 ${DockerHubUsername}/baeldung-ci-cd-process ${project.version} latest
Мы добавили его как часть профиля Maven, чтобы не запускать его при сборке по умолчанию.
Кроме того, мы указали два тега для изображения. Чтобы узнать больше о плагине, посетите нашу статью о кливере .
В дальнейшем давайте скорректируем наш файл сборки ( .travis.yml ):
before_install: - echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_USERNAME" --password-stdin - docker pull openjdk:11-jre-slim-sid script: - ./mvnw clean install - ./mvnw deploy jib:build -P deploy-docker
С учетом этих изменений служба сборки войдет в Docker Hub перед созданием приложения. Кроме того, он выполнит фазу deploy с нашим профилем. На этом этапе наше приложение будет отправлено в виде образа в репозиторий Docker.
Наконец, мы должны определить DOCKER_PASSWORD и DOCKER_USERNAME переменные в нашей службе сборки. В Travis CI эти переменные могут быть определены как часть настроек сборки .
Теперь давайте перенесем наши изменения в VCS. Служба сборки должна автоматически запускать сборку с нашими изменениями.
Мы можем проверить, был ли образ Docker помещен в репозиторий, запустив локально:
docker run -p 8080:8080 -t $DOCKER_USERNAME/baeldung-ci-cd-process
Теперь мы должны иметь возможность получить доступ к нашей проверке здоровья, получив доступ к http://localhost:8080/actuator/health .
6. Анализ кода
Следующее, что мы включим в наш процесс CI/CD, – это статический анализ кода. Основная цель такого процесса-обеспечить высочайшее качество кода. Например, он может обнаружить, что у нас недостаточно тестовых случаев или что у нас есть некоторые проблемы с безопасностью.
Давайте интегрируемся с CodeCov , который будет информировать нас о нашем тестовом покрытии.
Во-первых, мы должны войти в CodeCov с вашим профилем GitHub, чтобы установить интеграцию.
Во-вторых, мы должны внести изменения в наш код. Давайте начнем с добавления плагина jacoco |/:
org.jacoco jacoco-maven-plugin 0.8.5 default-prepare-agent prepare-agent report test report
Плагин отвечает за создание отчетов о тестировании, которые будут использоваться CodeCov.
Затем мы должны настроить раздел сценария в нашем файле службы сборки ( .travis.yml ):
script: - ./mvnw clean org.jacoco:jacoco-maven-plugin:prepare-agent install - ./mvnw deploy jib:build -P deploy-docker after_success: - bash <(curl -s https://codecov.io/bash)
Мы проинструктировали плагин jacoco для запуска во время фазы clean |/install . Кроме того, мы включили раздел after_success , который отправит отчет CodeCov после успешной сборки.
В дальнейшем мы должны добавить тестовый класс в наше приложение. Например, это может быть тест для основного класса:
@SpringBootTest
class CiCdApplicationIntegrationTest {
@Test
public void contextLoads() {
}
}Наконец, мы должны продвигать наши изменения. Сборка должна быть запущена, и отчет должен быть сгенерирован в нашем профиле CodeCov, связанном с репозиторием.
7. Развертывание приложения
В качестве последней части нашего процесса мы развернем наше приложение. Имея доступный для использования образ Docker, мы можем развернуть его на любой службе. Например, мы могли бы развернуть его на облачных PaaS или IaaS.
Давайте развернем наше приложение на Heroku, которое является PaaS, требующим минимальной настройки.
Сначала мы должны создать учетную запись , а затем войти в систему .
Далее, давайте создадим пространство приложения в Heroku и назовем его baeldung-ci-cd-process . Имя приложения должно быть уникальным, поэтому нам может потребоваться использовать другое.
Мы развернем его, интегрировав Heroku с GitHub , так как это самое простое решение. Однако мы также могли бы написать конвейер, который будет использовать наш образ Docker.
В дальнейшем мы должны включить heroku плагин в наш pom:
deploy-heroku true com.heroku.sdk heroku-maven-plugin 3.0.2 spring-boot-ci-cd java $JAVA_OPTS -jar -Dserver.port=$PORT target/${project.build.finalName}.jar
Как и в случае с Docker, мы добавили его как часть профиля Maven. Кроме того, мы включили команду запуска в раздел web .
Затем мы должны настроить наш файл службы сборки ( .travis.yml ), чтобы также развернуть приложение на Heroku:
script: - ./mvnw clean install - ./mvnw heroku:deploy jib:build -P deploy-heroku,deploy-docker
Кроме того, давайте добавим API-КЛЮЧ Heroku в переменную HEROKU_API_KEY в нашем строительном сервисе.
Наконец, давайте зафиксируем наши изменения. Приложение должно быть развернуто в Heroku после завершения сборки.
Мы можем проверить это, обратившись к https://baeldung-ci-cd-process.herokuapp.com/actuator/health
8. Заключение
В этой статье мы узнали, каковы основные части процесса CI/CD и как их подготовить.
Во-первых, мы подготовили репозиторий Git в GitHub и поместили туда наше приложение. Затем мы использовали Travis CI в качестве инструмента сборки для создания нашего приложения из этого репозитория.
После этого мы создали образ Docker и отправили его на DockerHub.
Затем мы добавили службу, которая отвечает за статический анализ кода.
Наконец, мы развернули наше приложение в PaaS и получили к нему доступ.
Как всегда, код для этих примеров доступен через на GitHub .