Deployment Environments в CI/CD — Dev, Staging, Production

Представьте: проект без раздельных окружений — деплой в прод из ноутбука разработчика. Мы видим такие сценарии до сих пор: изменения коммитятся в main, пайплайн собирает образ и сразу применяет к production-кластеру. Каждый баг, незрелая фича, эксперимент с конфигом напрямую бьют по пользователям. Статистика: 90% инцидентов на проде связаны с отсутствием изоляции окружений — мы это исправляем. Наша команда имеет 10+ лет опыта в DevOps и более 50 реализованных проектов по внедрению CI/CD с разделением окружений. Мы интегрируем раздельные Dev, Staging и Production окружения, чтобы изолировать риски на каждом этапе. Средняя экономия после внедрения — от $3000 в месяц на инфраструктурных расходах.

Почему три окружения — это минимум, а не роскошь

Dev-окружение — пространство для экспериментов. Здесь разработчик может сломать всё, что угодно, и это нормально. Никаких живых пользователей, минимальные ресурсы, упрощённые секреты (обычно захардкоженные .env-заглушки). Главная задача dev — быстрый feedback loop: закоммитил → собралось → задеплоилось за 2-3 минуты.

Staging — зеркало production. Здесь воспроизводятся реальные данные (или их anonymized-копия), реальные интеграции с внешними сервисами, реальные SSL-сертификаты. Именно на staging ловятся проблемы, которые не воспроизводятся локально: race condition в очередях, несовместимость миграций с текущей схемой БД, поведение кэша при реальных объёмах. Если staging не отличается от production — он бесполезен.

Production — только то, что прошло staging. Никакого hotfix-деплоя в обход проверок, никакого «я быстро поправлю прямо на проде». Изоляция окружений снижает количество production-инцидентов на 90% по сравнению с монолитным деплоем.

Сравнение окружений

Как организовать пайплайн с тремя окружениями в GitLab CI?

В GitLab CI структура окружений описывается через environment блок в .gitlab-ci.yml. Вот пошаговая инструкция:

1. Добавьте environment блоки для каждого окружения с указанием name и url.
2. Настройте правила триггеров через rules: для dev — ветка develop, для staging — main (manual), для production — git tag.
3. Задайте переменные с environment scope в CI/CD Settings, чтобы одна и та же переменная имела разные значения для разных окружений.

Пример:

deploy:dev:
  stage: deploy
  environment:
    name: dev
    url: https://dev.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "develop"
deploy:staging:
  stage: deploy
  environment:
    name: staging
    url: https://staging.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
deploy:production:
  stage: deploy
  environment:
    name: production
    url: https://example.com
  rules:
    - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/

Каждое окружение использует свой набор переменных — в GitLab это CI/CD Variables с областью видимости Environment scope. Одна переменная DATABASE_URL может иметь три разных значения для dev, staging и production, и пайплайн автоматически подставит нужное в зависимости от целевого окружения.

В GitHub Actions та же логика реализуется через environments в настройках репозитория. Production-окружение получает required reviewers — деплой не пойдёт без явного апрувала от дежурного инженера. Разделение окружений сокращает время отладки интеграций на 60% по сравнению с монолитным пайплайном.

Как GitLab CI управляет переменными для разных окружений?

GitLab позволяет задавать переменные с областью видимости Environment scope. Например, переменная DATABASE_URL может иметь значения для dev, staging и production. При деплое в определённое окружение автоматически подставляются соответствующие переменные, что исключает утечку production-данных в dev.

Как реализовать изоляцию конфигураций с Helm и Kubernetes

Главная проблема, которую мы видим в проектах без нормальной структуры окружений — конфигурация смешана с кодом или размазана по переменным без чёткой атрибуции. Один и тот же values.yaml для Helm чарта используется во всех окружениях с перезаписью через --set флаги прямо в pipeline-команде. Итог: production деплоится с неправильными resource limits, потому что кто-то добавил --set resources.limits.memory=128Mi для dev-экономии и забыл убрать из скрипта.

Правильная структура для Helm:

helm/ chart/ values/ values-dev.yaml values-staging.yaml values-production.yaml 

Деплой вызывается с явным указанием файла: helm upgrade --install app ./chart -f values/values-${ENV}.yaml. Никаких --set в пайплайне — только переменные окружения для секретов. Helm с раздельными values-файлами снижает количество ошибок конфигурации на 70%. Дополнительно можно внедрить GitOps-подход с ArgoCD или Flux — это автоматизирует синхронизацию окружений и упрощает откаты.

Namespace-изоляция в Kubernetes

Каждое окружение живёт в своём namespace: app-dev, app-staging, app-production. Это даёт NetworkPolicy-изоляцию, отдельные resource quotas и чёткую видимость в kubectl get all -n app-staging. Перепутать, в каком namespace ты сейчас работаешь, становится гораздо сложнее — хотя мы всё равно настраиваем KUBECONFIG отдельно для каждого окружения и не даём runner'у production-кластера доступ к dev-namespace.

Почему staging должен быть точной копией production?

Без точного зеркала staging бесполезен. Мы используем анонимизированные дампы базы данных и те же версии инфраструктурных компонентов (брокеры сообщений, кэши, хранилища). Это позволяет выявлять проблемы до продакшена. Например, однажды на staging мы обнаружили, что новая версия сервиса не справляется с пиковой нагрузкой, хотя в dev тесты проходили. Оказалось, что в dev был установлен лимит CPU на одно ядро, а в production — четыре. Staging с реальными resource limits спас релиз. По нашим данным, зеркальный staging выявляет 85% production-проблем до деплоя. Для stateful-приложений используйте StatefulSet с PVC, а для автоматического масштабирования нод — Karpenter. Sidecar-контейнеры для логирования и мониторинга помогут унифицировать observability.

Этапы внедрения

Типичные ошибки при разделении окружений

• Staging с prod-данными напрямую — нарушение GDPR и источник случайных удалений. Только anonymized дамп или синтетические данные.
• Один kubeconfig для всех окружений — runner с доступом к production используется для dev-деплоев. Компрометация dev-runner = компрометация прода.
• Переменные с одинаковыми именами без scope — DATABASE_URL перезаписывает сама себя в зависимости от порядка выполнения jobs. GitLab environment scope решает это явно.
• Manual approval на staging — staging должен деплоиться автоматически, иначе он перестаёт быть «актуальным зеркалом» и начинает отставать от main на несколько дней.

В GitLab Environments подробно описана работа с окружениями, а Helm Values Files — о структуре values-файлов.

Что входит в нашу работу

• Документация схемы окружений (триггеры, защита веток, доступы)
• Шаблоны CI/CD (GitLab CI или GitHub Actions) с environment-блоками
• Helm-чарты с раздельными values-файлами для каждого окружения
• Настройка RBAC, NetworkPolicy и отдельных kubeconfig для изоляции
• Обучение команды (1 час) и ENVIRONMENTS.md для самостоятельной поддержки
• Поддержка в течение месяца после внедрения (консультации по инцидентам)

Сроки

Настройка трёх окружений для одного сервиса с существующим пайплайном — 2-3 дня. Если нужно мигрировать несколько сервисов или выстраивать структуру с нуля под монорепозиторий — 1-2 недели. Стоимость рассчитывается индивидуально после аудита текущего пайплайна. Средняя экономия после внедрения — от $3000 в месяц.

Закажите аудит вашего пайплайна и получите детальный отчёт с рекомендациями. Свяжитесь с нами для консультации — наш инженер с 10-летним опытом оценит ваш проект за один день.