AFAIKステージングの展開は、Azureの役割をテストすることを目的としています。これは、コードにエラーがある役割をステージングに展開できることを意味します。そのエラーが私のデータを損傷する場合、私は失敗する可能性があります。
どうすればそれに対処できますか？妥当なデータがないと役割をステージングできず（テストが困難）、不安定な役割でデータを損傷させることはできません。
ステージング用に別のデータセットを維持する必要がありますか？この問題は通常どのように解決されますか？
2 に答える
2
AFAIKステージングの展開は、Azureの役割をテストすることを目的としています。これは、コードにエラーがある役割をステージングに展開できることを意味します。そのエラーが私のデータを損傷する場合、私は失敗する可能性があります。
ステージングは、実際には展開の場所として設計されています。つまり、仮想IPアドレスを瞬時に交換する前に新しい役割インスタンスを起動するためです。そこでいくつかのテストを行うことができますが（たとえば、デプロイメントが有効であることを最終的にチェックするなど）、多くのテストを実行できるようにするためのテストは実際にはありません。
どうすればそれに対処できますか？妥当なデータがないと役割をステージングできず（テストが困難）、不安定な役割でデータを損傷させることはできません。
私は通常、偽のデータを使用する開発環境でテストしたか、偽のデータを使用して別のAzureサービスとしてデプロイしました。ただし、これは、テストに大量のデータが必要な状況ではなかったことを認めます。通常、これらのテストは、1人または2人のユーザーによるテスト展開です。
于 2011-07-21T09:12:27.427 に答える
1
環境としてのステージングは、データを含む本番環境を正確にシミュレートすることを目的としています。
次の戦略があります。本番環境は本番環境であり、ステージングはステージングと同じDBに接続されます。これは、Azureの更新が同じように機能するためです。つまり、ステージングデプロイメントをアップグレードし、クライアントに再度検証する機会を与えてから、VIPをデプロイメントと交換して、アプリケーションをシームレスに移行できるようにしたいということです。そのため、データベースに重大な変更があった場合は、新しいデプロイメントをまとめて作成するか、本番デプロイメントをオフにして、ユーザーにメンテナンス通知を提供することにしました。
最終的にそれはあなたが決めるものです。ただし、繰り返しになりますが、Azureのステージングとは何かを念頭に置いて、データを実際に維持し、ベータアクセスの「プログラム」と見なすことをお勧めします。もちろん、他の要件がない限り。しかし、それは要点を超えています。
于 2011-07-22T22:59:19.083 に答える