Применение CI/CD с Spring Boot

1. Обзор

В этом руководстве мы рассмотрим процесс непрерывной интеграции/непрерывного развертывания (CI/CD) и реализуем его основные части.

Мы создадим простое приложение Spring Boot, а затем отправим его в общий репозиторий Git. После этого мы создадим его с помощью службы интеграции зданий, создадим образ Docker и отправим его в репозиторий Docker.

В конце мы автоматически развернем наше приложение в сервисе PaaS (Heroku).

2. Контроль версий

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

Давайте выберем Git в качестве VCS и GitHub в качестве нашего поставщика репозитория, поскольку они наиболее популярны на данный момент и бесплатны для использования.

Во-первых, нам нужно создать учетную запись на GitHub.

Кроме того, мы должны создать репозиторий Git . Назовем его foreach-ci-cd-process . Кроме того, давайте выберем общедоступный репозиторий, так как он позволит нам получить доступ к другим сервисам бесплатно. Наконец, давайте инициализируем наш репозиторий файлом README.md .

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

git clone https://github.com/$USERNAME/foreach-ci-cd-process.git

Это инициализирует наш проект в каталоге, где мы выполнили команду. На данный момент он должен содержать только файл README.md .

3. Создание приложения

В этом разделе мы создадим простое приложение Spring Boot, которое будет участвовать в процессе. Мы также будем использовать Maven в качестве инструмента сборки.

Во-первых, давайте инициализируем наш проект в каталоге, где мы клонировали репозиторий контроля версий.

Например, мы можем сделать это с помощью Spring Initializer , добавив веб -модули и модули привода .

3.1. Создание приложения вручную

Или мы можем добавить зависимости spring-boot-starter-web и spring-boot-starter-actuator вручную: ``

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Первый — ввести конечную точку REST, а второй — конечную точку проверки работоспособности.

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

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
</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 Wrapper в наше приложение. Если мы использовали Spring Initializr, мы можем пропустить эту часть, так как она включена по умолчанию.

В каталоге приложения делаем:

mvn -N io.takari:maven:0.7.7:wrapper

Это добавит файлы-оболочки Maven, включая файлы mvnw и mvnw.cmd , которые можно использовать вместо Maven.

Хотя у Travis CI есть собственный Maven, у других строительных служб может и не быть. Эта Maven Wrapper поможет нам быть готовыми к любой ситуации. Кроме того, разработчикам не нужно будет устанавливать Maven на свои машины.

4.2. Строительная служба

После этого давайте создадим учетную запись на Travis CI, войдя в нашу учетную запись GitHub. В дальнейшем мы должны разрешить доступ к нашему проекту в GitHub.

Далее нам нужно создать файл .travis.yml , который будет описывать процесс сборки в Travis CI. Большинство сервисов сборки позволяют нам создать такой файл, который находится в корне нашего репозитория.

В нашем случае давайте скажем Трэвису использовать Java 11 и Maven Wrapper для сборки нашего приложения:

language: java
jdk:
  - openjdk11
script:
  - ./mvnw clean install

Свойство языка указывает, что мы хотим использовать Java.

Свойство jdk указывает, какой образ Docker нужно загрузить с DockerHub, в данном случае openjdk11.

Свойство script говорит, какую команду запускать — мы хотим использовать нашу оболочку Maven.

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

5. Докеризация

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

5.1. Репозиторий образов Docker

Во-первых, мы должны создать репозиторий Docker для наших образов.

Давайте создадим учетную запись на DockerHub . Также создадим репозиторий для нашего проекта, заполнив соответствующие поля:

• имя: foreach-ci-cd-процесс
• видимость: общедоступная
• Настройка сборки: GitHub

5.2. Докер-образ

Теперь мы готовы создать образ Docker и отправить его в DockerHub.

Для начала `` добавим jib-maven-plugin , который создаст и запушит наш образ с приложением в репозиторий Docker (замените DockerHubUsername на правильное имя пользователя):

<profile>
    <id>deploy-docker</id>
    <properties>
        <maven.deploy.skip>true</maven.deploy.skip>
    </properties>
    <build>
        <plugins>
            <plugin>
                <groupId>com.google.cloud.tools</groupId>
                <artifactId>jib-maven-plugin</artifactId>
                <version>2.2.0</version>
                <configuration>
                    <to>
                        <image>${DockerHubUsername}/foreach-ci-cd-process</image>
                        <tags>
                            <tag>${project.version}</tag>
                            <tag>latest</tag>
                        </tags>
                    </to>
                </configuration>
            </plugin>
        </plugins>
    </build>
</profile>

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

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

В дальнейшем давайте настроим наш файл сборки ( .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

С этими изменениями служба сборки будет входить в DockerHub перед сборкой приложения. Кроме того, он выполнит фазу развертывания с нашим профилем. На этом этапе наше приложение будет отправлено в виде образа в репозиторий Docker.

Наконец, мы должны определить переменные DOCKER_PASSWORD и DOCKER_USERNAME в нашей службе сборки. В Travis CI эти переменные можно определить как часть настроек сборки .

Теперь давайте отправим наши изменения в VCS. Служба сборки должна автоматически запускать сборку с нашими изменениями.

Мы можем проверить, был ли образ Docker отправлен в репозиторий, запустив локально:

docker run -p 8080:8080 -t $DOCKER_USERNAME/foreach-ci-cd-process

Теперь мы должны получить доступ к нашей проверке работоспособности, открыв http://localhost:8080/actuator/health .

6. Анализ кода

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

Давайте интегрируемся с CodeCov , который будет информировать нас о нашем тестовом покрытии.

Во-первых, мы должны войти в CodeCov с нашим профилем GitHub, чтобы установить интеграцию.

Во-вторых, мы должны внести изменения в наш код. Начнем с добавления плагина jacoco :

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.5</version>
    <executions>
        <execution>
            <id>default-prepare-agent</id>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
        </execution>
        <execution>
            <id>report</id>
            <phase>test</phase>
            <goals>
                <goal>report</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Плагин отвечает за создание тестовых отчетов, которые будут использоваться 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 срабатывать на этапе чистой установки . Кроме того, мы включили раздел after_success , который отправит отчет в CodeCov после успешной сборки.

В дальнейшем мы должны добавить тестовый класс в наше приложение. Например, это может быть тест для основного класса:

@SpringBootTest
class CiCdApplicationIntegrationTest {

    @Test
    public void contextLoads() {

    }
}

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

7. Развертывание приложения

В качестве последней части нашего процесса мы развернем наше приложение. Имея образ Docker, доступный для использования, мы можем развернуть его на любом сервисе. Например, мы могли бы развернуть его на облачной платформе PaaS или IaaS.

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

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

Далее давайте создадим пространство приложения в Heroku и назовем его foreach-ci-cd-process . Имя приложения должно быть уникальным, поэтому нам может понадобиться использовать другое.

Мы развернем его, интегрировав Heroku с GitHub , так как это самое простое решение. Однако мы могли бы также написать конвейер, который будет использовать наш образ Docker.

В дальнейшем мы должны включить плагин heroku в наш pom:

<profile>
    <id>deploy-heroku</id>
    <properties>
        <maven.deploy.skip>true</maven.deploy.skip>
    </properties>
    <build>
        <plugins>
            <plugin>
                <groupId>com.heroku.sdk</groupId>
                <artifactId>heroku-maven-plugin</artifactId>
                <version>3.0.2</version>
                <configuration>
                    <appName>spring-boot-ci-cd</appName>
                    <processTypes>
                        <web>java $JAVA_OPTS -jar -Dserver.port=$PORT target/${project.build.finalName}.jar</web>
                    </processTypes>
                </configuration>
            </plugin>
        </plugins>
    </build>
</profile>

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

Затем мы должны настроить наш файл службы сборки ( .travis.yml ), чтобы также развернуть приложение на Heroku:

script:
  - ./mvnw clean install
  - ./mvnw heroku:deploy jib:build -P deploy-heroku,deploy-docker

Кроме того, давайте добавим API-KEY Heroku в переменную HEROKU_API_KEY в нашем сервисе сборки.

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

Мы можем проверить это, зайдя на https://foreach-ci-cd-process.herokuapp.com/actuator/health .

8. Заключение

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

Сначала мы подготовили Git-репозиторий в GitHub и отправили туда наше приложение. Затем мы использовали Travis CI в качестве инструмента сборки для сборки нашего приложения из этого репозитория.

После этого мы создали образ Docker и отправили его на DockerHub.

Далее мы добавили сервис, отвечающий за статический анализ кода.

Наконец, мы развернули наше приложение в PaaS и получили к нему доступ.

Как всегда, код этих примеров доступен на GitHub .