回答:
中小企業（自社の規模が明確ではない）の場合、3つの環境（開発、ステージ、プロダクション）が一般的です。大企業では、開発とステージの間にQA環境があることがよくあります。
これらは通常、次のように分類されます。
dev：作業コードのコピー。開発者が行った変更はここにデプロイされるため、統合と機能をテストできます。この環境は迅速に更新され、アプリケーションの最新バージョンが含まれています。
qa：（すべての企業がこれを持っているわけではありません）。品質保証のための環境。これにより、テスターがチェックを実行できるアプリケーションの変更頻度が少なくなります。これにより、共通のリビジョンに関するレポートを作成できるため、開発者は、テスターが発見した特定の問題が開発コードですでに修正されているかどうかを知ることができます。
ステージング：これはリリース候補であり、この環境は通常、実稼働環境のミラーです。ステージング領域には、アプリケーションの「次の」バージョンが含まれており、稼働前の最終ストレステストとクライアント/マネージャーの承認に使用されます。
production：これは現在リリースされているアプリケーションのバージョンで、クライアント/エンドユーザーがアクセスできます。このバージョンは、予定されているリリース中を除いて変更しないことが望ましい。
ステージングに昇格する前にコードを移動する場所として、テスト環境も存在しないことに少し驚いています。
質問に答えるには：
ステージ環境は、本番環境を可能な限り厳密にミラー化する必要があります。
これは、デプロイメント手順の検証に使用されます。コードが本番稼働準備ができたら、問題を引き起こすことなくデプロイできることを確認します。
つまり、コードはステージングに進みます-これは、展開が計画どおりに行われたことを確認するために、包括的にテストおよび回帰されます（そうでない場合は問題を解決します）。
米国政府/国防総省ITでの私の経験は次のとおりです。
Web開発者として、実際に考慮する主な3つの環境があります。
本番：エンドユーザーを対象とした製品の最終リリースバージョンをホストするように構成された環境。セキュリティとパフォーマンスのために最適化されています。ライブサーバーでホストされています。緊急のサポートが必要です。データが重要です。したがって、そのデータは定期的にバックアップされます。また、リスク管理と災害復旧も含まれます。実稼働環境は、エンドユーザーにわかりやすいエラーを表示するように構成されています。
ステージング：コードのフリーズを宣言した後、アプリケーションのリリース候補をホストするように構成された環境。リリース候補の範囲に同意するために、開発チームとともにプロジェクトマネージャー/所有者を対象としています。これには、品質保証が含まれ、また、開発チームが本番環境にリリースする前に最終修正と最終備品を行う必要があります。ベストプラクティスは、運用環境からコピーされたライブDBから利用可能な最新のデータを使用して、運用環境を模倣することです。通常、ステージング環境は内部チームと利害関係者のみがアクセスできるため、すべての利害関係者がローカルネットワークにアクセスできる場合は、パブリックサーバーで保護されるか、イントラネット環境で公開されます。ステージング環境は、中程度または完全な技術的エラーを表示するように構成されています。
開発：開発サイクル（通常、スクラム環境ではスプリントと呼ばれます）の間に自分の作業をチェックするために、マシン上の1人の開発者によって構成されたプライベート環境。開発環境は、完全な技術的エラーを表示するように構成されています。