Как выглядит процесс релиза в CI/CD?

В моей практике процесс релиза в CI/CD — это полностью автоматизированный конвейер, который начинается с мержа кода в основную ветку и заканчивается деплоем в прод. Я выстраиваю его так, чтобы минимизировать ручной труд и риск ошибок.

Типичные этапы пайплайна:

1. Сборка и статический анализ: Компиляция, линтинг, проверка зависимостей (например, npm run build).
2. Запуск автоматических тестов: Параллельный прогон юнит- и интеграционных тестов. Если они не проходят, пайплайн останавливается.
3. Деплой на staging-окружение: Автоматическая выкладка артефакта на среду, максимально похожую на прод.
4. Запуск регрессионных и E2E-тестов: На staging-среде запускаются более тяжелые UI- или сквозные тесты (например, на Selenium или Cypress).
5. Релиз в прод: Часто выполняется вручную (кнопкой) после проверки на staging. Использую стратегии для снижения риска:
   • Canary-релиз: Новая версия разворачивается на небольшом проценте трафика (например, 5%), и мы мониторим метрики.
   • Blue-Green: Есть два идентичных прод-окружения (синее и зеленое). Трафич переключается между ними мгновенно, что позволяет быстро откатиться.

Пример конфигурации пайплайна в GitLab CI для веб-приложения:

stages:
  - build
  - test
  - deploy-staging
  - deploy-prod

build-job:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

unit-test-job:
  stage: test
  script:
    - npm run test:unit

deploy-staging-job:
  stage: deploy-staging
  script:
    - scp -r dist/* user@staging-server:/var/www/app
  only:
    - main

deploy-prod-job:
  stage: deploy-prod
  script:
    - ./scripts/blue-green-deploy.sh
  when: manual # Требует ручного подтверждения
  only:
    - main

Ключевые принципы: всё, что можно, автоматизировано; каждый коммит в main потенциально готов к релизу; откат должен быть быстрым и простым.