如何部署.NET Web应用程序？（请提出建议！）

我们最近将ASP.NET 网站升级到了Web应用程序，部署它时遇到的困难突然让我们感到震惊。考虑到这项任务必须有多么普遍，我想知道人们使用什么插件/软件来部署一个快速发展的，远程存储的项目（即网站）？

除了在Visual Studio中 “发布” ，然后必须手动FTP更改的文件之外，还有更好的方法吗？尤其重要的是，当我们上传我们的.DLL时，该站点出现故障。

有太多的文件异常，我宁愿尽可能地自动执行该过程，以防止意外上传。

使用我们旧的解决方案（在我们的WebSite上），我们使用Dispatch for ASP，它彻底动摇了整个过程，只需单击一下即可。不幸的是，它对于DLL来说不是很好（如前所述）。

那么您的团队是如何做到的？

感谢您的任何建议。

PS-我已经读到Visual Studio 2010应该解决VS2005 / 08中的这些缺点，但是直到那时...

我强烈建议您使用持续集成。

我们使用TeamCity for CI，Rake和Albacore的组合来自动化构建。

TeamCity将从您的源代码存储库中检出代码，然后根据需要使用Rake构建应用程序，执行单元测试，甚至运行数据库脚本。成功构建后，您可以将源代码打包为zip文件，或将其复制到您选择的目标位置。

尽管TeamCity可与所有源代码控制系统一起使用，但我们使用Git。

如果不编辑XML文件，使用TeamCity和Rake类似于使用CruiseControl和NANT。当然，如果愿意，您可以将TeamCity与NANT一起使用。

从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上，我使用了fabric（fabfile.org）和capistrano（capify.org）这两个自动化工具来辅助远程SSH和SCP命令。如果在Windows主机上安装了Cygwin，则应该能够将它们用作部署工具。

在Visual Studio中“发布” Web应用程序可以从命令行以方式运行msbuild "C:\proj\yourprojectpathandfilename.csproj" /deploydir:"C:\some\deploy\dir"。目标目录是可部署的Web应用程序。

涵盖较大问题的其他答案也不错。我还要补充一点，您应该查看几个开源Web应用程序项目，并复制最喜欢的构建过程。

我同意Scott的观点，这可能非常复杂并且容易被忽略。部署策略也非常针对应用程序。如果您的应用程序完全独立于一个文件夹，则它可能比引用GAC的应用程序容易。与需要维护引用GAC程序集的多个版本的应用程序的多个版本的服务器相比，这反过来可能更容易。我们不想在这里开始谈论策略文件：）。

综上所述，将Microsoft Web部署工具与“ 应用程序请求路由”相结合是一个不错的选择。在IIS7中，可以使用该工具创建安装软件包。也可以将工具指向Web应用程序，然后将整个应用程序备份到应用程序存档文件夹中。然后，您可以从此存档文件夹部署到IIS6或IIS7 Web服务器（不支持IIS5）。我会使用斯科特建议的应用程序请求路由来将实时网站与测试网站分开。一旦确认新发布的网站良好，就可以将ARR设置为路由到新版本。

PyroBatchFTP对此非常有用。它只会推送更改，您可以编写脚本，以便您可以双击批处理文件来推送。

在Vaasnet，我们已经为自己设置了理想的解决方案，但是它的设置相当复杂，但是如果可以的话，值得使用其中的一些或全部元素。这是什么：

• 我们所有开发机器上的SVN
• SVN在我们的构建/部署服务器上
• Cruisecontrol.net监视 SVN的更改，并将仅将必要的文件生成并暂存到暂存文件夹中
• 使用PyroBatchFTP，我们推送到暂存站点（由Cruisecontrol触发，因此它会自动发生）
• 使用IIS7，应用程序请求路由（ARR）和URL重写，我们具有以下暂存/生产设置：
  • 预先的ARR会将流量定向到实例01或02，具体取决于哪个实例“处于活动状态”和哪个实例“处于暂存状态”
  • FTP帐户始终绑定到“暂存”
  • 我有另一个迷你管理站点，只需单击一下，即可交换暂存状态。零停机时间需要花费1秒钟的全部时间，如果我们意识到该版本有问题，我们可以重新切换（尽管这种情况很少见，因为我们可以在上线之前如此轻松地对其进行测试）。

因此，最终结果使我们能够检入SVN，并使其自动生成并投入生产，而无需任何手动交互。在测试暂存URL并确定它已经可以上线之后，我们登录到一个简单的站点，然后单击一下就可以上线。

对于其他未建议的方法，我推荐您参考“ The Gu”和Web Setup Projects。

这基本上为.NET应用程序创建了一个MSI安装程序。这个例子是针对VS2005的，但是我有VS2010，项目类型仍然存在。如果需要，这可以为您提供很多自定义设置，如果不需要，则可以只是基本安装。

就我个人而言，我们只是执行xcopy样式的部署，但最终我还是想将软件包交给服务器组，让他们可以控制何时以及如何进行部署。（我认为这也可以使使用组策略之类的大规模部署更加容易，但是我对此不太熟悉）

有很多方法可以使这只猫皮肤化，这实际上取决于您可以在服务器上获得多少访问权限。最近我个人最喜欢的方法是在项目内设置构建脚本（通常使用MSBUILD），该脚本将所有部署文件打包，然后使用SVN将它们桥接到生产环境中。并对生产文件进行版本控制。

在数据库方面，最好的选择是使用某种迁移框架。再次，一群人跑来跑去，没有真正明确的答案。

就我个人而言，我只是使用自己编写的vbs脚本将特定文件类型的文件夹复制到开发服务器（即，省略CS文件等）。

当我在一家大型.com公司工作时，这就是我们对.net部署所做的工作。

我们所有的源代码和存储过程都存储在SVN中。每天晚上，都有一个数据库作业运行并将生产存储的proc拖入SVN上的目录中，以便源代码控制中始终有最新版本。

在部署项目的当天，我们将使用nAnt脚本从SVN中提取项目，对项目进行自定义构建，并提取这些项目所需的任何依赖关系。运行nAnt脚本后，它将打包到一个自解压zip文件中。与该部署相关联的存储的procs被检入源代码管理，并且用脚本以及按顺序运行的excel表格进行了更新。

当deploymenet退出时，自解压zip文件被传输到启动该文件的服务器。将所有文件提取到正确的目录中，然后DBA在产品数据库上运行存储的proc。

在使用该系统的典型部署中，我们从五到六个小时的部署减少到一个小时或更短的时间。

祝您好运，并希望这对某些人制定出部署应用程序的方式有所帮助。

除了在Visual Studio中“发布”，然后必须手动FTP更改的文件之外，还有更好的方法吗？

Occam的剃刀通常是首选的方法：越简单越好。FTP很容易，几乎没有并发症。有些人使用XCOPY，Filezilla或WSFTP，其他人则可能使用MS Web部署工具（我还不熟悉），但总的来说，有一种更好的方式来部署ASP.NET Web应用程序（以及其他）一般应用）。IMO，如果从开发开始就考虑部署，则部署则可以将与Web应用程序集成在一起，从而使将来的部署相对轻松，顺畅。

作为.NET开发人员，他曾在多家公司中开发过ASP.NET Web应用程序，这些应用程序的大小，复杂程度和用户数量（从几百个用户到成千上万个用户），IMO“部署”通常是最“流畅”的主题。一些组织在官僚主义方面走得太远，而其他组织则根本不解决部署方面的任何问题。以我的经验，就困难/故障而言，部署问题通常分为以下三类中的一类或多类：

1. 在设计阶段，部署将被忽略/被深度忽略： 大多数Web应用程序倾向于将Web服务器和数据库结合在一起。除了应用程序代码，也许还有一些存储过程和数据库表，部署不需要太多的考虑。ASP.NET超过能够在部署帮助，但最常见的开发人员在得到实际的应用程序中运行和方面分心做它的任务而留下怎样的部署作为一个单独的问题。

2. 跨多个系统和多个角色的部署非常复杂： 复杂性是很重要的。从MSMQ，T-SQL存储过程和触发器，Reporting Services，SOAP / XML消息传递，AD身份验证，SSAS / SSIS等开始，正在发挥作用的技术数量增加了所涉及的人数。最糟糕的是，所有这些不同的组件通常由组织内的不同实体来管理。除非每个人都彼此同步，否则部署会迅速增加复杂性，并导致多个故障点。

3. 懒惰，冷漠或缺乏沟通和/或管理： 从很少甚至没有文档到缺乏协调的沟通和协议，很容易搞砸一个相对简单的过程。部署应该是一个简单的过程，同时要进行大量检查，同时记录所做的工作，但通常情况并非如此。大多数人只希望该死的网站运行起来。以我的经验，人们（非程序员）在真正变态之前并不在乎。责任很少落在只是一个人真正做了部署，因为没有人真正愿意如此问责制是失败的原因通常是分散的。

有太多的文件异常，我宁愿尽可能地自动执行该过程，以防止意外上传。那么您的团队是如何做到的？

我不知道有什么供应商可以自动化部署，尽管如果有几个供应商我也不会感到惊讶。您可能可以通过VBScript / WMI编写解决方案的脚本，也可以通过批处理编写解决方案的脚本，但现实情况是您需要针对更复杂的ASP.NET站点一起定制解决方案。由页面，数据库连接等组成的简单站点，您几乎不需要做太多事情，因此可以根据应用程序本身的复杂性来扩展部署工作。

到目前为止，在我目前的工作中，部署仍然是通过FTP并移动一堆文件来完成的。这很丑陋，很容易搞砸，而且没有准确的历史记录。只要您可以梳理FTP日志，就没有人真正这样做。我们的应用程序非常简单，除了FTP之外，不需要太多。我的团队如何部署我们的Web应用程序对您几乎没有用处。相反，我宁愿利用这次机会提出更好的建议做法。

• 假设什么都不做。用户帐户，R / W / X特权，ACL，防火墙，时间安排（何时部署以及需要多少时间），如果可能，在最终的“启动日期”之前测试对所有环境的部署。
• 在实际开始开发之前，请将部署因素纳入开发。如果这是一个简单的网站，那就去吧。如果有许多运动部件，则将其全部分解并实际其全部分解构建一个计划，所有组件（代码，数据库，报表，队列等）都应基于同一计划。
• 与其他平价机构进行协调并进行有效沟通。
• 如果可能，记录尽可能多的相关信息。
• 环境：一台Web服务器与Web场；32位与64位；找到一种方法来监视日志/错误/轮换等
• 查找（或构建）有助于部署的工具。
• 如果可以进行可编程部署，请选择一个范例并坚持下去。例如，如果要使用数据库服务器作为执行应用程序状态，部署，访问等的主要方法，则将其烘焙到应用程序中并坚持使用。如果您希望通过各种方式读取XML文件（例如web.config），则只需坚持使用一致的部署应用程序范例即可。另一个示例：某些组织在每个环境中都将web.config保留为静态文件，不应将其部署到其他环境中。其他人的程序web.config可以在没有错误的情况下跨环境部署。

我意识到，对于最初提出的问题，此帖子可能会过大。不幸的是，部署并不是一件简单的事情，因为应用程序的复杂性可能会有所不同。我敢打赌，大多数部署复杂ASP.NET应用程序的组织随着时间的推移已经制定了某些策略（至少）可靠地工作。