Що таке CI/CD: від ручного deploy до автоматизованих pipelines

Що таке CI/CD: від ручного deploy до автоматизованих pipelines

Майже кожен проєкт починається однаково. Один розробник, один сервер, один спосіб викласти зміни: підключитися по SSH, зробити git pull, перезапустити сервіс. Це працює. Поки проєкт маленький, це навіть швидше за будь-яку автоматизацію, бо весь процес займає хвилину і не вимагає жодного налаштування.

Проблеми починаються не через розмір коду, а через кількість людей і частоту змін. Двоє розробників уже можуть викласти на сервер різні версії одного файлу. Троє вже потребують домовленості, хто і коли деплоїть. Через півроку у проєкті з'являється staging-середовище, ще через рік — окремий сервер для клієнтської демо-версії, і кожен новий сервер це ще один набір ручних кроків, які хтось повинен пам'ятати і виконувати без помилок.

CI/CD це відповідь на цю проблему. Замість інструкції у голові (або у файлі deploy.txt, який ніхто не оновлював два роки) з'являється код, який виконує ті самі дії однаково, щоразу і без участі людини. Ця стаття пояснює, що саме ховається за абревіатурою, з чого складається pipeline і які інструменти для цього існують у 2026 році.

1.1 Типова ситуація без CI/CD

Виглядає це приблизно так. Розробник закінчив функцію, перевірив локально, зробив коміт і пуш. Далі відкриває термінал:

ssh deploy@192.0.2.10
cd /var/www/app
git pull origin main
npm ci --production
npm run build
sudo systemctl restart app

Шість команд, дві хвилини. Виглядає безпечно рівно доти, доки все йде за сценарієм. У реальності між цими рядками ховається десяток припущень: що на сервері та сама версія Node.js, що git pull не впаде через локальні зміни, які хтось залишив під час нічного інциденту, що збірка не з'їсть усю пам'ять і не покладе сусідній сервіс, що після рестарту застосунок справді піднявся, а не впав у краш-цикл.

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

1.2 Що іде не так

Ручний deploy ламається за трьома напрямками, і всі три з часом лише посилюються.

Людський фактор. Це не про недбалість, а про статистику. Будь-яка послідовність з десяти кроків, яку людина виконує вручну по кілька разів на тиждень, рано чи пізно буде виконана з помилкою: не та гілка, не той сервер у другій вкладці термінала, забутий крок зі складання фронтенду, застосована міграція на продакшн-базі замість staging. Що досвідченіший інженер, то рідше це трапляється, але ніколи не зникає повністю.

Несинхронізовані середовища. Локальна машина розробника, staging і продакшн майже завжди відрізняються: версією інтерпретатора, версією системних бібліотек, набором змінних оточення, наявністю кешу. Фраза «у мене локально працює» це не відмовка, а точний опис ситуації, коли код справді працює в одному середовищі і не працює в іншому. Без автоматизації ніхто не знає, наскільки саме розійшлися ці три середовища, бо їх ніхто ніколи не порівнював системно.

Страх deploy. Це найдорожчий наслідок і найменш помітний. Якщо викладка змін ризикована і робиться вручну, команда починає викладати рідше. Замість десяти маленьких змін на тиждень з'являється один великий реліз раз на два тижні. У ньому сотні змінених файлів, і коли після нього щось ламається, ніхто не може швидко сказати, який саме коміт винен. Ризик релізу зростає, тому релізи роблять ще рідше, і цикл замикається. Пʼятничне «давай уже в понеділок» це симптом саме цієї проблеми.

2. CI і CD: у чому різниця

Абревіатура CI/CD об'єднує три різні практики, і плутанина навколо неї виникає тому, що літера D означає одразу два різні поняття. Розберемо їх окремо.

2.1 CI — Continuous Integration

Continuous Integration це практика, за якої код кожного розробника автоматично збирається і перевіряється при кожному відправленні у репозиторій. Ключове слово тут інтеграція: ідея у тому, щоб зливати зміни у спільну гілку часто (щодня або частіше) і одразу перевіряти, що спільний код лишається робочим.

Типовий CI-процес запускається на кожен push і на кожен pull request, а всередині робить приблизно таке:

• Збирає проєкт. Компіляція, встановлення залежностей, збірка фронтенду, побудова Docker-образу. Якщо збірка падає, далі немає сенсу йти.
• Проганяє лінтери і статичний аналіз. Форматування, невикористані змінні, потенційні помилки типів, порушення стилю коду.
• Виконує тести. Модульні тести майже завжди, інтеграційні за наявності, іноді e2e-тести у браузері.
• Перевіряє залежності на вразливості. npm audit, pip-audit, Trivy для образів, сканування секретів у коді.

Результат CI це відповідь так/ні на питання «чи можна зливати ці зміни». У GitHub і GitLab ця відповідь перетворюється на зелену або червону позначку біля коміта і на блокування злиття pull request, поки перевірки не пройдуть.

Важлива деталь: CI не деплоїть нічого і нікуди. Його зона відповідальності закінчується там, де код визнано придатним.

2.2 CD — Continuous Delivery

Continuous Delivery це продовження CI: після успішних перевірок система автоматично готує реліз і доводить його до стану «можна викладати будь-якої миті». Практично це означає:

• зібраний артефакт (Docker-образ, .deb-пакет, архів зі статикою) складено у сховище і позначено версією;
• артефакт автоматично розгорнуто на staging-середовищі;
• на staging прогнано інтеграційні і приймальні тести;
• кнопка «викласти на продакшн» доступна, але натискає її людина.

Ручний крок тут не недолік, а свідоме рішення. Він потрібен там, де викладка має збігатися з бізнес-подіями (маркетингова кампанія, узгоджене вікно обслуговування, реліз мобільного застосунку у сторі) або де регуляторні вимоги передбачають підтвердження від відповідальної особи.

2.3 CD — Continuous Deployment

Continuous Deployment прибирає останній ручний крок. Кожна зміна, яка пройшла всі перевірки, автоматично потрапляє на продакшн без участі людини. Людина натискає кнопку рівно один раз: коли зливає pull request.

Це найзріліший рівень, і він вимагає інфраструктури, яка помітить проблему замість людини:

• Надійне тестове покриття. Якщо тести не ловлять регресії, автоматичний деплой просто швидше доставляє поламаний код клієнтам.
• Feature flags. Незавершена функція їде на продакшн вимкненою і вмикається окремо, вже без деплою.
• Поступова викладка. Canary або blue-green: нова версія спершу отримує частину трафіку, і лише потім увесь.
• Моніторинг і автоматичний rollback. Якщо після викладки зросла частка помилок або затримка відповіді, система повертає попередню версію сама.

2.4 Схема: код → CI → CD → продакшн

Ланцюжок від коміта до продакшну виглядає так:

push у гілку
   ↓
[CI]  build → lint → test → security scan
   ↓  (усе зелене)
[CD]  збірка артефакту → сховище → deploy на staging → тести на staging
   ↓
Continuous Delivery: чекає на ручне підтвердження
Continuous Deployment: їде далі самостійно
   ↓
продакшн + моніторинг + можливість rollback

Різниця між трьома практиками зводиться до того, де закінчується автоматика:

Практична порада: рухайтеся по цій таблиці згори вниз і не перестрибуйте рядки. CI дає користь одразу і майже без ризику. Continuous Delivery потребує кількох тижнів на налаштування staging і сховища. Continuous Deployment має сенс тоді, коли команда вже кілька місяців живе з Delivery і бачить, що ручний крок став формальністю.

3. Що відбувається всередині pipeline

Pipeline це опис усього процесу у вигляді файлу в репозиторії: .github/workflows/ci.yml для GitHub Actions, .gitlab-ci.yml для GitLab CI. Термінологія у різних систем відрізняється у деталях, але будівельні блоки скрізь однакові: тригер, стадія, задача, артефакт.

3.1 Trigger: подія, що запускає pipeline

Тригер відповідає на питання «коли». Найпоширеніші варіанти:

• push у певну гілку. Основний тригер для CI.
• pull request / merge request. Перевіряє результат злиття ще до того, як воно відбулося.
• tag. Створення тега v1.4.0 запускає реліз: збірку артефакту, публікацію, деплой.
• cron / schedule. Нічні прогони важких тестів, щоденне сканування залежностей на нові CVE.
• ручний запуск. workflow_dispatch у GitHub, кнопка Run pipeline у GitLab. Саме цей тригер реалізує ручний крок у Continuous Delivery.
• зовнішня подія. Виклик через API або webhook: наприклад, pipeline у сусідньому репозиторії, який зібрав нову версію бібліотеки.

Окремо варто знати про фільтр за шляхами. У монорепозиторії немає сенсу ганяти тести бекенду, коли змінився лише файл документації:

# GitHub Actions
on:
  push:
    branches: [main]
    paths:
      - 'backend/**'
      - '!**.md'

3.2 Stage: логічна група кроків

Стадія відповідає на питання «у якому порядку». Класичний набір це build → test → deploy, і сенс поділу у тому, що наступна стадія стартує лише тоді, коли попередня повністю завершилася успішно. Немає сенсу деплоїти те, що не зібралося, і тестувати те, що не зібралося теж.

Стадії дають ще одну корисну властивість: усе всередині однієї стадії може виконуватися паралельно. Якщо у стадії test є модульні тести, лінтер і сканер вразливостей, вони запускаються одночасно на різних runner-ах, і стадія триває стільки, скільки найповільніша з трьох перевірок, а не стільки, скільки їх сума.

3.3 Job: конкретна задача

Задача це те, що реально виконується: набір команд у конкретному оточенні на конкретному runner-і. Кожна задача стартує у чистому середовищі, тому вона завжди починається з отримання коду і встановлення залежностей.

Мінімальний робочий приклад для GitHub Actions:

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run lint
      - run: npm test

Той самий сенс у синтаксисі GitLab CI:

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: node:20
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

test:
  stage: test
  image: node:20
  script:
    - npm test

deploy:
  stage: deploy
  script:
    - ./scripts/deploy.sh
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

У GitHub Actions стадій як окремої сутності немає, порядок задається залежностями через ключ needs. У GitLab needs теж є і працює поверх стадій, дозволяючи будувати граф залежностей замість суворої черги. На великих pipeline це помітно скорочує загальний час.

3.4 Artifact: файл, що передається між задачами

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

Типові артефакти: зібраний фронтенд, скомпільований бінарник, згенерований пакет, а також звіти (результати тестів, покриття коду, звіт сканера вразливостей), які зручно дивитися прямо в інтерфейсі CI.

Артефакти легко переплутати з кешем, хоча задачі у них різні:

4. Що дає CI/CD на практиці

Абстрактна користь від автоматизації зрозуміла кожному. Корисніше подивитися, що саме змінюється у щоденній роботі.

4.1 Швидкий feedback

Головна цінність CI не в економії часу на запуск тестів, а у зменшенні інтервалу між помилкою і її виявленням. Вартість виправлення прямо залежить від цього інтервалу.

Побічний ефект швидкого feedback приємніший за очевидну економію: розробники починають робити менші коміти. Коли перевірка займає дві хвилини, немає причини накопичувати зміни. А менші коміти це простіший review і точніша відповідь на питання «після якої зміни зламалося».

4.2 Однакові умови на всіх середовищах

Pipeline виконується в описаному оточенні: конкретний образ, конкретна версія інтерпретатора, залежності з lock-файлу. Це оточення описане у репозиторії поруч з кодом, тому воно однакове для всіх і змінюється лише через pull request.

Наслідки цього виходять за межі самої збірки:

• Оновлення версій стає керованим. Перехід з Node.js 20 на 22 це один рядок у конфізі, і pipeline одразу показує, що саме зламається.
• Онбординг спрощується. Новий розробник читає конфіг pipeline і бачить точний перелік того, що потрібно проєкту.
• Продакшн перестає бути унікальним сервером. Якщо деплой це розгортання того самого образу, який пройшов тести, різниця між середовищами зводиться до конфігурації і даних.

4.3 Deploy стає рутиною, а не подією

Коли викладка це одна дія, яка виконується однаково і має передбачуваний відкат, змінюється сама культура роботи. Замість двотижневих релізів з'являються щоденні, і кожен з них містить мало змін, тому ризик кожного окремого релізу невеликий.

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

5. Популярні інструменти

Ринок CI/CD ділиться на три групи: хмарні платформи, вбудовані у git-хостинг; self-hosted git-платформи з власним CI; окремі CI-системи, які працюють з будь-яким репозиторієм.

5.1 Хмарні платформи

• GitHub Actions. Запущений у 2019 році, зараз найпоширеніший варіант завдяки величезному marketplace готових дій і тому, що більшість open-source проєктів живуть на GitHub. Конфіг у .github/workflows/, безкоштовні хвилини для публічних репозиторіїв, обмежена квота для приватних.
• GitLab CI. Вбудований у GitLab з 2015 року і історично сильніший у частині складних pipeline: стадії, граф залежностей, дочірні pipeline, вбудовані середовища з історією деплоїв. Конфіг у .gitlab-ci.yml. Доступний і у хмарі, і у власній інсталяції.
• Bitbucket Pipelines. Логічний вибір для команд, які вже працюють в екосистемі Atlassian разом з Jira. Простіший за конкурентів, з тіснішою інтеграцією з задачами.
• CircleCI. Незалежна платформа з репутацією швидкої: гнучке налаштування ресурсів під задачу, перевикористовувані конфігурації (orbs), розвинений кеш. Підключається до GitHub, GitLab і Bitbucket.

Спільна риса цієї групи: нічого не треба адмініструвати, оплата за використані хвилини або за тарифним планом. Спільне обмеження: квоти, обмежені ресурси на стандартних runner-ах і те, що ваш код збирається на чужій інфраструктурі.

5.2 Self-hosted Git з вбудованим CI

• Gitea. Легка git-платформа на Go, яка займає десятки мегабайтів пам'яті і запускається одним бінарником. З версії 1.19 має вбудований CI (Gitea Actions), сумісний з синтаксисом GitHub Actions: більшість простих workflow переносяться майже без правок.
• Forgejo. Форк Gitea під керівництвом спільноти, з тим самим механізмом Actions. Обирають ті, кому важлива модель управління проєктом і повністю вільна ліцензія.
• Gogs. Попередник Gitea, ще легший і ще простіший, але без вбудованого CI. Використовується там, де потрібен мінімальний git-хостинг, а CI підключається окремо.

Ця група має сенс, коли код не повинен залишати вашу інфраструктуру: вимоги замовника, регуляторні обмеження, робота у закритому контурі. Ціна питання це власне адміністрування: бекапи, оновлення, доступність.

5.3 Окремі CI-системи

• Jenkins. Ветеран галузі з 2011 року, з тисячами плагінів і здатністю інтегруватися практично з чим завгодно. Платить за це складністю: власна мова описів pipeline, помітні витрати на підтримку, регулярні оновлення плагінів. Досі поширений у великих компаніях з накопиченою автоматизацією.
• Drone CI. Контейнерна CI-система з простим YAML: кожен крок це запуск контейнера. Легка і зрозуміла, але після переходу під Harness умови ліцензування змінилися, що варто врахувати при виборі.
• Woodpecker CI. Форк Drone під вільною ліцензією, який розвиває спільнота. Зберігає простоту оригіналу і добре працює у парі з Gitea або Forgejo, тому це популярний вибір для повністю self-hosted стека.

5.4 Порівняння і вибір для серії

У наступних статтях серії ми зосередимося на GitHub Actions і GitLab CI, і причина суто практична. По-перше, це найширші екосистеми: майже будь-яка задача вже має готовий приклад. По-друге, обидві платформи дозволяють підключити власний runner на вашому сервері, не піднімаючи власну git-платформу. Тобто код може лишатися у звичному GitHub або GitLab, а збірка і деплой виконуватимуться на вашому залізі, з вашими ресурсами і вашими правилами доступу до продакшну.

Синтаксис Gitea Actions майже повторює GitHub Actions, тому все написане у серії про workflow буде застосовне і там, з поправкою на відсутність частини готових дій з marketplace.

6. Висновок

CI/CD це не окремий інструмент, який встановлюють, а спосіб описати процес доставки коду у вигляді коду. Три практики за абревіатурою відрізняються тим, наскільки далеко тягнеться автоматика:

• Continuous Integration перевіряє кожну зміну автоматично і дає відповідь за хвилини замість днів. Це найдешевший крок з найбільшою віддачею, і починати варто саме з нього.
• Continuous Delivery доводить перевірену зміну до стану готового релізу і викладає її на staging, лишаючи людині рішення про продакшн.
• Continuous Deployment прибирає і це рішення, але вимагає зрілих тестів, спостережуваності і механізму відкату.

Будь-який pipeline складається з тих самих блоків: тригер визначає, коли запускатися, стадії задають порядок, задачі виконують роботу, артефакти передають результати далі. Знаючи ці чотири поняття, можна читати конфіг будь-якої CI-системи, навіть якщо синтаксис бачите вперше.

Практичний результат теж вимірюваний: помилки знаходяться за хвилини, середовища перестають розходитися, а викладка з події перетворюється на рутину, яку роблять щодня і без нарад.

Що далі у серії

У другій частині розберемо архітектуру self-hosted runner: як влаштований агент, що виконує ваші задачі, чому його варто винести на власний сервер (ресурси, доступ до закритої мережі, кеш, вартість при великому обсязі збірок), як його встановити для GitHub Actions і GitLab CI, і головне, як ізолювати виконання чужого коду, щоб runner не став найслабшою точкою вашої інфраструктури.

Часті питання