Пошук уроків, статей та іншого контенту
Що насправді означають ці абревіатури та навіщо потрібен автоматизований конвеєр доставки коду.
CI/CD часто вимовляють як одне слово, але це дві окремі практики, що зазвичай працюють у парі: Continuous Integration (безперервна інтеграція) і Continuous Delivery/Deployment (безперервна доставка/розгортання).
CI — практика, за якою кожна зміна коду (наприклад, кожен push чи pull request) автоматично збирається й перевіряється: компілюється, проходить тести, лінтер. Мета — виявити проблему одразу, поки контекст свіжий, а не через тиждень, коли хтось інший уже побудував код на цій помилці.
# Спрощений приклад CI-конвеєра (GitHub Actions)
on: [pull_request]
jobs:
check:
steps:
- run: npm install
- run: npm run typecheck
- run: npm run lint
- run: npm testЦі два терміни плутають найчастіше — різниця в тому, що відбувається ПІСЛЯ успішної CI-перевірки:
Continuous Delivery — код автоматично готується до розгортання (збірка, артефакт готовий), але фінальний реліз у продакшн — ручна дія (натиснути кнопку).
Continuous Deployment — кожна зміна, що пройшла всі перевірки, автоматично потрапляє в продакшн без ручного втручання.
Continuous Deployment вимагає високого рівня довіри до автоматизованих тестів — команда фактично покладається на них як на єдиний запобіжник перед продакшеном. Багато команд свідомо обирають Continuous Delivery з ручним «дозволом» на реліз саме для додаткового контролю.
Встановлення залежностей.
Статичні перевірки: типи, лінтер, форматування.
Автоматизовані тести (unit, integration, іноді e2e).
Збірка production-артефакту (наприклад, Docker-образ).
Розгортання на staging-середовище для фінальної перевірки.
Розгортання в продакшн (автоматично або за ручним підтвердженням).
Без CI/CD команда покладається на ручну дисципліну («не забудь прогнати тести перед мержем») — і рано чи пізно хтось забуває. Автоматизований конвеєр робить перевірку якості обов'язковою частиною процесу, а не необов'язковим кроком, який можна пропустити під дедлайном.
Занадто повільний CI-конвеєр (наприклад, 30+ хвилин на просту зміну) — команда починає обходити перевірки чи мержити, не чекаючи результату, що зводить нанівець сенс CI; варто розпаралелювати незалежні кроки та кешувати залежності між запусками.
Continuous Deployment без достатнього покриття тестами — автоматичний реліз у продакшн настільки надійний, наскільки надійні тести, які його пропускають; недостатнє покриття означає, що баги долітають до користувачів автоматично й швидко.
Тримати секрети (API-ключі, паролі бази даних) прямо в конфігурації конвеєра замість менеджера секретів CI-системи — конфігурація конвеєра часто зберігається в тому самому репозиторії, що й код.