Ответ
В моих проектах деплой — это отдельный, завершающий этап CI/CD пайплайна, следующий после успешной сборки и тестирования. Я строил процесс по принципу многоступенчатых окружений.
Типичный пайплайн выглядел так:
- Build: Сборка артефакта (например, Docker-образа) и его публикация в реестр (Artifactory, ECR, GCR).
- Test: Запуск юнит-тестов, статического анализа кода (SAST) и проверки уязвимостей зависимостей (SCA).
- Deploy to Staging: Автоматический деплой собранного образа в staging-окружение (например, отдельный namespace в Kubernetes). Там запускались интеграционные и нагрузочные тесты.
- Deploy to Production: После успешных тестов в staging и ручного аппрува (или по условию, например, тегу) — деплой в production. Часто использовалась стратегия blue-green или canary-деплоя через ArgoCD или Flux для минимизации downtime.
Пример сегмента пайплайна GitLab CI для деплоя в staging:
deploy:staging:
stage: deploy
image: bitnami/kubectl:latest
script:
# Применяем манифесты, предварительно подставив актуальный тег образа
- envsubst < k8s/deployment.yaml | kubectl apply -f - --namespace=staging
# Ждем, пока поды перейдут в состояние Ready
- kubectl rollout status deployment/my-app --namespace=staging --timeout=120s
only:
- main # Автодеплой в staging при пуше в main
environment:
name: staging
url: https://staging.my-app.comКлючевая идея — деплой не единичное событие, а стандартизированная, повторяемая и откатываемая процедура, интегрированная в общий поток доставки.