理想
開発者は、自分のローカルで、プログラムに対する変更を試してみます。
いわば開発環境になります。そこで試してみてから、行けそうな気がしたら、
その変更をステージングサーバにまで持っていきます。デプロイって言うでしょう。
この時、ステージングってのは、あくまで本番のテスト環境になります。
スペックも設定もいくつか違うのがありますが、OSやミドルウェアのバージョンなどが基本的に揃っていて、
本番に適用したい変更の全てを、この環境でテストすることになります。
なので、教科書ではいつも、「ステージング＝プロダクション」を前提として設定しています。
僕もそう教えてもらいました。
現実は？
違う。違う。めちゃめちゃ違います。
基本的な構成が一緒だとしても、ステージングって、一人で使う環境じゃないので、環境が想定と違う場合がありえます。
他の開発者が試しで作って、テストが終わっても、そのまま放置したりすることが十分あり得るからです。
プロダクションとステージングがまったく一緒だという想定の上で行われたステージングテストって、実際プロダクションでは
どれぐらい意味があるのでしょうか。
そもそも想定って、エンジニアにとってはかなり怖いことかも知れません。想定ってのは、あくまで人間、詳しく言えば思考の主体として人間が
無意識的に決めている、他人とは共有できない自分だけの思考の枠である恐れがあるからです。
誰もバグを望んでいないです。意図したバグってありえないです。じゃ、なんでバグが発生するのか？そこが人間の想定って認識の死角です。
例えば、プロダクションの環境では、定期的にクーロンが動ぎ、別のサーバからデータの同期してくると考えてみましょう。
ステージングでもそういう定期的なジョブが設定されているでしょうか？
されてなかったら、その時点でアウトですね。しかも、ステージング上はテストのために、人間が手動でデータをベッドのディレクトリ転送したりする仕組みであれば、もうその時点で、真のテストは難しくなるかも知れません。
どうすべきか？
ローカルは置いといて、ステージング環境でのテストが、本番のテストにならない。なら、ステージングとプロダクションの環境って、
そもそも違うってことを常に意識するのが答えになるんじゃないかなと思います。
特定のモジュールを修正するプロジェクトがあるとしたら、最初の見積もりとして、両環境の差を確認する課題を用意したらどうでしょうか。
かなりプロジェクトの進捗に影響を及ぼすかも知れません。
１．ファイルやディレクトリ構成は同一なのか。
２．モジュールのバージョンは同一なのか。
とかを事前に考えてみて、想定ってものの正確さを高めることができるのであれば、リリースの直前発生して、皆バタバタすることになる
原因を、一つでも縮められるのではないでしょうか。