PreProdとProdの環境はどの程度似ている必要がありますか？

私は最近プロジェクトに参加したばかりで、リリース中に、それがプロダクションでは機能しないことに気づきました。他のすべての環境で動作しますが、別個のリリースチームがあり、サーバーと環境を自分でセットアップできないため、それらの構成を表示できません。

ProdのアカウントまたはIIS設定には異なるいくつかのユーザー権限があると思われるため、現在は作業しています。

だから私はこのすべてが私にとって学習経験であったと思います、そして同じことを再び繰り返されることを望みません。これらの環境はどのように異なるべきですか？PreProdは、同じユーザーアカウントのコピーを使用して同じデータベースのコピーを使用し、同じサーバーにインストールする必要があるなど、同じデータベースのコピーを使用してProd環境と同一のコピーである必要があると常に思っていました。

しかし、どれだけの距離を取るべきでしょうか？Webサイトが外向きの場合、PreProdは外向きにする必要がありますか？Webサイトに、ユーザーアカウントやパスワードを必要としないコンポーネントがある場合はどうなりますか？それを外の世界に公開しても大丈夫ですか？

可能な限り、本番サーバーと同じ環境でテストする必要があります。そうしないと、顧客が何を使用するかをテストすることにはなりません。他に何もない場合は、バグレポートをテストするためのそのような環境が必要です。

明らかに、同一にしたくないものもあります。支払いシステムへのリンクが思い浮かびますが、これらは本物であるかのようにあざけられるべきです。システムの規模など、複製できないものもあります。

外部URLを使用してテストすることもできます。ここでも、ユーザーに表示されるものをテストします。また、外部URLを介したテストでは、システムの内部使用とは異なる方法でネットワークを使用します。アクセス許可（たとえば）は、利用可能な帯域幅、ファイアウォールなどと同様に役割を果たします。すべてのユーザーが直面することになりますが、システムに直接アクセスする場合はスキップします。

ただし、アカウントとパスワードを必要としないコンポーネントには問題がありません。パスワードを必要としない場合、それは重要ではありません/重要ではありません、それが重要な場合は、なぜパスワードを取得していないのですか？

このためのベストプラクティスは、Blue Green Deploymentアプローチであり、Jez HumbleとDavid Farleyの著書 『Continuous Delivery』で作成され、Martin Fowlerのブログ投稿Blue Green Deploymentで説明されています。

前提は非常に簡単です。マーティン・ファウラーの投稿から：

青緑の展開アプローチ...できる限り同一の2つの実稼働環境があることを[保証]します。それらの1つ（例では青としましょう）はいつでもライブです。ソフトウェアの新しいリリースを準備するとき、グリーン環境でのテストの最終段階を行います。ソフトウェアが緑の環境で動作したら、ルーターを切り替えて、すべての着信要求が緑の環境に送られるようにします。青の環境はアイドル状態になります。

ブルーグリーンの展開は、ロールバックの迅速な方法も提供します。何か問題が発生した場合は、ルーターをブルー環境に戻します。

このアプローチは、同じ運用前環境と運用環境がないという問題を解決し、展開戦略を最適化します。

最終的な本稼働前の環境は、ロードバランサーから取り出されたライブサーバーの1つにすぎません。運用前ビルド（データベース接続文字列と他のいくつかの構成変更を除いて、基本的にライブビルドと同じです）を展開し、それをテストします。これで問題がなければライブコードをデプロイし、最後に問題がなければサーバーをロードバランサーに戻し、本番ビルドを残りのサーバーに1つずつデプロイします。

システム内の任意の時点で問題を特定できるように、それらは可能な限り類似している必要があります。ただし、スケーリングできない場合を除きます。できれば、本番環境と本番前/ステージング/テスト環境の唯一の違いはサイズです。本番環境は、大規模な環境ではさらに多くのマシンで構成されることを期待しています。データベースサーバーやWebサーバーなど、使用しているマシンの献身をミラーリングする必要もあります。

ただし、現在の予算では正確な複製ができない場合があります。近いほど、テストの効果が高まり、本番環境への移行中に問題が発生する可能性が低くなります。

この環境を一般に公開する必要がある場合、私はChrisFとは異なるスタンスをとります。それはいけないことだと私は言う。私は、実際のデータベースのコピー、または少なくとも実際のライブデータベースのサブセットのコピーと、内向きの環境で実行することを選択します。このようにして、実際の現実的なデータに対してテストでき、リークにつながるセキュリティホールを心配する必要がありません。もちろん、データをサニタイズすることもできますが、それによって環境から「ダーティデータ」が削除され、ライブシステムの欠陥の発見につながる可能性があります。

私が銀行、電気通信などで働いたことのあるところならどこでも、データベースは1週間ほど前のものを除いて、プリプロダクションはプロダクションの直接コピーでした。プリプロダクション全体のデータを維持するのは大規模なプロセスでしたが、プリプロダクションを実装した私が働いていた会社にとっては不可欠であると見なされていました。

AUバンキングセクションでは、政府はサービスの失敗に対して銀行に罰金を科します。たとえば、ウェブサイトのATMなどが毎分ダウンしています。インシデントに対して解雇された開発/テストチームの話を聞くのは珍しいことではありません。pre-prodは、すべての企業や開発プロセスに適しているわけではありませんが、一部の企業には不可欠です。