Лекция 145: Интеграция с GitLab CI: автоматическая сборка и тестирование

Сегодня мы подробнее разберёмся с GitLab CI, встроенным инструментом системы контроля версий GitLab для управления процессами CI/CD. Его главное преимущество — бесшовная интеграция с репозиторией кода. Вы прямо в GitLab можете описать весь процесс сборки, тестирования и даже деплоя, используя обычный YAML-файл.

Основные понятия GitLab CI

Перед тем как приступить к практике, давайте немного теории:

• Pipeline — набор стадий, которые автоматизируют весь процесс (например: сборка → тест → деплой).
• Stage — отдельный этап пайплайна (например, "test" или "build").
• Job — задача внутри стадии (например, запуск тестов).
• Runner — исполнитель, который запускает ваши задачи. Может быть локальным или хоститься GitLab.

Немного похоже на конвейер на фабрике: код заходит на вход, и ваш CI/CD пайплайн, как грамотный робот, собирает, тестирует, проверяет и, вуаля, всё готово!

Задачи нашей лекции

На сегодняшнем занятии мы:

1. Создадим базовый .gitlab-ci.yml для Spring Boot проекта.
2. Настроим этапы сборки и тестирования.
3. Убедимся, что автоматическая сборка и тестирование проходят успешно на каждый коммит.

Практика: Настройка GitLab CI для Spring Boot проекта

1. Подготовка Spring Boot проекта

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

Проектная структура:

my-spring-boot-app/
├── src/
│   ├── main/
│   │   ├── java/
│   │   └── resources/
│   │        └── application.yml
│   ├── test/
│   │   ├── java/
│   │   └── resources/
├── pom.xml

Если у вас еще нет своего проекта — создайте его с помощью Spring Initializr (https://start.spring.io).

Теперь, когда ваш проект готов, давайте добавим немного "магии автоматизации".

2. Создание файла .gitlab-ci.yml

Это ключевой файл для конфигурации CI/CD пайплайнов, и именно он управляет автоматизацией процессов. Файл должен находиться в корне вашего репозитория.

Пример .gitlab-ci.yml для Spring Boot проекта:

stages: # Определяем этапы пайплайна
  - build
  - test

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=/cache/.m2/repository" # Кэшируем локальные зависимости Maven

build:
  stage: build
  image: maven:3.8.5-openjdk-11 # Используем Docker-образ с Maven и JDK
  script:
    - mvn clean compile # Команда для компиляции проекта
  artifacts:
    paths:
      - target/ # Передаём артефакты (напр., jar-файлы) на следующие этапы

test:
  stage: test
  image: maven:3.8.5-openjdk-11
  script:
    - mvn test # Запускаем тесты
  artifacts:
    reports:
      junit: target/surefire-reports/TEST-*.xml # Журналируем результаты тестирования

Вот и всё! Теперь разберёмся, что мы здесь написали.

• stages: указываем этапы пайплайна, которые будут выполняться последовательно: сначала build, затем test.
• image: используем Docker-образ с Maven и Java 11. Это поможет воспроизвести окружение для сборки.
• variables: здесь определяется настройка Maven, чтобы ускорить сборку с помощью кэширования зависимостей.
• script: набор команд, которые требуется выполнить на каждом этапе.
• artifacts: файлы, которые передаются между этапами или включаются в результаты пайплайна.

P.S.: Вам может показаться, что YAML читается как набор заклинаний. Но на самом деле важно лишь научиться различать отступы и помнить, что "колония" (:) разделяет ключ и значение!

3. Тестирование пайплайна

1. Закоммитьте файл .gitlab-ci.yml в репозиторий:

   
   git add .gitlab-ci.yml
   git commit -m "Добавил GitLab CI"
   git push origin main
   

2. Откройте GitLab и перейдите в раздел CI/CD → Pipelines. Там вы увидите процесс выполнения пайплайна. Если всё настроено верно, стадии build и test будут выполнены успешно (зелёный цвет 🎉).

Частые ошибки и их устранение

1. Ошибка: "No such file or directory"
   • Это значит, что GitLab Runner не может найти некоторый файл или директорию (например, pom.xml). Убедитесь, что ваш проект корректно скопирован в репозиторий.
2. Ошибка: "Permission denied"
   • Возможно, Runner не имеет прав на выполнение команд. Проверьте права доступа вашего Runner'а.
3. Ошибка сборки: "Dependency not found"
   • Убедитесь, что ваш Maven проект настроен и все зависимости прописаны в pom.xml.

А как это поможет в реальной жизни?

Теперь каждый раз, как только вы вносите изменения в репозиторий (например, добавляете новый функционал), ваш код автоматически компилируется, тестируется и проверяется. Вы сразу будете знать, если что-то пошло не так.

Теперь вперед — добавьте автоматизацию, ведь вы на пороге создания по-настоящему профессионального пайплайна!