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

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

Основні поняття GitLab CI

Перед тим як приступити до практики, давайте трохи теорії:

• Pipeline — набір стадій, які автоматизують увесь процес (наприклад: збірка → test → деплой).
• 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.

А як це допоможе в реальному житті?

Тепер щоразу, коли ви вносите зміни в репозиторій (наприклад, додаєте новий функціонал), ваш код автоматично компілюється, тестується і перевіряється. Ви одразу дізнаєтеся, якщо щось пішло не так.

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