2011-08-08 4 views
1

当社のクライアントのWindows Server 2008 IIS 7 Webサーバー上のリッチクライアントアプリケーション(主にASP.NET、WCFサービス、およびASP.NET AJAXで作成)の更新をリリースしています。しばらくして、私たちは大量のアップデートをリリースしています。また、リリース直後にユーザーがキャッチしたバグが、自動化テストやステージテストでは検出されないこともあります。影響を受けていないコードを含むワークフローを中断することなく、ユーザーが引き続きIIS 7にASP.NETコードを円滑に展開する方法はありますか?私はステージから(web.configなしで)手動でコードをコピーして実動ウェブのルートフォルダに貼り付けるだけで、誰も実際に起動しないことに気付きました。しかし、私はアプリケーションで勤勉に働くユーザーのためにこの戦略に副作用があるかどうか疑問に思っています。私はちょうど他の接続が中断されるかどうか、あるいはそれらがこの状況で処理されているかどうか(例えば、SQL接続、WCFサービス呼び出し、それらが同じセッションを維持するかどうか、 ?この方法を選択した場合、web.configに、マスターページのすべてのユーザーにメッセージを表示するようなものがあります。「ログオフしてキャッシュをクリアしてください」というバナーのように彼らは対処された問題への更新を見るでしょう。しかし、これは影響を受けるユーザーにのみ関係します。IIS 7で新しくコンパイルされたASP.NET Webアプリケーションコードを展開してユーザーを蹴飛ばす方法はありますか?

これはマイナーなアップデートのための優れた戦略だと思っていて、デプロイメントが行われている間にユーザーに別のサーバーや何かを強制するweb.config設定を変更するなど、より良い戦略があります。または他の方法論では、私の耳は聞いています。明らかに後者はより安全に聞こえるが、私はこれがどのように行われるか分からない。私はロードバランスされたサーバーについて読んだことがありますが、このタイプのサーバー設定は、サーバーがダウンした場合など、さまざまな目的で実行されると思いますか?または、これはあなたが1つのサイトをダウンさせる最善のソリューションですか?どんな理想も大歓迎です。

答えて

3

私はリリースの最小限の影響についても強調していましたが、今は削除しています。現実は2つあります:

  1. あなたが更新しようとしているものではありません。これを考えてみましょう:ユーザーがx.aspxで作業していて、ポストバック中です。新しいx.aspxをドロップします。

  2. 十分な注意を払って、メンテナンスウィンドウは人生の手段です。ユーザーは、それはあなたが本当に何を知っていない時に空気中のすべてのプレートを保つためにあまりにも難しい

など、随時、更新を行うためにアプリケーションへの排他的アクセスを必要とする、ことを期待してください誰かが展開中に作業している可能性があります。特に、データベースの更新が混在している場合は!

+1

私はこれを実際の回答として受け入れます...私はあなたのSQLアップデートについて指摘しています..クライアントコードがSQLデータベースが期待して、地獄は緩んで破ることができます! – MacGyver

3

ミックスにロードバランサがある場合は、古いコードのサーバーを削除し、新しいコードのサーバーを追加します。これにより、人を蹴飛ばさずに、古いコードサーバー上でトラフィックが消滅します。新しいサーバーがトラフィックを取得します。

サーバーファームのすべてのコードを置き換えるまで、一度に1つのサーバーに新しいリリースでこれを行います。それは、実際の世界で焼くためのアプリケーション時間を提供します。問題が発生した場合は、単一のサーバーを元に戻すだけです。負荷バランスを使用すると簡単になります。

(通常は)シームレスな移行です。もちろん、アプリケーションがデータベースの変更などを処理できるかどうかを確認する必要があります。

+0

デプロイメントに単純な修正が含まれている(つまり、SQLの更新やWebサービスパラメータの変更などがない) – MacGyver

関連する問題