ASP.NETアプリケーションをライブサーバーにどのように展開しますか？
ASP.NET Webアプリケーションプロジェクト（[〜＃〜] not [〜＃〜]ASPのデプロイに使用するさまざまなテクニック/ツールを探しています。 .NET Webサイト）から本番へ？
Continuous Integration Buildサーバーがバイナリをある場所にドロップしてから、最初のユーザーリクエストがこれらのバイナリにヒットするまでの間に発生するワークフローに特に興味があります。
特定のツールを使用していますか、それともXCOPYだけですか？アプリケーションはどのようにパッケージ化されますか（Zip、MSIなど）？
アプリケーションを初めて展開するとき、アプリケーションプールと仮想ディレクトリをどのようにセットアップしますか（手動で作成するのですか、それとも何らかのツールを使用して作成するのですか）。
静的リソース（CSS、JS、またはイメージファイル）が変更された場合、アプリケーション全体を再デプロイしますか、または変更されたリソースのみを再デプロイしますか？ Assembly/ASPXページが変更されたときはどうですか？
特定のアプリケーションにデプロイされたすべてのバージョンを追跡し、何か問題が発生した場合に、アプリケーションを以前の既知の動作状態に復元する手順がありますか？
前のリストを自由に記入してください。
ASP.NETアプリケーションを展開するために使用するものは次のとおりです。
- ソリューションに Web Deployment Project を追加し、ASP.NET Webアプリケーションを構築するためにセットアップします
- セットアッププロジェクト（[〜＃〜] not [〜＃〜]Webセットアッププロジェクト）をソリューションに追加し、出力を取得するように設定します。 Web Deployment Project
- カスタムインストールアクションを追加し、OnInstallイベントでカスタムビルド.NETアセンブリを実行して、IISを使用して System.DirectoryServicesでアプリケーションプールと仮想ディレクトリを作成します。 .DirectoryEntry （このタスクは、アプリケーションが初めて展開されたときにのみ実行されます。）IISの複数のWebサイト、仮想ディレクトリの認証、およびアプリケーションプールのIDの設定をサポートします。
- TFSにカスタムタスクを追加してセットアッププロジェクトをビルドします（TFSはセットアッププロジェクトをサポートしないため、devenv.exeを使用してMSIをビルドする必要がありました）
- MSIはライブサーバーにインストールされます（MSIの以前のバージョンがある場合、最初にアンインストールされます）
Setup Factoryを使用して、すべてのコードをMSIにデプロイしています。何か変更が必要な場合は、ソリューション全体を再展開します。これはcssファイルのやり過ぎのように聞こえますが、すべての環境の同期を完全に維持し、本番環境の内容を正確に把握しています（すべてのテスト環境とuat環境に同じ方法でデプロイします）。
ライブサーバーにローリング展開を行うため、インストーラープロジェクトは使用しません。 CIのようなものがあります。
- approvedソース（リポジトリの「HEAD」ではない）からの「ライブ」ビルドサーバービルド
- （バックアップを取った後;-p）
- robocopyはステージングサーバーに公開します（F5クラスターではなく「ライブ」）
- ステージングサーバーで行われる最終検証。多くの場合、「ホスト」ハッキングを使用して、できる限り全体をエミュレートします。
- robocopy/Lは、次の「プッシュ」で変更のリストを配布するために自動的に使用されます。
- スケジュールされたプロセスの一部として、クラスターが循環し、ロボコピーを介してクラスター内のノードに展開されます（クラスターから出ている間）
robocopyは自動的に変更のみが展開されるようにします。
アプリプールなどについて私はloveこれを自動化する（ この質問を参照 ）が、momentそれはマニュアルです。しかし、私は本当にそれを変えたいです。
（おそらく、独自のデータセンターとサーバーファームが「オンサイト」にあると役立つので、多くのハードルを越える必要はありません）
ウェブサイト
デプロイヤー： http://www.codeproject.com/KB/install/deployer.aspx
Webサイトをローカルフォルダーに公開し、Zipで圧縮してから、FTPでアップロードします。サーバー上のDeployerは、Zipを抽出し、構成値（Web.Configおよびその他のファイル内）を置き換えます。
もちろん最初の実行では、サーバーに接続してセットアップする必要がありますIIS WebSite、database、しかし、その後の更新の公開は簡単です。
データベース
データベースの同期を保つために 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で行われます（msbuildはMonoプロジェクトと同様）。ほとんどの魔法はReleaseItで行われます。
開発サーバーでは基本的に継続的な統合が行われますが、運用側では実際にサーバーにSSHで接続し、スクリプトを実行して手動で展開を開始します。私のスクリプトは巧妙に「デプロイ」と呼ばれているため、bashプロンプトで入力します。私はとても創造的です。違います。
本番環境では、「deploy」を2回入力する必要があります。1回はチェックアウト、ビルド、および日付付きディレクトリへの展開、もう1回はそのディレクトリをデフォルトインスタンスにします。ディレクトリには日付があるため、関連するディレクトリ内から「deploy」と入力するだけで、以前の展開に戻すことができます。
初期展開には数分かかり、以前のバージョンへの復帰には数秒かかります。
私にとってはすてきなソリューションであり、3つのコマンドラインユーティリティ（svn、xbuild、およびreleaseit）、DBクライアント、SSH、およびBashのみに依存しています。
CodePlexのReleaseItのコピーをいつか更新する必要があります。
ASP.NET用のシンプルなXCopy。圧縮してサーバーにsftpし、適切な場所に解凍します。最初の展開では、IISの手動セットアップ
質問に答える：
- XCopy
- 手動で
- 静的リソースの場合、変更されたリソースのみをデプロイします。
DLLの場合、変更されたDLLおよびASPXページを展開します。 - はい、そしてはい。
簡単でシンプルに保つことで、これまでの頭痛の種が大幅に減りました。
特定のツールを使用していますか、それともXCOPYだけですか？アプリケーションはどのようにパッケージ化されますか（Zip、MSIなど）？
BuildMaster の開発者として、これは当然私が使用するものです。すべてのアプリケーションは、ツール内でアーティファクトとしてビルドおよびパッケージ化され、Zipファイルとして内部に保存されます。
アプリケーションを初めて展開するとき、アプリケーションプールと仮想ディレクトリをどのようにセットアップしますか（手動で作成するのですか、それとも何らかのツールを使用して作成するのですか）。
手動-ツール内に変更管理を作成し、アプリケーションがテスト環境を移動するときに将来の環境で実行する正確な手順を思い出させます。これは単純なPowerShellスクリプトで自動化することもできますが、新しいアプリケーションを追加することはあまりないので、サイトを手動で作成するのに1分かかるだけです。
静的リソース（CSS、JS、またはイメージファイル）が変更された場合、アプリケーション全体を再デプロイしますか、または変更されたリソースのみを再デプロイしますか？ Assembly/ASPXページが変更されたときはどうですか？
既定では、変更されたファイルのみがターゲットサーバーに転送されるように、アーティファクトを展開するプロセスがセットアップされます。これには、CSSファイル、JavaScriptファイル、ASPXページ、リンクアセンブリのすべてが含まれます。
特定のアプリケーションにデプロイされたすべてのバージョンを追跡し、何か問題が発生した場合に、アプリケーションを以前の既知の動作状態に復元する手順がありますか？
はい、BuildMasterがこれらすべてを処理してくれます。復元は、ほとんどの場合、古いビルドプロモーションを再実行するのと同じくらい簡単ですが、データベースの変更を手動で復元する必要があり、データが失われることがあります。基本的なロールバックプロセスの詳細は次のとおりです。 http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster
展開は、.netアプリケーション用に記述したカピストラーノのような展開ソリューションです。すべてのプロジェクトで使用するものであり、非常に柔軟なソリューションです。 このブログ投稿 Rob Coneryで説明されているように、.netアプリケーションの典型的な問題のほとんどを解決します。
- ソース管理からコードを取得する、ビルドする、アプリケーションプールを作成する、IISをセットアップするなど、多くの標準的な機能を実行するという意味で、優れた「デフォルト」動作が備わっています。
- ソース管理に基づいてリリース
- taskフックがあるため、デフォルトの動作を簡単に拡張または変更できます
- rollback
- すべてpowershellなので、外部依存関係はありません
- powerShellリモート処理を使用してリモートマシンにアクセスする
紹介 およびその他のブログ投稿があります。
上記の質問に答えるには：
アプリケーションはどのようにパッケージ化されていますか（Zip、MSI、...）？
Git（または別のscm）は、ターゲットマシンでアプリケーションを取得するデフォルトの方法です。または、ローカルビルドを実行し、Powereshellリモート接続経由で結果をコピーできます
アプリケーションを初めて展開するとき、アプリケーションプールと仮想ディレクトリをどのようにセットアップしますか（手動で作成するか、何らかのツールを使用して作成しますか）？
展開は、PowershellのWebAdministrationモジュールを使用して、アプリケーションプールとWebサイトアプリケーションを構成します。これにより、当社（およびお客様）はアプリケーションプールまたはWebサイトのあらゆる側面を変更できます
静的リソース（CSS、JS、またはイメージファイル）が変更された場合、アプリケーション全体を再デプロイしますか、または変更したリソースのみを再デプロイしますか？ Assembly/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変換のものを使用してみました）。そのため、適切なweb.configファイルもコピーされます
- 次に、PhantomJSを使用して、一連のUIテストを実行します。また、さまざまな解像度（モバイル、デスクトップ）で多数のスクリーンショットを撮り、各スクリーンショットに情報（ページタイトル、解像度）をスタンプします。 Jenkinsはこれらのスクリーンショットの処理を強力にサポートしており、ビルドの一部として保存されます
- 統合UIテストに合格すると、ビルドが成功します
誰かが「UATにデプロイ」をクリックした場合：
- 最後のビルドが成功した場合、Jenkinsは別のSVN更新を行います
- アプリケーションは、リリース構成を使用してコンパイルされます
- 「www」ディレクトリが作成され、アプリケーションがそこにコピーされます
- 次に、winscpを使用して、ビルドボックスとUATの間でファイルシステムを同期します
- HTTPリクエストをUATサーバーに送信し、200が返されることを確認します
- このリビジョンは、UAT-datetimeとしてSVNでタグ付けされます
- これまでのところ、ビルドは成功です！
[製品にデプロイ]をクリックすると：
- ユーザーが以前に作成されたUATタグを選択します
- タグは「切り替え」られます
- コードがコンパイルされ、Prodサーバーと同期されます
- ProdサーバーへのHTTPリクエスト
- このリビジョンはSVNでProd-datetimeとしてタグ付けされています
- リリースは圧縮されて保存されます
完全なビルドから実稼働までのすべてに約30秒かかりますが、これは非常に満足しています。
このソリューションの利点：
- これは速い
- 単体テストは論理エラーをキャッチする必要があります
- UIのバグが実稼働に入ると、スクリーンショットに原因でリビジョン番号が表示されます。
- UATとProdは同期が保たれます
- Jenkinsは、すべてのコミットメッセージとともに、UATおよびProdへの優れたリリース履歴を示します
- UATおよびProdリリースはすべて自動的にタグ付けされます
- リリースがいつ行われ、誰がリリースしたかを確認できます
このソリューションの主な欠点は次のとおりです。
- Prodへのリリースを行うたびに、UATへのリリースを行う必要があります。これは、UATがProdで常に最新であることを常に確認したかったため、私たちが行った意識的な決定でした。それでも、それは苦痛です。
- かなりの数の構成ファイルが浮かんでいます。すべてをJenkinsで実行しようとしましたが、プロセスの一部としていくつかのサポートバッチファイルが必要です。 （これらもチェックインされます）。
- DBのアップグレードおよびダウングレードスクリプトはアプリの一部であり、アプリの起動時に実行されます。 （ほとんど）動作しますが、それは苦痛です。
私は他の可能な改善を聞きたいです！
webセットアップ/インストールプロジェクト-何か問題が発生した場合に簡単にアンインストールできます
この答えが出た2009年に、Release Mediaを出力する継続的インテグレーションビルドにCruiseControl.netを使用しました。
そこから Smart Syncソフトウェア を使用して、負荷分散プール外にある運用サーバーと比較し、変更を上に移動しました。
最後に、リリースを検証した後、主にRoboCopyを使用してライブサーバーにコードを同期するDOSスクリプトを実行し、IISを停止/開始しました。
既存のアプリケーションファイルを上書きするのではなく、バージョンごとにディレクトリを作成し、IISアプリケーションを新しいパスに再ポイントすることをお勧めします。これにはいくつかの利点があります。
- 必要に応じて元に戻す
- ロックの問題を回避するためにIISまたはアプリプールを停止する必要はありません
- 古いファイルが問題を引き起こすリスクはありません
- ほぼゼロのダウンタイム（通常は、新しいappdomainでの一時停止が初期化されます）
私たちが経験した唯一の問題は、アプリプールを再起動せず、自動appdomainスイッチに依存している場合にキャッシュされるリソースです。
私が働いていた最後の会社では、rSyncバッチファイルを使用して展開し、最後のアップロード以降の変更のみをアップロードしていました。 rSyncの利点は、除外リストを追加して特定のファイルまたはファイル名パターンを除外できることです。したがって、たとえば、すべての.csファイル、ソリューションファイル、プロジェクトファイルを除外するのは非常に簡単です。
バージョン管理にTortoiseSVNを使用していたため、次のことを達成するために複数のSVNコマンドを記述できるのは素晴らしいことでした。
- 最初に、ユーザーが最新のリビジョンを持っていることを確認します。そうでない場合は、アップデートを促すか、そこでアップデートを実行します。
- 「synclog.txt」という名前のサーバーからテキストファイルをダウンロードします。このファイルには、SVNユーザーが誰であるか、アップロードしているリビジョン番号、アップロードの日時が記載されています。現在のアップロードに新しい行を追加し、変更されたファイルとともにサーバーに送り返します。これにより、アップロードによって問題が発生する可能性が低い場合にロールバックするサイトのバージョンを簡単に見つけることができます。
これに加えて、ライブサーバー上のファイルの違いをチェックするだけの2番目のバッチファイルがあります。これにより、誰かが自分の変更をSVNにアップロードせずにアップロードするという一般的な問題を強調できます。上記の同期ログと組み合わせることで、犯人の可能性のある人物を特定し、作業をコミットするよう依頼することができました。
最後に、rSyncでは、アップロード中に置換されたファイルのバックアップを取ることができます。バックアップフォルダーに移動していたため、一部のファイルが上書きされるべきでないことに突然気付いた場合、そのフォルダー内のすべてのファイルの最新のバックアップバージョンを見つけることができます。
ソリューションは少し不格好に感じましたが、アップロード方法がはるかにエレガントまたは簡単ではない環境で作業するとき、私はそれをもっと感謝するようになりました（たとえば、リモートデスクトップ、サイト全体をコピーアンドペースト） 。