Окружения dev, staging и production: зачем нужно каждое
Основы3 минРедакция Innovialabs
Коротко
Dev — для разработки, staging — для проверки релиза в условиях, близких к боевым, production — для реальных пользователей. Разделение окружений ловит ошибки до клиентов, а одинаковая конфигурация и отсутствие реальных персональных данных на staging делают его полезным.
Коротко: зачем три окружения
Окружение — это отдельная копия приложения со своим сервером, базой, настройками и доменом.
- Dev (development) — место, где разработчики пишут и пробуют код. Может ломаться в любой момент.
- Staging — «генеральная репетиция». Здесь проверяют готовый релиз в условиях, максимально похожих на боевые.
- Production — рабочая система, с которой взаимодействуют реальные пользователи и деньги.
Смысл разделения простой: ошибка должна найтись до того, как её увидит клиент.
Чем отличаются окружения
| Dev | Staging | Production | |
|---|---|---|---|
| Кто пользуется | Разработчики | QA, менеджеры, заказчик | Клиенты |
| Стабильность | Низкая | Высокая на время проверки | Максимальная |
| Данные | Тестовые, сиды | Тестовые или обезличенные | Реальные |
| Деплой | Часто, из рабочих веток | Кандидат в релиз | Проверенный релиз |
| Внешние сервисы | Песочницы, заглушки | Песочницы платёжек и API | Боевые ключи |
Как держать окружения одинаковыми
Staging полезен, только если он действительно похож на production. Иначе «на стейдже работало» ничего не значит.
- Один и тот же артефакт. Собирайте Docker-образ один раз и продвигайте его по окружениям, а не пересобирайте под каждое.
- Инфраструктура как код. Описывайте серверы и сервисы в Docker Compose, Terraform или манифестах Kubernetes, чтобы окружения создавались одинаково.
- Разница — только в конфигурации. Адреса, ключи и флаги выносите в переменные окружения:
# .env.staging
APP_ENV=staging
DATABASE_URL=postgres://app@staging-db:5432/app
PAYMENT_MODE=sandbox
- Те же версии. База данных, runtime и ключевые сервисы на staging и production должны совпадать.
- Миграции через тот же пайплайн. Если миграция прошла на staging, она пройдёт и на production — при условии похожего объёма и структуры данных.
Данные на staging
Копировать боевую базу на staging «как есть» — частая и опасная ошибка: персональные данные клиентов оказываются в менее защищённом месте.
Варианты:
- Сиды и фикстуры — сгенерированные тестовые данные, достаточно для большинства проверок.
- Обезличенная копия — production-база, в которой имена, телефоны, email и платёжные данные заменены или удалены.
- Синтетические данные в нужном объёме — для проверки производительности.
Отдельно проследите, чтобы staging не отправлял реальные письма и SMS и не проводил настоящие платежи — используйте sandbox-режимы сервисов.
Минимальная схема для небольшой команды
- Локальная разработка у каждого разработчика через Docker Compose вместо общего dev-сервера.
- Один staging-сервер, куда автоматически деплоится основная ветка после прохождения тестов.
- Production, куда тот же образ уходит после проверки на staging — вручную по кнопке или по тегу релиза.
- Закройте staging от поисковиков и посторонних: базовая авторизация или доступ по VPN.
Этого достаточно, чтобы ловить большинство ошибок, не раздувая инфраструктуру.
Частые ошибки
- Staging годами отстаёт от production по версиям и настройкам.
- Секреты и ключи общие для всех окружений.
- Хотфиксы правятся прямо на production-сервере в обход пайплайна.
- Staging проиндексирован поисковиками и создаёт дубли страниц.