Лекция 146: Практика: настройка пайплайна для CI/CD в GitLab

В этой лекции мы научимся:

1. Создавать и конфигурировать пайплайн в GitLab CI для Spring Boot приложения.
2. Реализовывать этапы сборки, тестирования и деплоя.
3. Разбираться, как мониторить выполнение пайплайна и устранять ошибки.

Итак, приготовьтесь! Настройка CI/CD пайплайна — это как переустановка операционной системы: делать не хочется, но после этого всё работает (по крайней мере, должно).

Зачем нам настройка CI/CD пайплайна

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

Реальный сценарий

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

• Проверяет, что проект компилируется.
• Выполняет все автоматические тесты.
• Деплоит приложение в тестовую и/или staging среду.
• В конце концов, разворачивает проверенное приложение на production.

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

Построение пайплайна: основные этапы

Начнём с создания файла .gitlab-ci.yml в корне нашего проекта. Это "сердце" GitLab CI пайплайна, где мы описываем все этапы.

stages: # Определяем стадии нашего пайплайна
  - build
  - test
  - deploy

Здесь мы указываем основные этапы:

1. build: сборка проекта.
2. test: тестирование (юнит и/или интеграционные тесты).
3. deploy: развёртывание на staging или production окружение.

Этап "build" отвечает за сборку нашего приложения. Для Spring Boot мы будем использовать Maven.

build:
  stage: build
  image: maven:3.8.5-openjdk-17 # Docker-образ с Maven и Java 17
  script:
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar # Сохраняем собранный JAR-артефакт
  only:
    - main # Запускаем стадию только на ветке main

Давайте разберём ключевые моменты:

• image: мы указываем Docker-образ, в котором будет выполняться наш этап (здесь это Maven + JDK 17).
• script: команды для выполнения. Мы запускаем mvn clean package для сборки проекта.
• artifacts: сохраняем итоговые артефакты (в данном случае JAR-файлы).
• only: запускаем эту стадию только для ветки "main", чтобы не строить каждую тестовую ветку.

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

test:
  stage: test
  image: maven:3.8.5-openjdk-17
  script:
    - mvn test # Запускаем все тесты
  only:
    - merge_requests # Выполняем тесты для merge-запросов

Что делает этот этап:

• Используется тот же Docker-образ, что и для сборки.
• Запускается команда mvn test, которая проверяет наш код.
• Настроен на выполнение для merge-запросов, ведь основной смысл тестирования — проверить код перед слиянием в основную ветку.

Этап деплоя отвечает за развёртывание приложения. Для начала мы настроим деплой на staging среду.

deploy:
  stage: deploy
  image: docker:20.10.16 # Используем Docker для развертывания
  services:
    - docker:dind # Docker-in-Docker для работы с контейнерами
  script:
    - docker build -t my-spring-app:latest .
    - docker run -d -p 8080:8080 my-spring-app:latest
  only:
    - main # Деплой выполняется только для ветки main

Разберём детали:

• image и services: мы используем Docker для развёртывания.
• script: создаём Docker-образ нашего приложения и запускаем контейнер.
• only: деплой производится только из основной ветки (main).

Полный пример пайплайна

Вот как выглядит полный .gitlab-ci.yml файл со всеми этапами:

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: maven:3.8.5-openjdk-17
  script:
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar
  only:
    - main

test:
  stage: test
  image: maven:3.8.5-openjdk-17
  script:
    - mvn test
  only:
    - merge_requests

deploy:
  stage: deploy
  image: docker:20.10.16
  services:
    - docker:dind
  script:
    - docker build -t my-spring-app:latest .
    - docker run -d -p 8080:8080 my-spring-app:latest
  only:
    - main

Теперь у нас есть работающий пайплайн, который поэтапно:

1. Собирает приложение (build).
2. Выполняет юнит-тесты (test).
3. Разворачивает собранное приложение в контейнере (deploy).

Как следить за пайплайном

После коммита изменения в GitLab:

1. Откройте вкладку CI/CD → Pipelines.
2. Вы увидите список запущенных пайплайнов и их статус (успех, ошибка, выполнение и т.д.).
3. Если что-то пошло не так, можете нажать на конкретный этап и увидеть логи выполнения.

Типичные ошибки и пути их устранения

• Ошибка: "Docker daemon not available"
  Убедитесь, что вы добавили docker:dind в секцию services.
• Ошибка сборки "Unable to find dependency"
  Проверьте файл pom.xml — возможно, зависимость указана неверно или отсутствует доступ к Maven-репозиториям.
• Тесты падают на этапе "test"
  Всегда проверяйте свои тесты локально перед пушем в репозиторий.

Теперь вы готовы автоматизировать сборку, тестирование и деплой вашего Spring Boot приложения с помощью GitLab CI. Кстати, пусть вас не пугают ошибки. Они неизбежны, но победимы.