Расскажи как происходил деплой на твоем проекте

Процесс деплоя на проекте: от кода до продакшена

На моем последнем крупном проекте (высоконагруженное SaaS-приложение) был реализован полностью автоматизированный CI/CD пайплайн, построенный на философии «deploy as code» и GitOps. Мы использовали гибридную облачную инфраструктуру (Kubernetes в GCP + собственный дата-центр для legacy-компонентов). Весь процесс был разбит на четкие стадии и обеспечивал деплой до 50 раз в день с минимальным даунтаймом.

Ключевые принципы и стека технологий

• Принципы: Infrastructure as Code (IaC), GitOps (артефакт деплоя — git-репозиторий), blue-green/канареечные деплои, всё в контейнерах, строгое версионирование всех артефактов.
• Стек: GitLab CI/CD (как основной оркестратор), Kubernetes (основная платформа), Helm (пакетирование), ArgoCD (деплой в k8s по GitOps), Terraform (облачная инфраструктура), Docker, SonarQube, Trivy, Nexus (артефакты), Prometheus/Grafana/Loki (мониторинг), Slack (уведомления).

---

Подробный процесс деплоя (CI/CD Pipeline)

Пайплайн активировался автоматически при пуше кода в ветку develop (тестовый стенд), release/* (стэйджинг) или main (продакшен). Вот его ключевые стадии:

1. Stage: Build & Test (Сборка и базовое тестирование)

# Упрощенный пример .gitlab-ci.yml
stages:
  - build
  - test
  - security-scan
  - package
  - deploy

build-job:
  stage: build
  image: docker:latest
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  only:
    - branches

• Сборка: Для каждого коммита создавался уникальный Docker-образ, тегируемый хэшем коммита ($CI_COMMIT_SHA). Это обеспечивало неизменяемость и трассируемость.
• Unit-тесты: Запускались в том же контейнере. При неудаче пайплайн останавливался.
• Анализ кода: Интеграция с SonarQube для проверки качества и покрытия кода.

2. Stage: Security & Package (Безопасность и пакетирование)

• Сканирование уязвимостей: Инструмент Trivy проверял собранный Docker-образ на наличие известных CVE в базовых слоях и зависимостях. Критические уязвимости блокировали деплой в продакшен.
• Пакетирование: Приложение упаковывалось в Helm-чарт. Вместо подстановки тега образа в шаблонах, использовался подход с зависимостями. Значение image.tag в values.yaml обновлял отдельный скрипт, и обновленный чарт пушился в отдельный Git-репозиторий (наш «source of truth» для деплоя).

  # Пример скрипта обновления версии в чарте
  yq eval '.image.tag = "$CI_COMMIT_SHA"' -i ./chart/values.yaml
  git add ./chart/values.yaml
  git commit -m "Update image to $CI_COMMIT_SHA"
  git push origin main
  

3. Stage: Deploy to Staging (Деплой на стэйджинг)

• Для веток develop и release/* деплой был прямым и автоматическим через GitLab CI. Мы использовали kubectl или helm upgrade для обновления нужного namespace в dev- или staging-кластере Kubernetes.
• После деплоя запускался набор интеграционных и API-тестов (на Python + Pytest), чтобы убедиться, что ключевые функции работают.
• Важно: На этой стадии также применялись канареечные деплои для критичных сервисов. Трафик постепенно переводился на новую версию, а метрики (ошибки, latency) внимательно мониторились в Grafana.

4. Stage: Production Deploy (Продакшен-деплой)

Продакшен-деплой инициировался либо вручную из интерфейса GitLab (для release/*), либо автоматически при мерже в main (для некритичных фич). Здесь в игру вступал GitOps с ArgoCD:

1. АргоCD непрерывно мониторил наш Git-репозиторий с Helm-чартами.
2. Как только в main появлялся новый коммит с обновленным values.yaml, АргоCD автоматически синхронизировал состояние кластера с желаемым из репозитория.
3. Мы использовали стратегию Blue-Green деплоя для критичных user-facing сервисов:

   # Аннотация для сервиса Istio (пример)
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: my-app
   spec:
     hosts:
       - my-app.example.com
     http:
       - route:
           - destination:
               host: my-app-blue
             weight: 100 # Старая версия
           - destination:
               host: my-app-green
             weight: 0   # Новая версия
   

    *   Новая версия (`green`) разворачивалась параллельно со старой (`blue`).
    *   После успешных health-чеков и, возможно, ручного smoke-тестирования, мы вручную переключали вес трафика со 100/0 на 0/100 в интерфейсе **ArgoCD Rollouts** или через Istio VirtualService. В случае проблем — мгновенный откат (переключение весов обратно).

5. Post-Deploy (Пост-деплойные действия)

• Мониторинг: Сразу после переключения трафика команда наблюдала за ключевыми дашбордами в Grafana (ошибки 5xx, время ответа, бизнес-метрики).
• Уведомления: В Slack автоматически приходило сообщение об успешном деплое с ссылками на коммит, пайплайн и дашборды.
• Откат: Основной механизм отката — либо переключение обратно в Blue-Green, либо откат коммита в Git-репозитории чартов, после чего ArgoCD автоматически возвращал предыдущую версию (основное преимущество GitOps).

---

Культура и практики

• Неизменяемая инфраструктура: Никто не мог зайти в прод и «подправить» конфиг вручную. Все изменения — только через код в Git.
• Ответственность разработчиков: Разработчики сами отвечали за свой код «до прода», включая написание тестов, мониторинг и, при необходимости, откат.
• Декларативность: Весь желаемый стейт системы (версии приложений, конфиги) описывался в Git. Это давало полную аудиторию изменений и простоту восстановления.

Такой подход минимизировал человеческий фактор, ускорял поставку ценности бизнесу и обеспечивал высокую стабильность и предсказуемость продакшен-окружения.