ステージングデータベースのグッドプラクティス
かなり複雑なサイトを本番環境にデプロイしようとしていますが、特にローカルで実行できない一部の外部サービスに関して、より現実的な環境でテストできるステージング環境が初めて必要になります。
私の一般的な計画は、最初にローカルで開発およびテストし、単純な変更（小さなバグ修正、HTML/CSS、JSなど）を本番環境に直接プッシュし、大きな変更については、最初にステージングサブドメインにプッシュして徹底的なテストを行い、次に本番環境にプッシュすることです。
ステージングデータベースと本番データベースの同期を維持する必要はないと思いますが（手動で更新する場合もあります）、本番環境に関連してステージング環境を維持することに関して一般的なグッドプラクティスがあるかどうか疑問に思います。特にデータベースに関しては。
一般的な考え/アドバイス/経験をいただければ幸いです。
更新：
コメントをありがとう、私は要点を理解します。これについて考えるのは少し時間がかかる価値があると思います。人気のある答えを受け入れました。
ステージングをバイパスして本番環境に変更を加えることは、災害と不使用のレシピです。これらの変更を行うと、マイナーの定義が変更され始めます。次に、2つの環境が離れると（つまり、ステージングが本番環境と一致しなくなると）、問題が発生し、ステージング環境への信頼が失われます。ステージングサーバーを最大限に活用するには、ステージングサーバーへの自動展開を実行し、完全にテストしてから、（変更がどれほど小さくても）本番環境に展開（自動化）する必要があります。また、完全な環境が可能な限り類似していることを確認し、その状態を維持する必要があります。これには明らかにDBが含まれます。私は通常、DBを維持するために（サイトまたはアプリをビルドする頻度に応じて）毎日または1時間ごとに同期をセットアップし、ビルドプロセスの一部としてこれを実行することがよくあります。
展開プロセスのすべてのステップを支援するソフトウェア tool を開発している人として、ステージング環境に関しては、本番環境をミラーリングすることがベストプラクティスであると言えます正確に。これには、同一のデータベーススキーマ（データは関係ありません。バックアップ/更新は問題ない場合があります）、同じオペレーティングシステムのバージョン、更新されたサービスパック、Webサーバー設定などが含まれます。
理想的な世界では、ステージング環境の目的は本番環境へのデプロイメントをテストすることだけであるため、ステージングで機能テストまたはユーザー受け入れテストを実行する必要はありません。ただし、実際の世界では、ステージング環境が機能環境またはUAテスト環境でもあることが許容される場合があります。
本番サーバーの設定を変更したり構成を変更したりするたびに、ステージングサーバーの設定を変更する必要があります。これにより、アプリケーションをステージングにデプロイできる場合、エラーなしで本番環境にデプロイできる可能性が高くなります。