Що таке deploy pipeline і чому релізи без нього ламаються частіше

Hook

Deploy pipeline — це не про написання нового коду. Це про те, як акуратно доставити вже готовий build до staging і production без сюрпризів.

Problem / Context

CI вже перевірив код. А deploy pipeline бере готовий артефакт і проводить його через останню милю: staging, smoke test, approval gate і production. Саме тут найчастіше й починаються проблеми.

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

Схема, яку варто мати в голові

Deploy pipeline має просувати один і той самий готовий артефакт: спочатку в staging, потім через smoke test і approval gate, і лише після цього — у production. Rollback має бути частиною маршруту, а не аварійною імпровізацією.

Why it matters

Більшість релізних фейлів трапляється не в коді, а в доставці:

• не той тег образу;
• забутий env;
• пропущений smoke test;
• немає швидкого rollback;
• staging і production занадто різні.

Хороший deploy pipeline робить реліз повторюваним. Тобто сьогодні, завтра і через місяць ти проходиш той самий шлях, а не граєш у рулетку.

How to do it

1. Build once, deploy many

Спочатку збери один артефакт. Потім розгорни саме його в staging і production. Не перезбирай окремо для кожного середовища.

2. Перекидай лише готовий результат

Pipeline має працювати з тим, що вже пройшло build. Це може бути Docker-образ, zip-архів або статична збірка.

3. Перевір staging перед production

Спочатку реліз іде в staging. Там запускаються smoke tests, і тільки після цього артефакт просувається далі.

4. Постав approval gate там, де це потрібно

Для ризикових релізів корисний ручний крок підтвердження. У GitHub Actions це може бути environment protection, у Jenkins — input step, у GitLab — manual job.

5. Тримай rollback готовим

Rollback не має бути ідеєю «потім розберемося». Його треба знати до релізу і хоча б раз перевірити в staging.

Приклад простого GitHub Actions сценарію:

name: release
on:
  workflow_dispatch:
jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy the same artifact to staging
        run: ./deploy.sh staging myapp:${{ github.sha }}
      - name: Smoke test staging
        run: ./smoke-test.sh staging

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Promote the same artifact to production
        run: ./deploy.sh production myapp:${{ github.sha }}

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

Anti-patterns

• збирати окремо для staging і production;
• деплоїти сирий код замість готового артефакту;
• запускати production без smoke test;
• робити ручний реліз з п’яти кроків, які ніхто не пам’ятає;
• не тестувати rollback заздалегідь;
• змішувати міграцію, деплой і дрібні фікси в один незрозумілий крок.

Conclusion / Action plan

Deploy pipeline — це релізна доріжка, а не просто ще один job.

Що зробити далі:

1. відокремити build від deploy;
2. пропускати через pipeline лише готовий артефакт;
3. додати staging і smoke test;
4. поставити approval gate, якщо реліз ризиковий;
5. перевірити rollback до того, як він реально знадобиться.

Простіше кажучи

deploy pipeline = «безпечний маршрут від готового білді до користувачів».