CI/CD простими словами

Що таке CI/CD

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

Абревіатура складається з двох частин:

• CI — Continuous Integration, або безперервна інтеграція;

• CD — Continuous Delivery або Continuous Deployment, тобто безперервна доставка чи розгортання.

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

Такий конвеєр може:

1. отримати нові зміни з репозиторію;

2. встановити залежності;

3. запустити перевірки та тести;

4. зібрати застосунок;

5. створити артефакт для доставки;

6. розгорнути його на тестовому або бойовому середовищі.

CI/CD не є конкретним інструментом. Це підхід, який можна реалізувати за допомогою GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Azure Pipelines та інших платформ.

Навіщо потрібен CI/CD

Без автоматизації процес часто виглядає так:

1. розробник змінює код;

2. передає його іншій людині на перевірку;

3. хтось вручну запускає тести;

4. файли копіюють на сервер;

5. виникає помилка;

6. незрозуміло, яка саме зміна її спричинила.

CI/CD робить ці кроки передбачуваними й повторюваними.

Основні переваги

• Швидкий зворотний зв’язок. Розробник дізнається про помилку одразу після надсилання змін.

• Менше ручної роботи. Не потрібно щоразу вручну запускати однакові команди.

• Стабільніший процес релізу. Усі зміни проходять однакові перевірки.

• Менші та безпечніші зміни. Код інтегрується часто, тому проблеми легше знайти.

• Прозорість. Команда бачить, який етап пройдено, а який завершився помилкою.

• Швидший реліз. Готову версію можна доставити користувачам за кілька хвилин.

Автоматизація не гарантує відсутності помилок. Вона допомагає виявляти їх раніше та зменшує кількість випадкових дій.

Що означає CI

Continuous Integration — це безперервна інтеграція змін у спільну кодову базу.

Розробники регулярно надсилають зміни до репозиторію. Після цього автоматично запускаються перевірки:

• встановлення залежностей;

• форматування коду;

• статичний аналіз;

• модульні тести;

• інтеграційні тести;

• перевірка збирання застосунку.

Якщо перевірки не пройдено, команда отримує сигнал про проблему. Зміни можна виправити, поки вони ще невеликі й пов’язані з конкретним комітом або pull request.

Приклад безперервної інтеграції

Уявімо, що розробник додав нову функцію:

Розробник створює коміт
        ↓
Зміни надсилаються до репозиторію
        ↓
CI встановлює залежності
        ↓
Запускаються перевірки та тести
        ↓
Команда отримує результат

Якщо тест завершився помилкою, зміна не повинна потрапити до наступного етапу без виправлення.

Чому важливо інтегруватися часто

Чим довше гілка розробника живе окремо, тим більше змін накопичується. Після об’єднання можуть виникнути:

• конфлікти файлів;

• несумісність модулів;

• зламані контракти між сервісами;

• тести, які складно пов’язати з конкретною зміною.

Часті інтеграції роблять проблеми меншими та зрозумілішими.

Що означає CD

У скороченні CD можуть мати на увазі два різні процеси.

Continuous Delivery — безперервна доставка

Безперервна доставка означає, що кожна зміна автоматично готується до релізу.

Після успішних тестів система може:

• зібрати застосунок;

• створити пакет або контейнер;

• зберегти артефакт;

• підготувати розгортання;

• передати версію на тестове середовище.

Останній крок — розгортання у production — може вимагати ручного підтвердження.

Тобто програмне забезпечення завжди готове до випуску, але команда сама вирішує, коли саме його опублікувати.

Continuous Deployment — безперервне розгортання

Безперервне розгортання йде далі: кожна зміна, яка успішно пройшла всі перевірки, автоматично потрапляє у production.

Схема може виглядати так:

Зміна коду
   ↓
Перевірки
   ↓
Збирання
   ↓
Тестове середовище
   ↓
Автоматичне розгортання у production

Continuous Deployment потребує високого рівня довіри до автоматичних тестів, моніторингу та механізмів відкату.

Різниця між Delivery і Deployment

• Continuous Delivery: система готує зміни, але реліз може запускатися вручну.

• Continuous Deployment: система сама розгортає всі зміни, які пройшли перевірки.

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

Що таке pipeline

Pipeline, або конвеєр, — це послідовність автоматизованих кроків.

Наприклад:

Код → Перевірки → Тести → Збирання → Доставка → Розгортання

Кожен крок може називатися:

• stage — етап;

• job — завдання;

• step — окрема команда або дія.

Точні назви залежать від інструмента, але логіка зазвичай однакова.

Приклад простого pipeline

name: Перевірка застосунку

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Отримати код
        uses: actions/checkout@v4

      - name: Встановити Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Встановити залежності
        run: npm ci

      - name: Перевірити форматування
        run: npm run lint

      - name: Запустити тести
        run: npm test

      - name: Зібрати застосунок
        run: npm run build

У цьому прикладі pipeline запускається:

• після надсилання змін у гілку main;

• під час створення або оновлення pull request.

Спочатку система отримує код, потім встановлює Node.js і залежності, запускає перевірки, тести та збирання. Якщо будь-який крок завершується з помилкою, pipeline зупиняється.

Назви команд залежать від конкретного проєкту. Наприклад, не кожен застосунок має команду npm run build, а для іншої мови програмування використовуватимуться інші інструменти.

Типова структура CI/CD-процесу

1. Тригер

Pipeline потрібно запустити у відповідь на певну подію:

• push до репозиторію;

• створення pull request;

• створення тега;

• розклад;

• ручний запуск;

• завершення іншого pipeline.

Наприклад, перевірки можна запускати для кожного pull request, а production-реліз — лише після створення версійного тега.

2. Перевірка коду

На цьому етапі можуть запускатися:

• форматер;

• linter;

• перевірка типів;

• аналіз залежностей;

• перевірка секретів у коді;

• перевірка правил проєкту.

Ці перевірки не замінюють тести, але допомагають швидко знаходити прості проблеми.

3. Тестування

Залежно від проєкту pipeline може запускати:

• модульні тести;

• інтеграційні тести;

• end-to-end тести;

• тести продуктивності;

• перевірки сумісності API.

Не всі тести потрібно запускати на кожній зміні. Частину довгих або дорогих перевірок можна виконувати за розкладом чи перед релізом.

4. Збирання

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

Це може бути:

• скомпільований застосунок;

• архів;

• пакет;

• Docker-образ;

• набір статичних файлів;

• пакет для мобільного застосунку.

Результат збирання називають артефактом.

5. Доставка

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

6. Розгортання

Артефакт встановлюється на певне середовище:

• development;

• testing;

• staging;

• production.

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

7. Перевірка після розгортання

Після релізу корисно перевірити, чи працює застосунок у новому середовищі:

• виконати smoke-тести;

• перевірити доступність основних endpoint;

• перевірити метрики;

• переглянути журнали;

• переконатися, що критичні функції доступні.

Середовища та просування змін

Зазвичай код не розгортають одразу на production. Спочатку він проходить через одне або кілька середовищ.

Наприклад:

Pull request
    ↓
CI-перевірки
    ↓
Staging
    ↓
Ручне підтвердження
    ↓
Production

Development

Середовище для щоденної роботи розробників. Воно може часто змінюватися й не завжди бути стабільним.

Testing

Середовище для автоматичних або ручних перевірок. Тут тестувальники можуть перевіряти нові функції до релізу.

Staging

Середовище, максимально схоже на production. Воно допомагає перевірити поведінку системи в умовах, наближених до бойових.

Production

Середовище, яким користуються реальні користувачі. Зміни тут потребують особливої уваги, моніторингу та плану відновлення.

Безпека в CI/CD

Pipeline працює з кодом, доступами та інфраструктурою, тому його потрібно захищати.

Секрети

Паролі, токени, ключі та рядки підключення не можна зберігати у відкритому вигляді в репозиторії.

Замість цього використовують захищене сховище секретів CI/CD-платформи. Також варто:

• надавати доступи лише на потрібному етапі;

• обмежувати права токенів;

• регулярно оновлювати ключі;

• не виводити секрети в журнали;

• не передавати секрети неперевіреним скриптам.

Залежності

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

Права доступу

Сервіс, який розгортає застосунок, не повинен мати більше прав, ніж необхідно. Наприклад, pipeline для тестового середовища не обов’язково має отримувати повний доступ до production.

Надійність і відкат

Навіть добре протестована зміна може спричинити проблему. Тому CI/CD має передбачати відновлення.

Корисні механізми:

• зберігання попередніх артефактів;

• версіювання релізів;

• швидкий rollback;

• blue-green deployment;

• canary deployment;

• перевірки стану після розгортання;

• автоматичне зупинення rollout при погіршенні метрик.

Blue-green deployment

Створюють два середовища:

• одне обслуговує поточну версію;

• друге отримує нову версію.

Після перевірки трафік перемикають на нове середовище. Якщо виникає проблема, трафік можна повернути назад.

Canary deployment

Нову версію спочатку отримує невелика частина користувачів. Команда спостерігає за помилками та метриками, а потім поступово збільшує частку трафіку.

CI/CD і гілки Git

Організація гілок впливає на складність pipeline.

Поширений варіант:

• кожна функція розробляється в окремій гілці;

• pull request запускає CI;

• після перевірки зміни об’єднуються в основну гілку;

• зміни з основної гілки автоматично потрапляють на staging;

• production-реліз запускається після підтвердження або створення тега.

Важливо не просто обрати модель гілок, а домовитися про зрозумілі правила:

• які перевірки є обов’язковими;

• хто може схвалити зміни;

• коли запускається реліз;

• що робити з невдалим pipeline;

• як виконувати відкат.

Як запровадити CI/CD у проєкті

Не обов’язково одразу автоматизувати весь процес. Краще рухатися поступово.

Крок 1. Зафіксувати ручний процес

Опишіть, як зараз відбувається реліз:

• які команди запускаються;

• у якому порядку;

• які файли потрібні;

• які дії виконуються вручну;

• де найчастіше виникають помилки.

Крок 2. Автоматизувати базові перевірки

Почніть із коротких і важливих перевірок:

• встановлення залежностей;

• форматування;

• статичний аналіз;

• основні тести;

• збирання.

Крок 3. Додати перевірки для pull request

Це не дозволить об’єднати зміни, які не пройшли обов’язкові перевірки.

Крок 4. Створити відтворюване збирання

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

Крок 5. Додати staging

Після успішного CI розгортайте застосунок у середовище, де його можна перевірити до production.

Крок 6. Автоматизувати production-реліз

Коли процес стане зрозумілим і стабільним, можна додати автоматичне або ручне розгортання у production.

Крок 7. Додати моніторинг і rollback

Автоматичний реліз без спостереження за системою може лише швидше доставляти проблеми користувачам.

Поширені помилки

Автоматизувати хаотичний процес

Якщо ручний реліз незрозумілий, його автоматизація просто перетворить хаос на складний скрипт.

Спочатку варто описати процес і прибрати зайві кроки.

Запускати лише один тест

Зелений статус одного тесту не означає, що застосунок повністю справний. Перевірки мають відповідати реальним ризикам системи.

Робити pipeline надто довгим

Якщо базові перевірки тривають годину, розробники можуть почати їх обходити. Швидкі перевірки варто запускати першими, а довгі — паралельно або на окремих етапах.

Зберігати секрети в репозиторії

Секрет, випадково доданий у Git, потрібно вважати скомпрометованим навіть після видалення файлу. Його слід відкликати та замінити.

Збирати застосунок окремо для кожного середовища

Якщо для staging і production виконуються різні збирання, результати можуть відрізнятися. Надійніший підхід — перевірити конкретний артефакт і просувати саме його між середовищами, якщо це відповідає архітектурі проєкту.

Не мати плану відкату

Помилка в production рано чи пізно трапиться. Команда має заздалегідь знати, як повернути попередню версію.

Вважати CI/CD заміною code review

Автоматичні перевірки аналізують лише те, що для них налаштовано. Вони не замінюють обговорення архітектури, вимог і підтримуваності коду.

Видавати pipeline надмірні права

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

Як зрозуміти, що CI/CD працює добре

На якість процесу вказують не кількість етапів і не складність конфігурації, а практичні результати:

• зміни інтегруються часто;

• помилки знаходять до production;

• pipeline має зрозумілий результат;

• невдалий реліз можна швидко відкотити;

• час від коміту до доставки передбачуваний;

• команда не боїться виконувати реліз;

• доступи та секрети захищені;

• після розгортання є моніторинг.

Корисно також вимірювати:

• частоту релізів;

• час від зміни до розгортання;

• частоту невдалих змін;

• середній час відновлення після проблеми.

Ці показники допомагають оцінити процес на основі фактів, а не вражень.

Підсумок

CI/CD — це спосіб організувати шлях коду від зміни до користувача.

• CI автоматично інтегрує зміни та перевіряє їх.

• Continuous Delivery готує кожну успішну зміну до релізу.

• Continuous Deployment автоматично розгортає перевірені зміни у production.

• Pipeline описує послідовність кроків: перевірки, тести, збирання, доставка та розгортання.

• Надійний CI/CD потребує не лише автоматизації, а й безпеки, моніторингу та плану відкату.

Найкраще починати з малого: автоматизувати тести й збирання, додати перевірки для pull request, а потім поступово автоматизувати доставку та production-релізи.