CI/CD (постійна інтеграція/впровадження)

Розділ: Інженерія систем і програмного забезпечення

📌 Про що ця тема

CI/CD — це практики автоматизації збирання, тестування й доставки програмного забезпечення. Перевіряють розуміння того, навіщо потрібна автоматизація розробки, з яких етапів складається конвеєр (pipeline) і чим відрізняються континуальна інтеграція, доставка й розгортання. Ключове поняття — автоматизований конвеєр розробки.


📖 Головне

• CI (Continuous Integration, постійна інтеграція) — часте злиття коду всіх розробників у спільну гілку з автоматичним збиранням і тестуванням після кожної зміни. Мета — рано знаходити конфлікти й помилки.

• CD має два значення: Continuous Delivery (постійна доставка) — код автоматично готується до випуску, але рішення про викладення приймає людина; Continuous Deployment (постійне розгортання) — кожна вдала зміна автоматично потрапляє до користувачів без ручного кроку.

• Pipeline (конвеєр) — послідовність автоматичних етапів: отримання коду → збирання (build) → тестування → пакування → розгортання (deploy).

• Система контролю версій (напр. Git) — основа CI/CD: зміни зберігаються в репозиторії, commit і push запускають конвеєр.

• Тригер — подія, що запускає конвеєр (новий commit, pull/merge request, розклад).

• Автоматичні тести — unit (окремі функції), інтеграційні (взаємодія модулів), end-to-end (поведінка системи). Якщо тест не пройдено — конвеєр зупиняється.

• Артефакт — результат збирання (виконуваний файл, пакет, образ контейнера), який передається на наступні етапи.

• Середовища: dev (розробка), test/staging (тестове, схоже на бойове), production (робоче, для користувачів).

• Rollback (відкат) — повернення до попередньої робочої версії у разі збою.

• Переваги: швидший випуск, менше ручних помилок, стабільніша якість, швидкий зворотний зв'язок розробнику.


🔢 Як це працює на прикладі

Розробник виправив функцію й робить git push у гілку.

1. Тригер: push запускає конвеєр на CI-сервері.

2. Build: код автоматично збирається; якщо не компілюється — конвеєр падає, розробник отримує сповіщення.

3. Test: запускаються unit- та інтеграційні тести; усі пройдено.

4. Пакування: формується артефакт (напр. образ контейнера).

5. Deploy на staging: версію розгорнуто в тестовому середовищі, проходять end-to-end тести.

6. При Continuous Delivery — людина натискає «випустити» на production; при Continuous Deployment — розгортання відбувається автоматично. Якщо на production виявиться збій — виконується rollback.


⚠️ Типові помилки

• Плутають Continuous Delivery і Continuous Deployment: у Delivery фінальний випуск підтверджує людина, у Deployment — усе автоматично.

• Вважають, що CI/CD — це одна програма. Насправді це практика/підхід, реалізований набором інструментів.

• Думають, що CI = лише злиття коду без тестів; насправді автоматичне тестування — обов'язкова частина.

• Плутають build (збирання) і deploy (розгортання) — це різні етапи конвеєра.

• Забувають роль системи контролю версій як точки запуску конвеєра.


🎯 Що завчити напамʼять

• CI = постійна інтеграція (часте злиття + авто-збирання + авто-тести).

• CD = Delivery (готовність до випуску, рішення людини) або Deployment (авто-випуск).

• Етапи pipeline: build → test → пакування → deploy.

• Середовища: dev → test/staging → production.

• Тригер, артефакт, rollback — базові терміни.


🧠 Перевір себе

1. Чим Continuous Delivery відрізняється від Continuous Deployment?

2. Що запускає конвеєр CI/CD?

3. Що станеться з конвеєром, якщо автоматичний тест не пройдено?

4. Для чого потрібен rollback?


Відповіді: 1 — у Delivery фінальний випуск на production підтверджує людина, у Deployment він відбувається автоматично; 2 — тригер, напр. новий commit/push чи merge request (рідше розклад); 3 — конвеєр зупиняється, зміна не йде далі, розробник отримує сповіщення; 4 — щоб швидко повернути попередню робочу версію при збої нового випуску.

Перевірити себе на практиці

Прочитати — половина справи. Далі потрібні завдання цієї ж теми з розбором кожної відповіді: саме на них видно, чи справді тема закрита.