ASP.NETアプリケーションをライブサーバーにどのように展開しますか？

私はあなたのASP.NET Webアプリケーションプロジェクト（デプロイするために使用するさまざまな技術/ツールを探していませ ASP.NETのWebサイト）の生産には？

継続的インテグレーションビルドサーバーが特定の場所にバイナリをドロップしてから、最初のユーザーリクエストがこれらのバイナリに到達するまでの間に発生するワークフローに特に興味があります。

1. 特定のツールを使用していますか、それともXCOPYを使用していますか？アプリケーションはどのようにパッケージ化されていますか（ZIP、MSIなど）？

2. アプリケーションが初めて展開されるとき、アプリプールと仮想ディレクトリをどのように設定しますか（手動で作成するか、またはツールを使用して作成しますか）？

3. 静的リソース（CSS、JS、またはイメージファイル）が変更された場合、アプリケーション全体を再デプロイしますか、それとも変更したリソースのみを再デプロイしますか？アセンブリ/ ASPXページが変更されたときはどうですか？

4. 特定のアプリケーションのすべてのデプロイ済みバージョンを追跡していますか。何か問題が発生した場合に、アプリケーションを以前の既知の動作状態に復元する手順はありますか？

前のリストを自由に記入してください。

ASP.NETアプリケーションを展開するために使用するものは次のとおりです。

1. ソリューションにWeb配置プロジェクトを追加し、ASP.NET Webアプリケーションを構築するように設定します
2. 私たちは、セットアッププロジェクト（追加しないソリューションにWebセットアッププロジェクトを）し、Web配置プロジェクトの出力を取るためにそれを設定します
3. カスタムインストールアクションを追加し、OnInstallイベントで、System.DirectoryServices.DirectoryEntryを使用してIISにアプリプールと仮想ディレクトリを作成するカスタムビルド.NETアセンブリを実行します（このタスクは、アプリケーションが初めて展開されるときにのみ実行されます） 。IISの複数のWebサイト、仮想ディレクトリの認証、およびアプリケーションプールのIDの設定をサポートしています。
4. TFSにカスタムタスクを追加して、セットアッププロジェクトをビルドします（TFSはセットアッププロジェクトをサポートしていないため、devenv.exeを使用してMSIをビルドする必要がありました）。
5. MSIがライブサーバーにインストールされている（以前のバージョンのMSIがある場合は、最初にアンインストールされます）

Setup Factoryを使用して、すべてのコードをMSIにデプロイしました。何かを変更する必要がある場合は、ソリューション全体を再展開します。これはcssファイルにとってはやり過ぎのように聞こえますが、すべての環境の同期を完全に保ち、本番環境にあるものを正確に把握しています（すべてのテストおよびuat環境に同じ方法で展開します）。

ライブサーバーへのローリングデプロイメントを行うため、インストーラープロジェクトは使用しません。CIのようなものがあります。

• 承認されたソースからの「ライブ」ビルドサーバービルド（リポジトリの「ヘッド」ではない）
• （バックアップを取った後;-p）
• robocopyはステージングサーバーに公開します（「ライブ」ですが、F5クラスターにはありません）
• ステージングサーバーで行われる最終検証。多くの場合、全体をできるだけ厳密にエミュレートするための「ホスト」ハッキングが行われます
• robocopy / Lは、次の "プッシュ"での変更のリストを配布し、任意の間抜けを警告するために自動的に使用されます
• スケジュールされたプロセスの一部として、クラスターが循環し、robocopyを介してクラスター内のノードにデプロイされます（クラスター外にある間）

robocopyは、変更のみがデプロイされることを自動的に保証します。

アプリプールなどについて; これを自動化したいのですが（この質問を参照）、現時点では手動です。でも本当に変えたいです。

（おそらく、独自のデータセンターとサーバーファームが "オンサイト"にあるため、多くのハードルを越える必要がありません）

ウェブサイト

デプロイヤ：http : //www.codeproject.com/KB/install/deployer.aspx

ウェブサイトをローカルフォルダーに公開し、zip圧縮してからFTP経由でアップロードします。次に、サーバーのデプロイヤーがzipを抽出し、（Web.Configおよびその他のファイル内の）構成値を置き換えます。

もちろん、最初の実行ではサーバーに接続してIIS Webサイト、データベースをセットアップする必要がありますが、その後の更新の公開は簡単です。

データベース

データベースの同期を維持するには、http：//www.red-gate.com/products/sql-development/sql-compare/を使用します

サーバーが多数のルーターの背後にあり、直接接続できない場合（SQL Compareの要件です）、https：//secure.logmein.com/products/hamachi2/を使用してVPNを作成します。

私は主にASP.NETアプリをLinuxサーバーに展開し、最小限の変更でもすべてを再展開します。これが私の標準的なワークフローです：

• （Subversionのような）ソースコードリポジトリを使用しています
• サーバーには、次のことを行うbashスクリプトがあります。
  • 最新のコードをチェックアウト
  • ビルドを行う（DLLを作成する）
  • 必要なものまでファイルをフィルタリングします（たとえば、コードファイルを削除します）
  • データベースをバックアップします
  • 現在の日付で名前が付けられたディレクトリ内のWebサーバーにファイルを展開します
  • 新しいスキーマがデプロイメントに含まれている場合、データベースを更新します
  • 新しいインストールをデフォルトにして、次のヒットで提供されるようにします

チェックアウトはSubversionのコマンドラインバージョンで行われ、ビルドはxbuild（Monoプロジェクトのmsbuildと同様）で行われます。魔法のほとんどはReleaseItで行われます。

開発サーバーでは基本的に継続的な統合を行っていますが、運用側では実際にサーバーにSSH接続し、スクリプトを実行して手動で展開を開始します。私のスクリプトは巧妙に 'deploy'と呼ばれているため、bashプロンプトで入力します。私はとてもクリエイティブです。ない。

本番環境では、「デプロイ」を2回入力する必要があります。1回はチェックアウト、ビルド、日付付きのディレクトリへのデプロイ、もう1回はそのディレクトリをデフォルトのインスタンスにするためです。ディレクトリには日付が付けられているため、関連するディレクトリ内から「deploy」と入力するだけで、以前のデプロイメントに戻すことができます。

初期展開には数分かかり、以前のバージョンへの復帰には数秒かかります。

これは私にとって素晴らしいソリューションであり、3つのコマンドラインユーティリティ（svn、xbuild、およびreleaseit）、DBクライアント、SSH、およびBashにのみ依存しています。

私は本当にいつかCodePlexでReleaseItのコピーを更新する必要があります：

http://releaseit.codeplex.com/

ASP.NET用のシンプルなXCopy。圧縮してサーバーにsftpし、適切な場所に解凍します。最初の展開では、IISの手動セットアップ

あなたの質問に答える：

1. XCopy
2. 手動で
3. 静的リソースの場合、変更されたリソースのみをデプロイします。
   DLLの場合、変更されたDLLおよびASPXページを展開します。
4. はい、そうです。

それを素晴らしくシンプルに保つことで、これまでに多くの頭痛の種を救いました。

特定のツールを使用していますか、それともXCOPYを使用していますか？アプリケーションはどのようにパッケージ化されていますか（ZIP、MSIなど）？

BuildMasterの開発者として、これは当然私が使用するものです。すべてのアプリケーションは、ツール内でアーティファクトとして構築およびパッケージ化され、ZIPファイルとして内部に保存されます。

アプリケーションが初めて展開されるとき、アプリプールと仮想ディレクトリをどのように設定しますか（手動で作成するか、またはツールを使用して作成しますか）？

手動で-ツール内に変更コントロールを作成し、アプリケーションがテスト環境を移動するときに、将来の環境で実行する正確な手順を思い出させます。これは単純なPowerShellスクリプトで自動化することもできますが、新しいアプリケーションを頻繁に追加しないため、サイトを手動で作成するのにかかる1分と同じくらい簡単に費やすことができます。

静的リソース（CSS、JS、またはイメージファイル）が変更された場合、アプリケーション全体を再デプロイしますか、それとも変更したリソースのみを再デプロイしますか？アセンブリ/ ASPXページが変更されたときはどうですか？

既定では、アーティファクトの展開プロセスは、変更されたファイルのみがターゲットサーバーに転送されるように設定されています。これには、CSSファイル、JavaScriptファイル、ASPXページ、およびリンクアセンブリからのすべてが含まれます。

特定のアプリケーションのすべてのデプロイ済みバージョンを追跡していますか。何か問題が発生した場合に、アプリケーションを以前の既知の動作状態に復元する手順はありますか？

はい、BuildMasterがこれをすべて処理してくれます。復元は、ほとんどの場合、古いビルドプロモーションを再実行するのと同じくらい簡単ですが、データベースの変更を手動で復元する必要があり、データが失われる可能性があります。基本的なロールバックプロセスの詳細は次のとおりです：http : //inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

Webセットアップ/プロジェクトのインストール-問題が発生した場合に簡単にアンインストールできます

展開]は、カピストラーノのような私は、.NETアプリケーションのために書いた展開ソリューションです。これは、すべてのプロジェクトで使用するものであり、非常に柔軟なソリューションです。Rob Coneryによるこのブログ投稿で説明されているように、.netアプリケーションの一般的な問題のほとんどを解決します。

• ソース管理からのコードの取得、ビルド、アプリケーションプールの作成、IISのセットアップなど、多くの標準的なことを行うという意味で、これには適切な「デフォルト」の動作が付属しています。
• ソース管理の内容に基づくリリース
• それが持っているタスクのフックをデフォルトの動作が容易に拡張または変更することができますので、
• それが持っているロールバック
• それはすべてpowershellなので、外部依存関係はありません
• PowerShellのリモート処理を使用してリモートマシンにアクセスする

ここに紹介と他のいくつかのブログ投稿があります。

上記の質問に答えるには：

• アプリケーションはどのようにパッケージ化されていますか（ZIP、MSIなど）？

  Git（または別のscm）は、ターゲットマシンでアプリケーションを取得するデフォルトの方法です。または、ローカルビルドを実行して、Powereshellリモート接続を介して結果をコピーすることもできます。

• アプリケーションが初めて展開されるとき、アプリプールと仮想ディレクトリをどのように設定しますか（手動で作成するか、またはツールを使用して作成しますか）？

  Unfoldは、PowershellのWebAdministration Moduleを使用して、アプリケーションプールとWebサイトアプリケーションを構成します。私たち（およびあなた）は、アプリケーションプールまたはWebサイトのあらゆる側面を変更できます

• 静的リソース（CSS、JS、またはイメージファイル）が変更された場合、アプリケーション全体を再デプロイしますか、それとも変更したリソースのみを再デプロイしますか？アセンブリ/ ASPXページが変更されたときはどうですか？

  はい、展開してこれを行います。デプロイは他のデプロイの隣にインストールされます。そうすれば、何かがうまくいかなかったときに簡単にロールバックできます。また、展開されたバージョンをソース管理リビジョンまで簡単に追跡できます。

• 特定のアプリケーションにデプロイされたすべてのバージョンを追跡していますか？

  はい、展開すると古いバージョンが保持されます。すべてのバージョンではなく、いくつかのバージョン。これにより、ロールバックがほとんど簡単になります。

過去1年間、リリースプロセスを改善してきましたが、現在は順調に進んでいます。私はJenkinsを使用してすべての自動ビルドとリリースを管理していますが、TeamCityまたはCruiseControlを使用できると確信しています。

したがって、チェックイン時に、「通常の」ビルドは次のことを行います。

• JenkinsはSVN更新を行って、最新バージョンのコードを取得します
• NuGetパッケージの復元は、独自のローカルNuGetリポジトリに対して実行されます。
• アプリケーションはMsBuildを使用してコンパイルされます。正しいMsBuildをインストールしてから、ASP.NETおよびMVC dllをビルドボックスにインストールする必要があるため、これを設定することは冒険です。（補足として、<MvcBuildViews>true</MvcBuildViews>ビューをコンパイルするために.csprojファイルに入力すると、msbuildがランダムにクラッシュしたため、無効にする必要がありました）
• コードがコンパイルされると、単体テストが実行されます（これにはnunitを使用していますが、好きなものを使用できます）
• すべての単体テストに合格したら、IISアプリプールを停止し、アプリをローカルに展開し（必要なファイルをコピーするためのいくつかの基本的なXCOPYコマンドのみ）、IISを再起動します（IISロックファイルに問題があり、これは解決しました）それ）
• 環境ごとに個別のweb.configファイルがあります。dev、uat、prod。（私はほとんど成功せずにウェブ変換のものを使ってみました）。したがって、正しいweb.configファイルもコピーされます
• 次に、PhantomJSを使用して一連のUIテストを実行します。また、さまざまな解像度（モバイル、デスクトップ）で多数のスクリーンショットを取得し、各スクリーンショットに情報（ページタイトル、解像度）をスタンプします。Jenkinsはこれらのスクリーンショットの処理に優れたサポートを提供しており、ビルドの一部として保存されます
• 統合UIテストに合格すると、ビルドは成功します

誰かが「Deploy to UAT」をクリックした場合：

• 最後のビルドが成功した場合、Jenkinsは別のSVNアップデートを行います
• アプリケーションは、リリース構成を使用してコンパイルされます
• 「www」ディレクトリが作成され、アプリケーションがその中にコピーされます
• 次に、winscpを使用して、ビルドボックスとUATの間でファイルシステムを同期します。
• HTTPリクエストをUATサーバーに送信し、200が返されることを確認します
• このリビジョンはUVN-datetimeとしてSVNでタグ付けされています
• ここまで来たら、ビルドは成功です！

「Deploy to Prod」をクリックすると：

• ユーザーが以前に作成されたUATタグを選択します
• タグは「切り替えられます」
• コードはコンパイルされ、Prodサーバーと同期されます。
• ProdサーバーへのHTTPリクエスト
• このリビジョンはSVNでProd-datetimeとしてタグ付けされています
• リリースは圧縮されて保存されます

完全なビルドから製品化までには約30秒かかりますが、これには非常に満足しています。

このソリューションの利点：

• これは速い
• 単体テストは論理エラーをキャッチする必要があります
• UIのバグが本番環境に入ると、スクリーンショットに、どのリビジョンが原因であるかが表示されます。
• UATと製品は同期されています
• Jenkinsは、すべてのコミットメッセージとともにUATおよびProdへの優れたリリース履歴を示します
• UATおよび製品リリースはすべて自動的にタグ付けされます
• リリースがいつ発生し、誰がリリースしたかを確認できます

このソリューションの主な欠点は次のとおりです。

• Prodへのリリースを行うときはいつでも、UATへのリリースを行う必要があります。UATが常にProdで最新であることを常に確認したかったので、これは意識的な決定でした。それでも、それは苦痛です。
• 非常に多くの構成ファイルが浮かんでいます。私はそれをすべてJenkinsに入れようとしましたが、プロセスの一部として必要ないくつかのサポートバッチファイルがあります。（これらもチェックインされています）。
• DBのアップグレードスクリプトとダウングレードスクリプトはアプリの一部であり、アプリの起動時に実行されます。それは（ほとんど）動作しますが、それは苦痛です。

他に改善の余地がある場合は是非聞いてください！

この答えのもととなった2009年に、Release Mediaも出力する継続的インテグレーションビルドにCruiseControl.netを使用しました。

そこから、Smart Syncソフトウェアを使用して、負荷分散プール外にある本番サーバーと比較し、変更を上に移動しました。

最後に、リリースの検証後、主にRoboCopyを使用してコードをライブサーバーに同期するDOSスクリプトを実行し、進行中にIISを停止/開始しました。

最後の会社では、rSyncバッチファイルを使用して展開し、最後のアップロード以降の変更のみをアップロードするために働いていました。rSyncの優れた点は、除外リストを追加して、特定のファイルまたはファイル名のパターンを除外できることです。したがって、たとえば、すべての.csファイル、ソリューション、プロジェクトファイルを除外するのは非常に簡単です。

私たちはバージョン管理にTortoiseSVNを使用していたため、以下を実行するためにいくつかのSVNコマンドを書き込むことができて良かったです。

• まず、ユーザーが最新のリビジョンを持っていることを確認します。そうでない場合は、更新を促すか、その場で更新を実行します。
• 「synclog.txt」と呼ばれるサーバーからテキストファイルをダウンロードします。このファイルには、SVNユーザーが誰であるか、ユーザーがアップロードしているリビジョン番号、アップロードの日時が記載されています。現在のアップロードに新しい行を追加し、変更されたファイルと一緒にサーバーに送り返します。これにより、アップロードで問題が発生した場合に、どのバージョンのサイトにロールバックするかを非常に簡単に見つけることができます。

これに加えて、ライブサーバー上のファイルの違いをチェックするだけの2番目のバッチファイルがあります。これは、誰かがSVNへの変更をアップロードするがコミットしないという一般的な問題を強調することができます。上記の同期ログと組み合わせると、犯人の可能性が高い人物を特定し、作業をコミットするように依頼できます。

最後に、rSyncを使用すると、アップロード中に置き換えられたファイルのバックアップを作成できます。それらをバックアップフォルダーに移動しました。そのため、一部のファイルが上書きされるべきではないことに突然気付いた場合、そのフォルダー内のすべてのファイルの最新のバックアップバージョンを見つけることができます。

当時のソリューションは少し不格好に感じましたが、アップロード方法があまりエレガントではない、または簡単ではない環境（リモートデスクトップ、サイト全体をコピーして貼り付けるなど）で作業するとき、私はそれ以来ずっとずっとそれを高く評価するようになりました。 。

既存のアプリケーションファイルを上書きするだけでなく、バ​​ージョンごとにディレクトリを作成し、IISアプリケーションを新しいパスに再ポイントすることをお勧めします。これにはいくつかの利点があります：

• 必要に応じて迅速に元に戻す
• ロックの問題を回避するためにIISまたはアプリプールを停止する必要はありません
• 古いファイルが問題を引き起こすリスクはありません
• ほぼゼロのダウンタイム（通常、新しいappdomainでの一時停止が初期化されるだけ）

私たちが持っていた唯一の問題は、アプリプールを再起動せず、自動アプリドメインスイッチに依存している場合にリソースがキャッシュされることです。