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

Этапы и процессы деплоя в современных DevOps-практиках

В современной CI/CD (Continuous Integration/Continuous Delivery/Deployment) практике деплой — это не единичное событие, а результат сквозного, автоматизированного конвейера. Понятие "этап" здесь многогранно: это и фаза в жизненном цикле ПО, и стадия в пайплайне, и конкретный процесс выполнения на инфраструктуре. Давайте разберем с разных ракурсов.

1. Деплой как этап жизненного цикла ПО (SDLC)

В классическом жизненном цикле (SDLC - Software Development Life Cycle) деплой — это финальный этап, следующий после разработки, тестирования и стабилизации. Его цель — передача проверенной и собранной версии приложения (артефакта) в среду, где с ним будут работать конечные пользователи (продакшн) или тестировщики (стейджинг). На этом этапе фокус смещается с создания функциональности на обеспечение её доступности, производительности и безопасности в целевой среде.

2. Деплой как ключевая стадия в CI/CD-пайплайне

В автоматизированном пайплайне деплой является ядром стадий Delivery или Deployment. Рассмотрим упрощенную схему пайплайна:

# Пример структуры .gitlab-ci.yml, отражающей этапы
stages:
  - build      # Сборка артефакта
  - test       # Запуск автоматических тестов
  - deploy     # Этап развертывания

deploy_to_staging:
  stage: deploy
  script:
    - ansible-playbook deploy.yml -e "env=staging"
  only:
    - main     # Срабатывает при мерже в main

deploy_to_production:
  stage: deploy
  script:
    - helm upgrade my-app ./chart --namespace production
  when: manual # Требует ручного подтверждения
  only:
    - tags     # Срабатывает только для тегов

Здесь этап deploy — это логическая группа заданий. Важно, что он часто разделяется на подэтапы:

• Деплой в тестовые среды (Staging, Pre-Prod): Происходит автоматически после успешного прохождения всех тестов. Цель — финальная проверка в среде, максимально приближенной к продакшену.
• Деплой в продакшен (Production): Может быть автоматическим (при полном Continuous Deployment) или ручным/утверждаемым (при Continuous Delivery). Часто используется канареечный деплой (canary) или синее-зеленое развертывание (blue-green) для минимизации рисков.

3. Процесс выполнения деплоя (последовательность действий)

Независимо от пайплайна, сам процесс деплоя включает несколько технических подэтапов:

1. Подготовка артефакта: Получение собранного и версионированного артефакта (Docker-образ, JAR/WAR-файл, пакет Helm) из артефакт-репозитория (Nexus, JFrog Artifactory, Container Registry).
2. Подготовка инфраструктуры (Provisioning): Обеспечение готовности целевой среды. На этом подэтапе может применяться IaC (Infrastructure as Code) (Terraform, Pulumi) для создания ресурсов или инструменты оркестрации (Kubernetes) для проверки наличия необходимых namespace, секретов, хранилищ.
3. Конфигурация (Configuration): Применение корректных настроек (конфигов) и секретов для целевого окружения. Используются инструменты вроде Ansible, Chef, Puppet или нативные механизмы Kubernetes (ConfigMaps, Secrets).
4. Развертывание приложения (Application Deployment): Непосредственная установка или обновление версии приложения. Пример для Kubernetes:

   # Использование Helm (пакетный менеджер для K8s)
   helm upgrade --install my-app ./my-chart --values production-values.yaml
   
   # Или с использованием kubectl для canary-деплоя
   # 1. Развертывание canary-версии с 10% трафика
   kubectl apply -f my-app-canary-deployment.yaml
   kubectl apply -f my-app-canary-service.yaml
   # 2. После проверок — постепенное увеличение трафика и замена основного деплоя
   

5. Верификация и пост-деплойные проверки (Smoke/Health Checks): Убедиться, что приложение не просто запущено, но и функционирует корректно. Выполняются автоматические проверки:

   # Проверка готовности эндпоинтов
   curl -f http://$SERVICE_URL/health || exit 1
   # Проверка метрик или логов на наличие критических ошибок
   

6. Откат (Rollback) при неудаче: Критически важный подэтап. В случае провала проверок автоматически или вручную запускается процедура возврата к предыдущей стабильной версии.

   # Откат релиза Helm
   helm rollback my-app 1
   
   # В Kubernetes можно просто применить манифест предыдущего деплоя
   kubectl apply -f previous-deployment.yaml
   

Ключевые принципы современного деплоя

• Идемпотентность: Многократный запуск процесса деплоя с одними и теми же артефактами должен приводить к одинаковому результату.
• Версионирование: Каждый артефакт, конфигурация и манифест инфраструктуры имеет уникальную версию, что гарантирует повторяемость и упрощает откат.
• Неизменяемость (Immutable Infrastructure): Вместо изменения состояния существующих серверов или контейнеров развертывается новая, полностью собранная и протестированная версия образа. Это повышает надежность и предсказуемость.

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