你如何部署你的.NET Web应用程序？ （请推荐！）

我强烈build议使用持续集成。

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

TeamCity会从源代码库中检查代码，然后使用Rake构build应用程序，执行unit testing，甚至可以根据需要运行数据库脚本。 成功构build后，您可以将源代码打包成zip文件或将其复制到您select的目的地。

我们使用Git，尽pipeTeamCity与所有源代码控制系统一起工作。

使用TeamCity和Rake将类似于使用CruiseControl和NANT，而不需要编辑XML文件。 当然，如果您愿意的话，您可以使用TeamNity与NANT。

一个从rakefile.rb中执行构build的简短示例。 恕我直言，比XML文件更容易阅读和debugging。

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应用程序而构build的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应用程序项目，并复制你最喜欢的构build过程。

我同意斯科特的观点，这可能是非常复杂和容易被忽视的。 部署策略也是特定于应用程序的。 如果您的应用程序完全包含在一个文件夹中，则可能比引用GAC的应用程序更容易。 这反过来可能比需要维护引用GAC的多个版本的组件的应用的多个版本的服务器更容易。 我们不想在这里开始谈论政策文件:)。

说完所有将Microsoft Web部署工具与应用程序请求路由相结合是一个不错的select。 在IIS7中，可以使用该工具创build安装包。 也可以将工具指向Web应用程序，并将整个应用程序备份到应用程序归档文件夹中。 然后，您可以从此存档文件夹部署到IIS6或IIS7 Web服务器（不支持IIS5）。 我会使用像Scottbuild议的应用程序请求路由来将testing网站与现场分开。 一旦你确认新发布的网站是好的，你可以设置ARR路由到新版本。

PyroBatchFTP很适合这个。 它只会推动更改，您可以编写脚本，以便双击batch file即可推送。

在Vaasnet我们已经为自己设定了梦想解决scheme，但是它的设置相当重要 ，但如果可以的话，值得使用部分或全部这些元素。 这是什么：

• SVN在我们所有的开发机器上
• SVN在我们的构build/部署服务器上
• Cruisecontrol.net监视 SVN的变化，并将构build和分阶段文件夹的必要文件
• 使用PyroBatchFTP，我们推到一个中转站点（由Cruisecontrol触发，所以它会自动发生）
• 使用IIS7和应用程序请求路由 （ARR）和URL重写，我们有以下的分段/生产设置：
  • ARR预先将stream量引导到实例01或02，取决于哪一个是“活”的，哪一个是“分段”
  • FTP帐户始终绑定到“分期”
  • 我有另一个小型pipe理网站，将交换分期，并与一个点击生活。 如果我们意识到该版本出了什么问题（尽pipe在上线之前我们可以很容易地进行testing，这是非常罕见的），所以需要1秒钟的时间才能切换到零停机时间。

所以最终的结果是，我们可以检查SVN，并自动生成并推送到生产环境，而无需任何手动交互。 在我们testing我们的分级url并确定它已经准备就绪后，我们login到一个简单的网站，点击一下即可。

另一种没有提出的方式，我把你称为“顾”和Web安装项目

这基本上为您的.NET应用程序创build一个MSI安装程序。 这个例子是为VS2005，但我有VS2010和项目types仍然在那里。 这可以给你很多的定制，如果你需要它，或者只是基本的安装，如果你不需要。

就我个人而言，我只是做一个xcopy风格的部署，但是我最终只想把一个包传递给服务器组，让他们控制部署的时间和方式。 （我认为这也可以使用类似组策略的方式进行大规模部署更容易，但是我不太熟悉）

有很多方法来剥皮这个猫，真的取决于你有多less访问你的服务器上。 最近我个人最喜欢的方法是在项目中设置一个构build脚本（通常使用MSBUILD）来打包所有的部署文件，然后使用SVN将这些脚本连接到生产环境中。 并版本生产文件。

数据库方面，最好的办法是使用某种迁移框架。 再次，一堆运行的人，并没有真正明确的答案。

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

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

我们所有的源代码和存储过程都存储在SVN中。 每天晚上，一个数据库作业运行，并将生产存储过程拖到SVN中的一个目录中，这样在源代码pipe理中总是有最新的版本。

在部署项目的当天，我们将使用nAnt脚本从SVN中提取项目，自定义构build项目并拉取这些项目所需的依赖项。 一旦nAnt脚本运行，它被打包成一个自解压zip文件。 与此部署关联的存储过程被检入到源代码pipe理中，并且一个excel spreed工作表被更新，脚本运行并按照哪个顺序。

当部署网closures时，自解压zip文件被转移到启动的服务器上。 所有的文件被提取到正确的目录中，DBA运行生产数据库中的存储过程。

在使用这个系统的典型部署中，我们从五到六小时部署到一小时以内。

祝你好运，希望这有助于一些部署你的应用程序的方式。

必须有更好的方法，而不仅仅是在Visual Studio中“发布”，然后必须手动FTP更改的文件？

奥卡姆的剃刀通常是首选的方法：越简单越好。 FTP很容易，很less或没有任何并发​​症。 有些人使用XCOPY，Filezilla或WSFTP，其他人可能使用MS Web部署工具（我还不熟悉），但总而言之，有一个更好的方式来部署ASP.NET Web应用程序（和其他一般的应用程序）。 国际海事组织（IMO）认为，如果从开发阶段就开始考虑部署， 可以将部署与networking应用程序集成在一起，这样可以在将来相对轻松地部署。

作为一名.NET开发人员，他曾在几家开发ASP.NET Web应用程序的公司工作，他们的规模，复杂性和用户数量（从几百名用户到几万名用户）不等，而IMO的“部署”通常是最“stream畅”的话题。 一些组织在官僚作风方面做得太过分了，而另一些组织根本就没有处理任何有关部署的问题。 根据我的经验，部署方面的问题在困难/失败方面倾向于分为三类：

1. 在devise阶段，部署将被忽略/遗忘。大多数Web应用程序倾向于包含Web服务器和数据库。 除了应用程序代码之外，可能还有一些存储过程和数据库表，部署并不需要太多的考虑。 ASP.NET不仅有助于部署，而且大多数情况下，开发人员在实际应用程序运行和执行任务方面分心，而将部署作为一个单独的问题。

2. 在多个系统和玩游戏的人中部署是复杂的：复杂性是一个婊子。 从MSMQ，T-SQL存储过程和触发器，报告服务，SOAP / XML消息传递，ADauthentication，SSAS / SSIS等等，在场的技术数量增加了所涉及的人数。 最糟糕的是，所有这些不同的组件通常由组织内的不同实体pipe理。 除非每个人都彼此保持同步，否则部署的复杂性会迅速增加，从而导致多个故障点。

3. 懒惰，冷漠或缺乏沟通和/或pipe理：从很less到没有文件，缺乏协调的沟通和协议，很容易搞砸一个相对简单的过程。 部署应该是一个简单的过程，在logging所做的事情的同时进行大量的检查，但往往情况并非如此。 大多数人只是想让该死的网站跑起来。 根据我的经验，人们（非程序员）并不真正关心，直到事情真的发生。 由于没有人真正想成为失败的原因，所以责任很less落在一个人身上，因此责任通常是分散的。

有太多繁琐的文件例外，我必须尽可能自动化的过程，以防止意外上传。 那么你的团队怎么做呢？

我不知道有任何供应商自动化部署，但如果有几个我不会感到惊讶。 您可能可以通过VBScript / WMI编写解决scheme脚本或批处理脚本解决scheme，但实际情况是您需要为更复杂的ASP.NET网站定制解决scheme。 由页面组成的简单网站，数据库连接以及其他任何东西都不需要做太多的工作，因此可以根据应用程序本身的复杂程度来扩展您的部署工作。

到目前为止，在我目前的工作部署仍然通过FTP和移动一堆文件。 这是丑陋的，很容易搞砸，没有准确的历史感。 当然，你可以梳理FTP日志，没有人真的不好意思这样做。 我们的应用程序相当简单，除FTP之外没有太多需要 我的团队如何部署我们的networking应用程序对您来说真的没什么用处。 相反，我宁愿利用这个机会来提出更好的做法。

• 什么也不要。 用户帐户，R / W / X权限，ACL，防火墙， 时间 （何时部署以及需要多less时间 ），并且如果可能的话，在最终“启动date”之前testing部署到所有环境。
• 在开发实际开始之前，要把开发部署到开发中 如果这是一个简单的网站，那就这样吧。 如果有很多移动部件，将其全部纳入其中，并且实际上构build一个计划，所有组件（代码，数据库，报告，队列等）都在同一个计划中。
• 与其他人员协调并有效沟通。
• 尽可能多地logging相关信息。
• 环境：一个Web服务器与Web场; 32位与64位; find一种方法来监视日志/错误/旋转等
• 查找（或构build）可以帮助部署的工具。
• 如果可能的话进行可编程部署，select一个范例并坚持下去。 例如，如果要使用数据库服务器作为执行应用程序状态，部署，访问等的主要方法，请将其烧入应用程序并坚持使用。 如果您更喜欢阅读XML文件（比如web.config），只要坚持一致的范例部署应用程序。 另一个例子：有些组织把web.config作为一个静态文件放在每个不应该部署到其他环境的环境中。 其他的web.config程序可以跨环境部署，而不会出错。

我意识到，这个职位可能是对原来问的问题矫枉过正。 不幸的是，部署并不是一件简单的事情，因为应用程序的复杂程度可能不同 我敢打赌，大多数组织部署复杂的ASP.NET应用程序， 随着时间的推移 ，可靠地发展了一些工作（至less）的工作。