Лекція 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: тестування (unit і/або інтеграційні тести).
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 # Docker-образ з Maven і Java 17
  script:
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar # Зберігаємо зібрані JAR-файли
  only:
    - main # Запускаємо тільки на гілці main

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

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

Тепер у нас є робочий пайплайн, який поетапно:

1. Збирає додаток (build).
2. Виконує unit-тести (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. До речі, нехай вас не лякають помилки. Вони неминучі, але їх можна подолати.