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

【问题标题】：Coming up with a better ASP.NET deployment strategy提出更好的 ASP.NET 部署策略
【发布时间】：2011-10-04 13:11:10
【问题描述】：

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

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

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

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

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

【问题讨论】：

标签： asp.net deployment

【解决方案1】：

我没有看完所有这些，但 Troy Hunt 的 You're deploying it wrong 系列可能是个不错的地方。

系列中讨论的要点：

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

【讨论】：

【解决方案2】：

在部署之前我们有四个阶段。

发展
质量检查
UAT
生产

我们有针对 QA 和 UAT 运行的构建脚本（在竹构建服务器内）。我们的 DBA 是唯一可以针对 QA、UAT 和 PROD 运行创建脚本的人。从 QA -> UAT 进行的任何操作都类似于测试运行部署。 UAT 通过再次复制生产系统来恢复。

当我们发布到生产环境时，我们只需创建一个全新的站点并将其指向 UAT 数据库并测试它在环境上是否正常工作。然后，当它运行良好时，我们轻弹“开关”并将生产 IIS 记录指向下一个站点，并将 DB 连接更改为指向 Prod DB。

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

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

【讨论】：

【解决方案3】：

我是 BuildMaster 的开发人员，该工具可以非常轻松地自动执行您上面概述的步骤，我们为 5 名开发人员团队提供免费的有限版本。

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

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

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

【讨论】：

【解决方案4】：

请参阅Scott Hanselman 标题为“Web Deployment Made Awesome”的博文和相关演讲

Blog
Video

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

【讨论】：

【解决方案5】：

拥有一个与您的开发环境完全隔离的用户验收测试 (UAT) 环境，并且只有 UAT 经理可以访问。

设置一个 UAT 构建，您可以在每次发布时手动触发它，当触发它时，它应该将您的所有部署文件以及部署清单发送给 UAT 管理器，UAT 管理器会将所有文件重新部署到 UAT 环境并运行任何数据库升级脚本。

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

【讨论】：

您假设我们有一个 UAT 经理，或者根本没有 UAT...或者 QA。开发人员是我们自己的 QA。
术语 UAT 管理器是为了清楚起见，您可以让开发人员担任此角色，只要他们遵循正确的程序。我建议您考虑使用 UAT 环境，以使您的部署更加顺畅和灵活。

【解决方案6】：

注意事项 - 我处于无法使用 MSI、批处理等进行最终部署的环境中

有帮助的事情：

在构建服务器上进行完整编译并运行所有单元测试和集成测试的构建服务器。为什么在部署之夜发现您在 aspx 页面中有一些内容无法编译？（我承认您的 Q 没有说明编译是否在部署之夜进行）

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

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

这是一篇关于如何进行更好的集成测试的文章：http://suburbandestiny.com/Tech/?p=601 有大量关于如何进行单元测试的优秀文献，但通常如果您的应用程序已经存在，您将不得不重构直到可以进行单元测试。如果这不是一个选项，那么就不要成为一个纯粹主义者，而是将一些尽可能快速且可重复的集成测试放在一起。

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

【讨论】：