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