提出更好的ASP.NET部署策略

Question

在工作中，我们目前使用以下部署策略：

• 运行批处理脚本以清除所有临时ASP.NET文件
• 运行批处理脚本，将每个 ASPX文件编译为自己的DLL（ASP.NET Web 站点，而不是Web应用程序）
• 将每个单独更改的文件（ASPX和DLL）复制到实时服务器上的相应文件夹中。
• 打开Deployment Scripts文件夹，在生产数据库上手动运行每个SQL脚本（表修改，存储过程等）。
• 在睡觉前说一个祷告（或许开玩笑吧）
• 第二天早上测试第一件事并希望最好 - 修复它们出现的错误。

我们过去曾经被咬了几次因为有人会忘记运行一个脚本，或者认为他们运行了一些东西但没有，或者覆盖了与某个模块相关的sproc，因为有两个文件（一个在Sprocs中）文件夹和[ModuleName]相关文件夹中的一个文件夹）或复制了错误的DLL（因为它们可以使用与.NET生成的随机字母数字相同的名称）。

这对我来说效率非常低 - 很多手动的东西，非常容易出错。由于所有手动步骤并记住需要复制的文件，需要复制的位置，开发人员有时需要2-3小时才能执行部署（我们会在深夜，如午夜左右进行） ，需要运行哪些脚本，确保脚本以正确的顺序运行等。

比使用两个小时复制和粘贴单个ASPX页面，DLL，图像，样式表等更简单，并手动运行30多个SQL脚本。我们使用SVN作为我们的源代码控制系统（主要仅用于更新/提交，但我们不做分支）但没有单元测试或测试策略。是否有某种工具可以帮助我们使部署更顺畅？

Answer 1

我没有完成所有这些，但Troy Hunt的You're deploying it wrong系列可能是一个值得关注的好地方。

系列中讨论的要点：

• 配置转换
• 构建自动化
• 持续集成

Answer 2

我们有四个阶段才能部署。

• 开发
• QA
• UAT
• 生产

我们已经构建了针对QA和UAT运行的脚本（在Bamboo构建服务器内部）。我们的DBA是唯一可以针对QA，UAT和PROD运行创建脚本的人。任何来自质量保证的事情 - ＆gt; UAT就像是一个测试运行部署。通过再次复制生产系统来恢复UAT。

当我们发布到Production时，我们只需创建一个全新的站点并将其指向UAT数据库并测试环境是否正常。然后当这个工作正常时，我们点击'switch'并将生产IIS记录指向下一个站点，并将数据库连接更改为指向Prod DB。

因为我们使用的是完全差异的文件夹结构，所以我们的所有文件都会被复制，因此不会错过任何文件。因为我们已经进行了部署到UAT的测试运行，所以我们知道我们没有错过DB脚本（DB Scripts通常合并为一个）。因为我们已经测试了IIS网站的卷影副本，所以我们知道环境应该可行。然后我们可以在白天完成所有这些设置 - 然后在午夜或任何时候进行最后一次切换 - 减少对开发人员的影响。

tl; dr; 自动构建和部署;用于测试运行部署的UAT系统;在工作时间部署;在午夜轻拂开关/运行数据库更新。

Answer 3

我是BuildMaster的开发人员，这个工具可以非常轻松地自动执行上面列出的步骤，我们为5位开发人员提供了限量版本。

设置部署自动化的那一刻，您的大多数痛点都将消失 - 主要是批处理脚本执行和逐个文件复制。一旦完全自动化，您甚至可以安排夜间部署，只需要担心过程中出现错误（您可以为失败的构建设置通知程序）。

在数据库方面，您也可以将数据库与BuildMaster集成，如果您将脚本上传到工具中，它将跟踪哪些数据库针对哪个数据库运行。

要了解如何设置简单的Web应用程序部署计划，您可以运行其中一个示例应用程序。您还可以查看：http://inedo.com/support/tutorials/lunchmaster/part-1以了解如何自己创建一个 - 它稍微过时了，因为我们已经让它更容易开箱即用，但主要是概念是一样的。

Answer 4

请参阅此博客帖子以及Scott Hanselman标题为 “Web部署制作真棒”的相关演讲

• Blog
• Video

对于SQL部署，您可能需要考虑以下其中一项：

• RikMigrations
• Migrator.NET
• FluentMigrator
• 受托人Introduction＆amp; Source

Answer 5

让用户验收测试（UAT）环境与您的开发环境完全隔离，并且只能由UAT经理访问。

设置UAT构建，您可以在每次发布时手动触发，触发时应将所有部署文件和部署核对表发送给UAT管理员，UAT管理员将所有文件重新部署到UAT环境，并运行任何数据库升级脚本。

一旦应用程序用户和测试人员签署了UAT版本，就可以授权UAT管理员使用与UAT版本完全相同的过程和检查清单部署到PRODUCTION环境。这将保证您不会错过任何部署步骤，并在将其部署到生产环境之前测试部署过程。

Answer 6

警告 - 我处于一个我们无法使用MSI，批处理等进行最终部署的环境

有帮助的事情：

构建服务器，它在构建服务器上执行完整编译并运行所有单元测试和集成测试。为什么发现你在aspx页面中有什么东西在部署之夜不能编译？ （我承认你的Q不清楚是否在部署之夜进行编译）

我有一个管理员可以访问该练习环境和部署失败点的页面，例如连接到数据库，连接到报告服务，发送电子邮件，读取和写入临时文件夹。

此外，将管理员需要更改的所有内容放入web.config外部的文件中。连接字符串和应用程序设置部分本身支持一种方法（即不要重新创建web.config系统只是为了创建一个单独的文件）

这是一篇关于如何进行更好的集成测试的文章：http://suburbandestiny.com/Tech/?p=601有很多关于如何进行单元测试的好文献，但是如果你的应用程序已经存在，你必须重构，直到单元测试变为可能。如果这不是一个选项，那么就不要成为一个纯粹主义者，并尽可能快速和可重复地进行一些集成测试。

将您的依赖项保留在bin而不是GAC中，因为告诉管理员复制文件比教他们管理GAC更容易。