.NET Webアプリケーションをどのようにデプロイしますか？（推奨事項をお願いします！）

最近、ASP.NET WebサイトをWebアプリケーションにアップグレードしましたが、展開する際の急激な難しさに驚かされました。これがどれほど一般的なタスクであるかを考えると、急速に進化し、リモートに保存されたプロジェクト（つまり、Webサイト）を展開するために人々がどのプラグイン/ソフトウェアを使用するのか疑問に思いましたか？

Visual Studioで "発行"し、変更されたファイルを手動でFTPで転送するよりも優れた方法があるはずです。特に、.DLLをアップロードしているときにサイトがダウンするためです。

非常に多くの手間のかかるファイルの例外があるため、偶発的なアップロードを防ぐために、できるだけプロセスを自動化する必要があります。

私たちの古いソリューション（WebSite上）では、Dispatch for ASPを使用しました。これにより、プロセス全体がワンクリックで完全にロックされました。残念ながら、（前述のように）DLLには適していません。

では、チームはそれをどのように行うのですか？

アドバイスありがとうございます。

PS-Visual Studio 2010はVS2005 / 08でこれらの欠点に対処することになっていることを読みましたが、それまでは...

継続的インテグレーションの使用を強くお勧めします。

ビルドの自動化には、CI、Rake、AlbacoreのTeamCityの組み合わせを使用します。

TeamCityはソースコードリポジトリからコードをチェックアウトし、Rakeを使用してアプリケーションをビルドし、単体テストを実行し、必要に応じてデータベーススクリプトを実行します。ビルドが成功したら、ソースコードをzipファイルにパッケージ化するか、選択した宛先にコピーできます。

TeamCityはすべてのソース管理システムで動作しますが、Gitを使用しています。

TeamCityとRakeの使用は、XMLファイルを編集せずにCruiseControlとNANTを使用するのと同じです。もちろん、必要に応じてNANTでTeamCityを使用できます。

ビルドを実行するrakefile.rbから抜粋した短いサンプル。私見、XMLファイルよりも読みやすくデバッグしやすい。

require 'albacore'
require 'rexml/document'
require 'find'

VERSION_NO = "1.0"

OUTPUT_PATH = "output"
WEBOUTPUT_PATH = "output/web"
ADMINOUTPUT_PATH = "output/admin"

CONFIG = "Release"

WEB_PATH = "app/Company.Website.Web"
ADMIN_PATH = "app/Company.Website.Admin"
PACKAGE_PATH = "build/package"
DB_SCRIPT_PATH = "Company.Website.DB"
SOLUTION = "Company.Website.sln"

ARTIFACTS_PATH = "d:/build/artifacts/"

DEPLOY_WEB_PATH = "d:/deploy/company/website/"
DEPLOY_ADMIN_PATH = "d:/deploy/company/admin/"

task :default => ['setuptest','assemblyinfo','config','msbuild','createdb','sqlcmd','deploy']


task :setuptest do |setup|
  if ENV['BuildNumber'].nil? then ENV['BuildNumber'] = "000" end

  VERSION_NO = VERSION_NO + '.' + ENV['BuildNumber']
  puts 'Version Number : ' + VERSION_NO

  ZIPFILE_WEB = 'Company.Website.Web.' + VERSION_NO
  ZIPFILE_ADMIN = 'Company.Website.Admin.' + VERSION_NO  

  DB_SERVER = "WEB2"
  DB_DATABASE = "Website"  
  CREATEDB_SCRIPT = "app/Company.Website.DB/00CreateDatabaseTEST.sql"
end

  assemblyinfotask do |asm|
    asm.version = VERSION_NO
    asm.company_name = "Company Name"
    asm.copyright = "Copyright 2010"
    asm.output_file = "CommonAssemblyInfo.cs"
  end

  task :config do
    FileUtils.cp 'NHibernate.test.config', 'NHibernate.config'
  end

  msbuildtask do |msb|
    msb.properties = { :configuration => :Debug }
    msb.targets [:Clean, :Build]
    msb.solution = "Company.Website.sln"
  end

  sqlcmdtask :createdb do |sql|
    puts "executing sql scripts..."
    sql.log_level = :verbose
    sql.path_to_command = "sqlcmd.exe"
    sql.server = DB_SERVER
    sql.database = "master"
    sql.scripts << CREATEDB_SCRIPT
  end

  sqlcmdtask do |sql|
    puts "executing sql scripts..."
    sql.log_level = :verbose
    sql.path_to_command = "sqlcmd.exe"
    sql.server = DB_SERVER
    sql.database = DB_DATABASE
    sql.scripts << "app/Company.Website.DB/01CreateTables.sql"
    sql.scripts << "app/Company.Website.DB/02InsertReferenceData.sql"
  end

  task :deployprep do

    FileUtils.remove_dir 'app/Company.Website.Web/obj'
    FileUtils.remove_dir 'app/Company.Website.Admin/obj'

  end

  ziptask :zipweb do |zip|
    puts "creating zip package in " + ZIPFILE_WEB
    zip.directories_to_zip = ["app/Company.Website.Web"]
    zip.output_file = ZIPFILE_WEB  + '.zip'
    zip.output_path = File.dirname(__FILE__)
  end

  ziptask :zipadmin do |zip|
      puts "creating zip package in " + ZIPFILE_ADMIN
    zip.directories_to_zip = ["app/Company.Website.Admin"]
    zip.output_file = ZIPFILE_ADMIN  + '.zip'
    zip.output_path = File.dirname(__FILE__)
  end  

Albacoreは、.NETアプリケーションをデプロイするために特別に構築されたRakeタスクのスイートです。

Linuxでは、リモートSSHおよびSCPコマンドを支援する自動化ツールであるファブリック（fabfile.org）およびcapistrano（capify.org）を使用しました。CygwinをWindowsホストにインストールしている場合、これらをデプロイメントツールとして再利用できるはずです。

Visual StudioでのWebアプリケーションの「公開」は、コマンドラインからとして実行できますmsbuild "C:\proj\yourprojectpathandfilename.csproj" /deploydir:"C:\some\deploy\dir"。宛先ディレクトリーは、デプロイ可能なWebアプリケーションです。

あなたのより大きな質問をカバーする他の答えは良いです。また、いくつかのオープンソースWebアプリケーションプロジェクトを見て、最も気に入ったビルドプロセスをコピーする必要があることも付け加えておきます。

これは非常に複雑で見過ごされやすいというスコットの意見に同意します。展開戦略も非常にアプリケーション固有です。アプリが1つのフォルダーに完全に自己完結している場合は、GACを参照するアプリよりも簡単です。これは、GACのアセンブリの複数のバージョンを参照するアプリの複数のバージョンを維持する必要があるサーバーよりもさらに簡単かもしれません。ここでは、ポリシーファイルについて話し始めたくありません。

Microsoft Web Deployment ToolとApplication Request Routingを組み合わせることは、1つの優れたオプションと言えます。IIS7では、ツールを使用してインストールパッケージを作成できます。ツールでWebアプリケーションを指定し、アプリケーション全体をアプリケーションアーカイブフォルダーにバックアップすることもできます。次に、このアーカイブフォルダーからIIS6またはIIS7 Webサーバー（IIS5はサポートされていません）に展開できます。スコットが提案するように、アプリケーションのリクエストルーティングを使用して、ライブとテストのウェブサイトを分離します。新しく公開されたWebサイトが適切であることを確認したら、ARRを設定して新しいバージョンにルーティングすることができます。

PyroBatchFTPはこれに最適です。変更のみをプッシュし、バッチファイルをダブルクリックしてプッシュできるようにスクリプトを作成できます。

Vaasnetでは、自分たちで夢のソリューションをセットアップしましたが、セットアップはかなり複雑ですが、可能であれば、これらの要素の一部またはすべてを使用する価値があります。これは次のとおりです。

• すべての開発マシン上のSVN
• ビルド/デプロイメントサーバー上のSVN
• Cruisecontrol.netは、SVNへの変更を監視し、必要なファイルのみを構築してステージングフォルダーにステージングします。
• PyroBatchFTPを使用して、ステージングサイトにプッシュします（Cruisecontrolによってトリガーされるため、自動的に実行されます）
• IIS7とApplication Request Routing（ARR）およびURL Rewriteを使用して、次のステージング/本番環境のセットアップがあります。
  • ARRは、どちらがインスタンスが「ライブ」で、どちらが「ステージング」であるかに応じて、インスタンス01または02にトラフィックを転送します。
  • FTPアカウントは常に「ステージング」にバインドされています
  • ステージングを入れ替えてシングルクリックでライブする別のミニ管理サイトがあります。ダウンタイムなしで切り替えるのに1秒かかります。そのリリースに問題があることがわかった場合は、再度切り替えることができます（稼働前に簡単にテストできるため、まれです）。

したがって、最終的な結果により、SVNにチェックインして、手動で操作しなくても自動的にビルドして本番環境にプッシュすることができます。ステージングURLをテストして、公開の準備ができていることを確認したら、シンプルなサイトにログインし、ワンクリックで公開します。

提案されていない別の方法については、「区」とWebセットアッププロジェクトを紹介します

これは基本的に、.NETアプリケーション用のMSIインストーラーを作成します。この例はVS2005の場合ですが、VS2010を使用していて、プロジェクトタイプはまだ残っています。これにより、必要に応じて多くのカスタマイズを行うことができます。必要ない場合は、基本的なインストールのみを行うことができます。

個人的には私が作業している場所ではxcopyスタイルの展開を行っていますが、最終的にはパッケージをサーバーグループに渡して、いつ、どのように展開するかを制御できるようにしたいと考えています。（これにより、グループポリシーのようなものを使用して大量展開を行うのが容易になると思いますが、私はあまり詳しくありません）

この猫のスキンを作成する方法はたくさんありますが、実際にはサーバー上でどの程度のアクセスが可能かによって異なります。最近の私の個人的なお気に入りの方法は、プロジェクト内にビルドスクリプトをセットアップし（通常はMSBUILDを使用）、すべてのデプロイメントファイルをパッケージ化し、SVNを使用してそれらを本番環境にブリッジすることです。そして、生産ファイルをバージョン管理します。

データベースに関しては、ある種の移行フレームワークを使用するのが最善です。繰り返しますが、走り回っている人たちの束で、明確な答えはありません。

個人的に私は自分で書いたvbsスクリプトを使用して、特定のファイルタイプのフォルダーを開発サーバーにコピーします（つまり、csファイルを除外します）。

私が大規模な.com会社で働いていたとき、これが.net展開で行ったものです。

すべてのソースコードとストアドプロシージャはSVNに保存されました。毎晩、データベースジョブが実行され、プロダクションストアドプロシージャをプルしてSVNのディレクトリに入れます。これにより、ソース管理に常に最新のバージョンが存在するようになります。

プロジェクトの展開日に、nAntスクリプトを使用してSVNからプロジェクトをプルし、プロジェクトのカスタムビルドを実行して、これらのプロジェクトに必要な依存関係をプルします。nAntスクリプトが実行されると、自己解凍zipファイルにパッケージ化されました。この展開に関連付けられているストアドプロシージャがソース管理にチェックインされ、実行するスクリプトとその順序でExcelスプレッドシートが更新されました。

deploymenetが起動すると、自己解凍zipファイルが、それが起動されたサーバーに転送されました。すべてのファイルが正しいディレクトリに抽出され、DBAは製品データベースでストアドプロシージャを実行しました。

このシステムを使用した一般的な展開では、5〜6時間の展開から1時間以内になりました。

幸運を祈るとともに、これがアプリケーションのデプロイ方法を理解するのに役立つことを願っています。

Visual Studioで "発行"し、変更されたファイルを手動でFTPで転送するよりも優れた方法があるはずです。

Occamのかみそりは、通常、推奨されるアプローチです。FTPは簡単で、複雑さはほとんどありません。XCOPY、Filezilla、またはWSFTPを使用する人もいれば、MS Webデプロイメントツール（まだ詳しくない）を使用する人もいますが、オールインワンで、ASP.NET Webアプリ（およびその他のアプリ全般）。IMO、開発の最初から導入を考慮する場合、導入はWebアプリと統合できるため、将来的には比較的簡単でスムーズな導入が可能になります。

サイズ、複雑さ、ユーザー数（数百人から数万人）の範囲でASP.NET Webアプリを開発している複数の企業で働いた.NET開発者として、IMOの「展開」は最も「流動的」なトピックです。一部の組織は、官僚制の観点からそれを受け入れすぎていますが、他の組織は配備の問題にまったく取り組んでいません。私の経験では、展開の問題は、困難/失敗の点で、3つのカテゴリの1つ以上に分類される傾向があります。

1. 設計フェーズでは、展開は無視されるか、徹底的に忘れられ ます。ほとんどのWebアプリは、Webサーバーとデータベースを組み込む傾向があります。アプリケーションコードだけでなく、一部のストアドプロシージャやデータベーステーブルを除けば、展開についてはそれほど考慮する必要はありません。ASP.NETは、展開を支援する能力以上のものですが、ほとんどの場合、開発者は、実際のアプリケーションを実行してそのタスクを実行するという点で気を取られ、展開方法は別の問題として残されます。

2. 複数のシステムと関係者の間での展開は複雑 です。複雑さはビックです。MSMQ、T-SQLストアドプロシージャとトリガー、Reporting Services、SOAP / XMLメッセージング、AD認証、SSAS / SSISなどから、関係するテクノロジーの数が増えると、関係する人の数も増えます。最悪の場合、これらのさまざまなコンポーネントはすべて、通常、組織内のさまざまなエンティティによって管理されます。全員が互いに同期していない限り、展開が複雑になり、複数の障害点が発生する可能性があります。

3. 怠惰、無関心、またはコミュニケーションや管理の欠如： 文書化がほとんどないことから、コミュニケーションやプロトコルが調整されていないことまで、比較的単純なプロセスを台無しにするのは簡単です。展開は、何が行われたかを文書化する間、常に多数のチェックが行われる単純な手順である必要がありますが、多くの場合そうではありません。ほとんどの人は、いまいましいサイトを稼働させたいだけです。私の経験では、人々（プログラマーではない）は、何かが本当に不愉快になるまで気にしません。誰も本当に失敗の理由になりたくないので、通常、説明責任が分散されるため、実際に展開を行うのは1人だけでは責任はほとんどありません。

非常に多くの手間のかかるファイルの例外があるため、偶発的なアップロードを防ぐために、できるだけプロセスを自動化する必要があります。では、チームはそれをどのように行うのですか？

展開を自動化する手持ちのベンダーは知りませんが、いくつかあるとしても驚かないでしょう。VBScript / WMIを介してソリューションをスクリプト化するか、ソリューションをバッチスクリプト化することもできますが、実際には、より複雑なASP.NETサイトに合わせてソリューションを調整する必要があります。ページ、データベース接続などで構成される単純なサイトでは、アプリケーション自体の複雑さに合わせて展開作業をスケーリングする必要はほとんどありません。

これまでのところ、私の現在の作業では、展開はまだFTPを介して行われ、多数のファイルを移動しています。それは醜く、失敗しやすく、正確な歴史の感覚はありません。FTPログをくまなく調べられたとしても、誰もそんなことをする必要はありません。私たちのアプリはFTP以外の必要がなく、かなりシンプルです。私のチームがWebアプリを展開する方法は、ほとんどまたはまったく役に立ちません。代わりに、この機会を利用してより良い実践を提案したいと思います。

• 何も仮定しません。ユーザーアカウント、R / W / X特権、ACL、ファイアウォール、タイミング（展開するタイミングと実行に必要な時間）。可能であれば、最終的な「リリース日」の前にすべての環境への展開をテストします。
• 開発が実際に始まる前に、展開を開発に組み込みます。それが単純なサイトであれば、そうしてください。そこに、多くの可動部品、要因でそれがすべてであり、実際の場合建てる計画を先のすべてのコンポーネント（コード、データベース、レポート、キューなど）は同じプランですべてです。
• 他のパリティと調整し、効果的かつ効率的に通信します。
• 可能な限り多くの関連情報を文書化します。
• 環境：1つのWebサーバーとWebファーム。32ビットと64ビット。ログ/エラー/回転などを監視する方法を見つける
• 展開に役立つツールを見つけます（またはビルドします）。
• プログラム可能な展開が可能な場合は、パラダイムを選択してそれを使用してください。たとえば、アプリケーションの状態、展開、アクセスなどを実行するための主要な手段としてデータベースサーバーを使用する場合は、アプリケーションに焼き付けて使用します。XMLファイル（web.configなど）を必ず読みたい場合は、アプリケーションの展開に一貫したパラダイムを使用してください。別の例：一部の組織では、web.config を他の環境に展開すべきではない各環境の静的ファイルとして残しています。他のプログラムのweb.configは、エラーなく環境全体に展開できるようになっています。

この投稿は、最初に尋ねられた質問に対してはやりすぎかもしれません。残念ながら、アプリケーションは複雑さが異なる場合があるため、展開は単純なことではありません。複雑なASP.NETアプリを展開するほとんどの組織は、時間の経過とともに（少なくとも）確実に機能する特定の戦略を開発してきたに違いない。