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 — щоб швидко повернути попередню робочу версію при збої нового випуску.