你如何部署ASP.NET应用程序住服务器?(How do you deploy your ASP.N

2019-06-26 04:44发布

我要寻找不同的技术/工具,你用它来部署ASP.NET Web应用程序项目( 不是 ASP.NET网站)来生产?

我特别感兴趣的工作流程的持续集成构建服务器下降一些的位置,第一用户请求到达这些二进制文件时的二进制文件的时间之间发生的事情。

  1. 您是否使用了一些特定的工具或只是XCOPY? 应用程序是如何打包(ZIP,MSI,...)?

  2. 当一个应用程序部署的第一次,你如何安装应用程序池和虚拟目录(你手动或使用一些工具来创建它们)?

  3. 当静态资源的变化(CSS,JS或图像文件)你重新部署整个应用程序或只修改后的资源? 如何当装配/ ASPX页面的变化?

  4. 你跟踪所有版本的部署对于给定的应用和在万一出错,你有应用恢复到以前的某个已知的工作状态的程序?

随意完成前面的列表。


下面是我们用来部署我们的ASP.NET应用程序:

  1. 我们添加一个Web部署项目的解决方案,并设置它来构建ASP.NET Web应用程序
  2. 我们添加一个安装项目( 而不是 web安装项目)到溶液中,将其设置为采取网络部署项目的输出
  3. 我们添加自定义的安装操作,并在OnInstall情况下,我们运行创建一个应用程序池,并使用在IIS虚拟目录自定义生成.NET程序集System.DirectoryServices.DirectoryEntry (这个任务只执行一个应用程序部署在第一时间) 。 我们支持在IIS中,验证多个Web站点的虚拟目录和应用程序池设置身份。
  4. 我们在TFS中添加自定义的任务就是建设安装项目(TFS不支持安装项目,所以我们不得不使用的devenv.exe构建MSI)
  5. 微星安装现场服务器上(如果还有的MSI它首先卸载以前的版本)

Answer 1:

我们拥有所有的使用设定厂的MSI部署了我们的代码。 如果事情必须改变,我们重新部署整个解决方案。 这听起来像矫枉过正的CSS文件,但它绝对是保持所有环境保持同步,我们确切地知道是在生产(我们部署到所有测试和UAT环境的方法相同)。



Answer 2:

我们滚动部署现场服务器,所以我们不使用安装项目; 我们有更多的东西一样CI:

  • “活”集结服务器从合法来源(不回购的“HEAD”)建立
  • (它已经采取了备份;-p后)
  • ROBOCOPY发布到一个临时服务器(“活”,但不是F5集群中)
  • 临时服务器上完成,常与“主机”最终验证黑客为接近地模拟了整个事情尽可能
  • ROBOCOPY / L被自动用于分发的在接下来的“推”的更改列表,以提醒任何蠢材的
  • 作为调度的过程的一部分,群集被循环,经由ROBOCOPY部署到集群中的节点(而它们是出群集)

ROBOCOPY自动确保只部署更改。

重新应用程序池等; 希望这是自动的( 见这个问题 ),但目前它是手动的。 我真的想改变这种状况,虽然。

(它可能帮助,我们有我们自己的数据中心和服务器农场“现场”,所以我们没有跨越许多障碍)



Answer 3:

网站

部署: http://www.codeproject.com/KB/install/deployer.aspx

我网站发布到本地文件夹,压缩它,然后将其上传通过FTP。 在服务器上部署后,提取拉链,更换配置值(Web.Config中和其他文件),仅此而已。

当然,对于首次运行需要连接到服务器和安装IIS网站的数据库,但发布更新后,是小菜一碟。

数据库

为了保持数据库同步,我用http://www.red-gate.com/products/sql-development/sql-compare/

如果服务器的背后是一群路由器,你不能直接连接(这是SQL的要求比较),使用https://secure.logmein.com/products/hamachi2/创建VPN。



Answer 4:

我主要是部署ASP.NET应用到Linux服务器,即使是最小的变化重新部署的一切。 这是我的标准的工作流程:

  • 我使用源代码库(例如Subversion)
  • 在服务器上,我有一个bash脚本,执行以下操作:
    • 检查出最新的代码
    • 是否建立(创建的DLL)
    • 过滤器中的文件下到要领(删除代码文件为例)
    • 备份数据库
    • 在部署一个以当前日期命名的目录下的文件到Web服务器
    • 更新数据库,如果一个新的架构包括在部署
    • 使新安装的默认之一,所以它会在下一击送达

结帐与颠覆的命令行版本完成,建筑与xbuild(MSBuild的工作都从Mono项目)完成。 最神奇的是ReleaseIt完成。

在我的开发服务器我基本上是有持续集成,但在生产方面其实我SSH到服务器并通过运行脚本手动启动部署。 我的剧本则巧妙地称为“部署”所以这就是我在bash提示符下键入。 我非常有创意。 不。

在生产中,我必须键入“部署”两次:一次退房,构建和部署到一个过时的目录,并一度使该目录的默认实例。 由于目录的日期,我可以简单地通过从相关目录中输入“部署”恢复到以前的任何部署。

初始部署需要一两分钟,逆转到以前的版本需要几秒钟。

这一直是我一个很好的解决方案,只依赖于三个命令行实用程序(SVN,xbuild和releaseit),数据库客户端,SSH,和Bash。

我真的需要更新ReleaseIt的CodePlex上的某个副本:

http://releaseit.codeplex.com/



Answer 5:

简单的XCopy为ASP.NET。 邮编起来,SFTP服务器,提取到正确的位置。 对于首次部署,IIS的使用说明书正确设置



Answer 6:

回答你的问题:

  1. 的XCopy
  2. 手动
  3. 对于静态资源,我们只部署改变资源。
    对于DLL的,我们部署变化的DLL和ASPX页面。
  4. 是的,是的。

保持它的简单好用迄今已为我们节省了很多头疼的问题。



Answer 7:

您是否使用了一些特定的工具或只是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



Answer 8:

Web安装/安装项目 - 所以,如果出了问题,你可以很容易地将其卸载



Answer 9:

展开是一个斯特拉努般的部署解决方案,我写的.NET应用程序。 这就是我们用我们所有的项目,这是一个非常灵活的解决方案。 在解释它解决了大部分的.NET应用程序的典型问题本博客文章由罗布科纳。

  • 它带有一个良好的“默认”的行为,在某种意义上说,它为你带来很多的标准的东西:让从源头控制,构建代码,创建应用程序池,设置IIS等
  • 基于什么是在源代码控制版本
  • 的任务挂钩 ,所以默认行为可以很容易扩展或改变
  • 它已经回滚
  • 这一切都PowerShell的 ,所以没有任何外部依赖
  • 它使用PowerShell远程访问远程计算机

这里有一个介绍和其他一些博客文章。

因此,要回答上述问题:

  • 应用程序是如何打包(ZIP,MSI,...)?

    Git的(或其他SCM)是默认的方式来获得目标计算机上的应用程序。 另外,您可以执行本地构建和结果在Powereshell远程连接复制

  • 当一个应用程序部署的第一次,你如何安装应用程序池和虚拟目录(你手动或使用一些工具来创建它们)?

    展开配置使用PowerShell的WebAdministration模块的应用程序池和网站应用程序。 它使我们(和你)来修改应用程序池或网站的任何方面

  • 当静态资源的变化(CSS,JS或图像文件)你重新部署整个应用程序或只修改后的资源? 如何当装配/ ASPX页面的变化?

    是的展开做到这一点,任何部署旁边安装到他人。 当服用点不顺心这样,我们可以很容易地回滚。 它也使我们能够轻松地追溯部署版本的源代码控制修订。

  • 你跟踪所有部署版本的给定的应用?

    是的,开展保持旧版本周围。 并非所有版本,但版本众多。 它使回滚几乎微不足道。



Answer 10:

我们一直在改进我们的释放过程在过去的一年,现在我们已经有了它拍下来。 我使用詹金斯来管理所有的自动化的建立和释放,但我敢肯定,你可以使用的TeamCity或CruiseControl的。

所以在签入,我们的“正常”构建执行以下操作:

  • 詹金斯没有一个SVN更新,以获取最新版本的代码
  • 一个NuGet包还原完成运行时对我们自己的本地的NuGet库
  • 该应用程序使用的MSBuild编译。 这一设置是一种冒险,因为你需要在你的构建盒安装正确的MSBuild,然后ASP.NET MVC和dll的。 (作为一个方面说明,当我有<MvcBuildViews>true</MvcBuildViews>在我的.csproj文件来编译意见进入,MSBuild的随机崩溃,所以我不得不停用)
  • 一旦代码被编译测试运行单元(我使用这个NUnit的,但你可以使用任何你想要的)
  • 如果所有的单元测试都通过了,我停止IIS应用程序池,本地部署的应用程序(只是一些基本的命令XCOPY在必要的文件复制),然后重新启动IIS(我有问题,与IIS锁定文件,这解决了它)
  • 我对每个环境独立的web.config文件; 开发,UAT,PROD。 (我尝试使用网络改造的东西,但收效甚微)。 所以,正确的web.config文件也复制跨越
  • 然后我用PhantomJS执行一堆UI测试。 它也需要一群在不同的分辨率(移动,桌面)和邮票每个屏幕截图的一些信息(网页标题,分辨率)的屏幕截图。 詹金斯有处理这些截图的大力支持,他们被保存作为构建的一部分
  • 一旦整合UI测试通过构建成功

如果有人点击“部署到UAT”:

  • 如果最后的构建成功,詹金斯的确另一SVN更新
  • 该应用程序是使用RELEASE配置编译
  • 创建一个“www”的目录和应用程序复制到它
  • 然后我使用WinSCP赋予到构建框和UAT之间的文件系统同步
  • 我送一个HTTP请求到UAT服务器,并确保我拿回200
  • 该修订标记在SVN为UAT-日期时间
  • 如果我们走了这么远,构建成功!

当我们点击“部署到正式版”:

  • 用户选择以前创建的UAT标签
  • 标签是“切换”到
  • 代码被编译和PROD服务器同步
  • HTTP请求到服务器PROD
  • 该修订标记在SVN为PROD-日期时间
  • 发布是压缩和存储

所有了整体构建到生产大约需要30秒,我非常,非常高兴。

上升空间到该解决方案:

  • 它很快
  • 单元测试应该抓住逻辑错误
  • 当一个用户界面错误进入生产,截图将有望表现出什么版本#造成了它
  • UAT和PROD保持同步
  • 詹金斯显示了一个极大的释放历史UAT和PROD所有提交信息的
  • UAT和PROD版本都自动标记
  • 你可以看到,当释放发生,谁做他们

该解决方案的主要缺点是:

  • 每当你做一个版本为正式版,你需要做一个释放UAT。 这是我们做了,因为我们要始终确保UAT始终保持最新与PROD有意识的决定。 不过,这是一个痛苦。
  • 有相当多的配置文件左右浮动。 我试图把它所有的詹金斯,但有必要作为过程的一部分,一些支持批量文件。 (这些也签入)。
  • DB升级和降级脚本是应用程序的一部分,并在应用程序启动运行。 它的工作原理(主要是),但它是一个痛苦。

我很乐意听到任何其他可能的改进!



Answer 11:

早在2009年,在这个答案来自冰雹,我们用CruiseControl.net为我们的持续集成构建,这也输出发布媒体。

从那里,我们使用的智能同步软件来比较,这是出了负载均衡池中的生产服务器和移动的变化了。

最后,确认发布后,我们跑了主要用于ROBOCOPY同步的代码脚本DOS到现场服务器,停止/启动IIS,因为它去了。



Answer 12:

在最后的公司我工作了,我们使用使用rsync的批处理文件,只上传自上次上传的变化进行部署。 RSYNC的妙处在于,你可以添加排除列表,以特定的文件或文件名模式排除。 因此排除所有的我们的.cs文件,解决方案和项目文件是很容易的,例如。

我们使用TortoiseSVN进行版本控制,所以很高兴能在几个SVN写命令来完成以下任务:

  • 首先,检查用户的最新版本。 如果没有,要么提示他们更新或运行更新正确的那里,然后。
  • 从所谓的“synclog.txt”,详细SVN用户是谁的服务器,他们上传什么版本号和上传的日期和时间下载的文本文件。 追加对当前上传一个新行,然后将其发送回服务器更改的文件一起。 这使得它非常容易找出滚什么版本的网站回到上关的机会,上传会引起问题。

除了这个还有就是只检查现场服务器上的文件差异的第二个批处理文件。 这可以突出常见问题,其中有人会上传但不能提交他们的变化SVN。 与上面提到的,我们可以找出谁是可能的罪魁祸首,并要求他们提交自己的工作同步日志结合。

最后,rsync的,您可以采取的上传过程中被替换的文件的备份。 我们曾经拥有过它们移动到备份文件夹所以如果你突然意识到,某些文件不应该被覆盖,你可以找到该文件夹​​中的每个文件的最后一个备份起来的版本。

虽然该解决方案的时候觉得有点笨重因为我已经来到在上传方法是少了很多高雅或易环境中工作时,欣赏它了一大堆更多(远程桌面,复制并粘贴整个网站,例如) 。



Answer 13:

我建议你不只是重写现有应用程序文件,而是创建每个版本的目录和repointing IIS应用程序到新的路径。 这样做有几个好处:

  • 快速,如果需要恢复
  • 无需停止IIS或应用程序池,以避免锁定问题
  • 造成问题的旧文件没有风险
  • 更多或更少的零停机时间(通常只是在新的AppDomain初始化停顿)

我们有唯一的问题是,如果你没有重新启动应用程序池,并依靠自动程序域开关被缓存的资源。



文章来源: How do you deploy your ASP.NET applications to live servers?