Лекція 141: Вступ до процесів CI/CD

Якщо ти колись працював у команді розробників (або хоча б бачив меми про те, як розробники вручну тестують і деплоять застосунки в п’ятницю ввечері), ти розумієш, який головний біль може викликати збірка, тестування і розгортання застосунків. І от тоді на сцену виходить CI/CD, як супергерой.

CI/CD розшифровується як Continuous Integration (безперервна інтеграція) і Continuous Deployment/Delivery (безперервне розгортання/доставка). Так, це три слова, і так, це два поняття — бо Deployment і Delivery іноді розрізняють, а іноді об’єднують.

Тож давай розберемо їх окремо:

Continuous Integration (CI):

Уяви, що твій код — це гігантський пазл, який ви збираєте з колегами. Кожного разу, як хтось додає свою частинку пазла, система перевіряє, що вона пасує до інших частин і не ламає вже зібране. Це і є CI: процес автоматичної збірки і тестування після кожної зміни в коді. Це дозволяє виявляти помилки раніше, ніж вони перетворяться на проблему.

Continuous Deployment/Delivery (CD):

• Continuous Deployment — це коли твій код автоматично відправляється на бойові сервери після проходження всіх тестів. Це схоже на "Я натиснув git push, і через 5 хвилин усе готово!".
• Continuous Delivery вимагає від тебе лише одного ручного кліку, щоб запустити процес деплоя, а до того всі тести і перевірки вже виконані автоматично. Це корисно, якщо хочеш більше контролю над релізом.

Чому CI/CD важливий?

Коротко: CI/CD економить час, нерви і гроші. Але це трохи абстрактно, давай детальніше.

1. Автоматизація рутинних задач: ти забуваєш про запуск тестів вручну і перевірки "а точно це працює?". Машина робить усе за тебе.
2. Раннє виявлення помилок: тести запускаються після кожної зміни в коді. Якщо хтось "зламав прод", це виявляється одразу, а не через кілька тижнів.
3. Швидше на ринку: у тебе є можливість доставляти нові фічі користувачам швидше, бо всі етапи збірки і тестування суттєво пришвидшуються.
4. Менше людських помилок: люди забувають. Люди втомлюються. Люди роблять дурні помилки. Машини — ні (ну, майже ні, якщо їх правильно налаштувати).

Основні етапи CI/CD пайплайна

Давай розберемо, з чого складається типовий CI/CD пайплайн. Це як ланцюжок станцій на конвеєрі, кожна з яких відповідає за свій етап підготовки твого застосунку.

1. Коміт змін: розробники вносять зміни в код і відправляють їх у центральний репозиторій (GitHub, GitLab і т.д.).
2. Автоматична збірка: на цьому етапі твій код компілюється, збирається в артефакт (наприклад, JAR або WAR файл) і перевіряється, чи його взагалі можна запустити.
3. Тестування:
   • Юніт-тести: перевіряють окремі частини коду.
   • Інтеграційні тести: перевіряють взаємодію між компонентами.
   • End-to-End тести: перевіряють роботу застосунку в цілому.
4. Розгортання на тестову середу (staging): якщо тести пройшли успішно, застосунок розгортається на сервері для перевірки в умовах, максимально наближених до бойових.
5. Розгортання на бойову середу (production): після тестування на staging ти можеш розгорнути застосунок для реальних користувачів.

Приклади: як це працює на практиці?

Уяви, що ти розробник. Ось як може виглядати твій день з CI/CD:

1. Ти вніс зміни в код і запушив їх у GitLab.
2. GitLab CI запускає автоматичну збірку твого застосунку.
3. Юніт-тести перевіряють, що новий код працює правильно.
4. Якщо тести проходять успішно, застосунок розгортається на тестовому сервері (staging), і ти можеш переконатися, що все працює.
5. Декілька кліків (або автоматично, якщо налаштовано Continuous Deployment) — і застосунок розгортається в production.

Переваги впровадження CI/CD

Перехід на CI/CD може здатися складним і трудомістким, але ось основні причини, чому це того варте:

1. Економія часу: тобі більше не потрібно вручну запускати тести, збирати застосунок, завантажувати файли на сервер.
2. Підвищення якості продукту: завдяки ранньому виявленню помилок і автоматичному тестуванню твій код стає надійнішим.
3. Швидкість випуску оновлень: CI/CD дозволяє компанії випускати оновлення частіше і швидше. Як кажуть у DevOps-спільноті, "deploy early, deploy often".
4. Стабільність і відтворюваність: кожного разу пайплайн проходить ті самі кроки. Ніяких "людських факторів".

Чому CI/CD вважають стандартом в індустрії?

CI/CD став стандартом не просто заради моди. Цей підхід довів свою ефективність для компаній будь-якого розміру: від стартапів, які працюють над першим продуктом, до гігантів типу Google і Netflix.

Цікавий факт:

Netflix робить тисячі деплоїв у прод щодня. Це стало можливим лише завдяки CI/CD і автоматизації процесів. Уяви, якби це робили вручну — інженери б ніколи не спали.

Інструменти, які ми будемо вивчати

Існує купа інструментів для налаштування CI/CD. Ось кілька найпопулярніших, з якими ми познайомимось:

• Jenkins: дуже потужний і гнучкий інструмент для побудови пайплайнів. Але іноді здається, що йому варто вручити медаль "за найзастаріліший UI".
• GitLab CI: інтегрований інструмент CI/CD для роботи з проєктами на GitLab. Зручний, мінімалістичний, з потужною YAML-конфігурацією.
• CircleCI: простий і популярний інструмент, особливо серед тих, хто використовує Docker. Але він не інтегрований з GitLab/GitHub, що може бути мінусом для деяких.

Ми почнемо з Jenkins і GitLab CI — двох інструментів, які найчастіше обирають для роботи зі Spring Boot застосунками.

Питання для обговорення: "А CI/CD — це щось тільки для великих компаній?"

Ні в жодному разі. Уяви, що ти розробляєш невеликий інтернет-магазин. Кожного разу, як додаєш нову функціональність, потрібно перевіряти, що нічого не зламалося. Налаштувавши CI/CD, ти звільниш свій час для роботи над фічами, замість того щоб вручну тестувати застосунок.

Тепер, коли ти познайомився з теорією, у наступних лекціях ми перейдемо до практики: створимо свій Spring Boot застосунок, налаштуємо пайплайн з використанням Maven і підключимось до GitLab CI. Пора автоматизувати нудні речі!