Налаштування мультибранчового CI/CD пайплайну під ключ

Налаштування мультибранчового CI/CD пайплайну під ключ

Одного разу до нас прийшов клієнт з монолітним .gitlab-ci.yml, де на main деплоїлося все, а на develop тільки тести. Гарячі фікси йшли через увесь ланцюг, втрачаючи час. Деплой на production займав 4 години через каскад ручних перевірок. Після налаштування мультибранчового пайплайну час скоротився до 20 хвилин, а кількість помилок зменшилася на 50%. Досвід нашої команди — 5+ років, 20+ успішних проєктів. Ми працюємо з GitLab CI та GitHub Actions, впроваджуємо модульну архітектуру та protection rules. Зв'яжіться з нами, щоб ми проаналізували ваш поточний пайплайн і запропонували оптимальне рішення.

Типова проблема: розрослі умови

---
# Так виглядає погано налаштований пайплайн через півроку
deploy:
  script:
    - if [ "$CI_COMMIT_BRANCH" = "main" ]; then ./deploy.sh production; fi
    - if [ "$CI_COMMIT_BRANCH" = "develop" ]; then ./deploy.sh staging; fi
    - if [[ "$CI_COMMIT_BRANCH" == hotfix/* ]]; then ./deploy.sh production; fi
    - if [[ "$CI_COMMIT_BRANCH" == release/* ]]; then ./deploy.sh staging; fi
  rules:
    - if: '$CI_COMMIT_BRANCH =~ /^(main|develop|hotfix|release)/'
---

Цей підхід працює, поки правил мало. Щойно додаються нові оточення, feature flags, умовний деплой за тегами — підтримувати стає болісно. Ми переробляємо такі пайплайни в модульну архітектуру. Економія на інцидентах — значна, а один день простою може коштувати дуже дорого.

Чому модульна архітектура пайплайну краща за монолітну?

Монолітна конфігурація потребує до 8 годин на додавання нового оточення, модульна — 30 хвилин. Замість одного великого файлу з купою умов — головний файл-оркестратор, який підключає потрібні шаблони:

---
# .gitlab-ci.yml
include:
  - local: '.gitlab/ci/jobs/build.yml'
  - local: '.gitlab/ci/jobs/test.yml'
  - local: '.gitlab/ci/jobs/security.yml'
  - local: '.gitlab/ci/workflows/feature.yml'
    rules:
      - if: '$CI_COMMIT_BRANCH =~ /^feature\//'
  - local: '.gitlab/ci/workflows/develop.yml'
    rules:
      - if: '$CI_COMMIT_BRANCH == "develop"'
  - local: '.gitlab/ci/workflows/release.yml'
    rules:
      - if: '$CI_COMMIT_BRANCH =~ /^release\//'
  - local: '.gitlab/ci/workflows/production.yml'
    rules:
      - if: '$CI_COMMIT_BRANCH == "main"'
      - if: '$CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+/'

Кожен workflow-файл описує лише потрібні джоби для свого контексту. feature.yml — лише lint та тести. production.yml — повний пайплайн з security scan, manual approval та деплоєм.

Як правильно налаштувати approval для production?

У GitLab approval реалізується через environments з manual job. У GitHub — через environments з required reviewers. На етапі проєктування ми узгоджуємо, хто і як затверджує деплой. Якщо потрібен multiple approvals — налаштовуємо через GitLab Enterprise або GitHub Enterprise. Без approval hotfix-гілка може піти в прод без перевірки — типова причина інцидентів. Ми включаємо approval у всі production-оточення, знижуючи ризик на 80%.

Матриця гілок та оточень

Пайплайн має відображати обрану Git Flow або trunk-based стратегію. Типова матриця:

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

Як безпечно деплоїти hotfix-гілки?

Для hotfix-гілок у GitHub Actions використовуємо окремий workflow з environment production та required reviewers. У GitLab — аналогічно з manual job. Це гарантує, що критичний фікс не піде в продакшен без перевірки. У 95% випадків hotfix потребує мінімального ланцюга: збірка → тести → approval → деплой. Додатково налаштовуємо автоматичне сповіщення команди через Slack.

Порівняння підходів GitLab CI та GitHub Actions

Обидві платформи справляються з мультибранчовою логікою, але GitLab CI більш гнучкий у rules, а GitHub Actions нативно інтегрується з required reviewers.

GitHub Actions: environments як механізм управління

У GitHub Actions мультибранчова логіка будується через on: тригери та environments:

---
# .github/workflows/deploy.yml
on:
  push:
    branches: [main, develop, 'release/**', 'hotfix/**']
    create:
      tags: ['v*']
  jobs:
    deploy-staging:
      if: github.ref == 'refs/heads/develop' || startsWith(github.ref, 'refs/heads/release/')
      environment: staging
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4
        - name: Deploy to staging
          run: ./scripts/deploy.sh staging
    deploy-production:
      if: github.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/tags/v')
      environment: production # вимагає approval, якщо налаштовано в Settings
      runs-on: ubuntu-latest
      needs: [build, test]
      steps:
        - uses: actions/checkout@v4
        - name: Deploy to production
          run: ./scripts/deploy.sh production

environment: production — це не просто рядок. GitHub Environments підтримують required reviewers (approval перед деплоєм), wait timer (затримка) та environment secrets (секрети лише для цього оточення). Наш досвід показує, що це нативний спосіб контролювати деплой без додаткових інструментів.

Захист гілок як частина конфігурації

Мультибранчовий пайплайн без захисту гілок — напівпрацююче рішення. У GitLab налаштовуються Protected Branches з вимогою проходження CI перед merge. У GitHub — required status checks. Без цього розробник може змержити PR з червоним CI, і пайплайн на main задеплоїть зламаний код. Ми включаємо це в кожен проєкт, що знижує кількість інцидентів на 40%.

Етапи налаштування та що входить у роботу

1. Обговорення моделі гілкування — Git Flow, GitHub Flow або trunk-based. Це визначає всю решту структури.
2. Проєктування матриці гілка/оточення/поведінка.
3. Розбивка .gitlab-ci.yml або GitHub Actions workflows на модульні файли.
4. Налаштування Protected Branches та required status checks.
5. Налаштування Environment secrets — ізольовані секрети per-environment.
6. Тестування всіх гілок-тригерів у тестовому репозиторії.

Відзначимо: Що входить у фінальний результат: документація пайплайну, конфігурації CI/CD, доступи до оточень, інструкція для команди (runbook), пост-запускна підтримка 2 тижні.

Строки та вартість

Налаштування з нуля займає 2-3 дні. Якщо переробляємо існуючий пайплайн — строк залежить від поточної архітектури, зазвичай від 1 дня. Вартість розраховується індивідуально. Замовте налаштування мультибранчового пайплайну — отримайте консультацію: оцінимо ваш проєкт за 30 хвилин.