Що таке CI/CD: пояснення безперервної інтеграції й доставки

Що таке CI/CD і чому без нього команда страждає

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

CI (Continuous Integration) вирішує першу частину: кожен коміт автоматично тестується і збирається. Не треба чекати, поки хтось вручну перевірить.

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

Проблеми без CI/CD

• Помилки знаходяться пізно. Коміт зробили вчора, помилку знайшли сьогодні, вже 5 інших комітів зверху.
• «У мене працює» не працює. На локальному комп’ютері інше оточення, ніж на сервері.
• Деплой — це стрес. Якщо викочування робиться вручну раз на місяць, це завжди страшно і збої неминучі.
• Команда чекає. Без автоматизації комусь доводиться чекати, поки хтось інший запустить тести або зробить реліз.

Як працює pipeline

Pipeline — це ланцюжок кроків:

1. Push — хтось пушить код у репозиторій.
2. Test — автоматично запускаються тести. Якщо падають — pipeline зупиняється.
3. Build — код збирається (компіляція, бандл, Docker-образ).
4. Deploy to staging — перевірка на тестовому сервері.
5. Deploy to production — фінальне викочування (ручне або автоматичне).

Кожен крок має пройти → наступний запускається. Це як конвеєр: якщо деталь бракована, конвеєр зупиняється.

CI та CD — це не одне й те саме

CI (Continuous Integration)

Автоматично тестує код після коміту. Це база. Без CI ніякий CD не має сенсу.

Continuous Delivery

Код проходить через CI і автоматично готується до деплою. Фінальний крок — кнопка «Викотити» — натискається вручну. Добре для більшості команд.

Continuous Deployment

Те саме, але навіть кнопка не потрібна: кожен успішний коміт йде у production автоматично. Потрібна висока довіра до тестів і моніторінгу.

З чого почати

Рівень 1: автоматичні тести

Найпростіший старт. Додай запуск тестів після кожного пушу. Якщо тести падають — розробник дізнається одразу.

# GitHub Actions
name: CI
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

Рівень 2: білд

Додай крок збирання після тестів:

  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build

Рівень 3: staging deploy

Після успішного білду — деплой на staging:

  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh staging

Рівень 4: production deploy

Ручний або автоматичний деплой у прод:

  deploy-prod:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh production

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

1. Починати з CD, коли немає CI

Без тестів автоматичний деплой — це рулетка. Спершу тести.

2. Довгі пайплайни без фідбеку

Якщо pipeline триває 40 хвилин, розробник вимкнеться й не побачить результат одразу. Тримай швидкий фідбек: тести — до 5-10 хвилин, білд — до 10.

3. Ігнорувати помилки в CI

Коли CI падає і команда звикла йтигнорувати — CI стає марним. Краще мати 5 тестів, які завжди проходять, ніж 500, які ігнорують.

4. Зловживати Continuous Deployment

Якщо тести покривають тільки 10% коду — автоматичний деплой у прод ризикований. Delivery (з кнопкою) краще для більшості команд.

Висновок / план дії

CI/CD — це не про технологію. Це про довіру. Коли ти довіряєш своїм тестам і процесам, деплой перестає бути страшною подією.

Що зробити найближчим часом:

1. Додай автоматичний запуск тестів після кожного коміту.
2. Переконайся, що розробники бачать результат CI (зелений / червоний).
3. Автоматизуй білд після успішних тестів.
4. Спробуй staging deploy як наступний крок.
5. Коли команда звикне — додай production deploy (з кнопкою або автоматично).

Не треба впроваджувати все одразу. Почни з тестів і будуй поступово.