Чем принципиально отличается окружение staging от production и почему нельзя тестировать новые изменения сразу в проде?

Короткий ответ

Staging — это окружение, максимально похожее на production по конфигурации и инфраструктуре, но изолированное от реальных пользователей, где можно безопасно проверить изменения перед релизом; production обслуживает реальный трафик, и ошибки там напрямую влияют на пользователей и бизнес.

Как это работает подробнее

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

Пример кода

example.yamlКопировать

deploy_staging:
  stage: deploy
  script: ./deploy.sh staging
  environment: staging
deploy_prod:
  stage: deploy
  script: ./deploy.sh prod
  environment: production
  when: manual
  needs: ["deploy_staging"]

Что использовать на практике

• На практике. staging не всегда идентичен production на 100% (объём данных, количество реплик, внешние интеграции), и это важно учитывать — некоторые проблемы (под нагрузкой, с редкими данными) staging не воспроизводит. Поэтому staging снижает риск, но не заменяет мониторинг и осторожные стратегии выкладки (canary, feature flags) в самом проде.
• Пример. Ожидаемое поведение: деплой в production возможен только после успешного `deploy_staging` и ручного подтверждения, что даёт возможность проверить работу на staging перед реальным релизом.

Подводные камни

• Частые ошибки. считают staging «необязательной формальностью» и пропускают его при спешке, из-за чего в прод попадают очевидные ошибки конфигурации; держат staging с сильно устаревшими данными или версией инфраструктуры, из-за чего он перестаёт быть репрезентативным.