问ASP.NET部署/维护最佳实践

EN

编译了ASP.NET MVC应用程序。这意味着你不能像PHP网站那样上传修改过的文件。这也意味着当您开始更新站点时，当前用户将被丢弃(例如，失去他们的会话)。

除了简单地更新文件之外，还有更多的工作要做:您必须处理：

• 新版本可能需要服务器上的不同权限集。
• 新版本可能要求安装分布式事务协调器(MSDTC)服务，或者希望使用不同的SMTP服务器，或访问Active等。这涉及更改应用程序和服务器本身的配置。
• 例如，初学者经常遇到的一个问题是，他们在/bin中保留旧DLL，同时添加具有不同名称的新DLL:应用程序可能仍然使用旧DLL，这会造成更改应用程序代码的疯狂情况，但应用程序的行为保持不变。
• 如果数据库模式改变了，并且应用程序使用普通的SQL server而不是NoSQL，那么数据会怎样呢？如何在架构中执行更改？如何在更改过程中保持数据正确？

处理应用程序的旧版本和新版本之间的转换是一项艰巨的任务。几年前，这是一个问题，一个新版本的应用程序已经准备就绪，但系统管理员需要几天或几周才能部署。DevOps解决了这个问题，但要求开发人员(通过代码或配置)描述将承载应用程序的系统。

应用程序越大，这项任务就越复杂。

• 对于一个很小的web应用程序来说，把源文件复制到服务器上就足够了，
• 对于更大的事件，您必须有一个处理更新过程的自动化流程，并在出现问题时进行回滚，
• 对于更大的系统，在每一个新版本中，都会创建和部署新VM，并回收旧版本，从而确保用户从旧版本无缝过渡到新版本。

编译后的应用程序只是强制/鼓励更早地自动化流程。

业务联系我们更新一些文本，并添加到一个新的pdf文件的链接。我团队的其他成员很快就说，这不应该做，因为这个网站现在是直播的。

海事组织，这种拒绝没有真正的技术原因；他们只是想避免这样做，因为如果自动化不好，这项任务就容易出错。

通常发生的情况是：

1. 应用程序是首次部署的。
2. 该团队花了几个小时来调整配置以使其正常工作。由于小组预期将在三周前交付，每个人都匆忙，没有人记录这些变化。
3. 应用程序现在已经启动并运行。
4. 在几周、几个月或几年里，一些随机的人会在服务器上随意更改一些内容:例如，他们将数据库移动到不同的位置，或者SMTP密码更改，从而导致Web.config中的更改。

如果现在更新新版本，您将回到第一步，并且可能需要几天时间才能恢复正确的配置。由于该网站是实时的，因此应不惜一切代价避免这种情况。

您有项目经理、开发经理或其他开发人员吗？

您无法在go live之后进行部署，这是毫无意义的。

当然，这些改变需要计划，费用和资源，但说“不”是胡说八道。

您所看到的行为的主要原因是这些类型的更改容易出错。手动更新应用程序会导致忘记和失去同步。您仍然应该能够完成新的版本(而且应该很容易)，而不是部分的补丁。

部分更新(如在活动站点上更改某些CSS或文本)可能导致跳过测试、测试或阶段环境不同步，甚至不将代码提交到源代码管理。如果这是代码更改，您甚至可以在没有恢复计划的情况下破坏活动站点。

在.NET中，由于代码是编译的，因此可能会出现其他问题，例如加载时间过长和用户会话丢失。这些问题可以减轻我的交换到一个温暖的环境和使用进程外的会话状态。但是，除非您希望每次执行部署时都考虑这些类型的问题和应用程序特有的其他问题。那么修补现场网站是个坏主意。

随着您的应用程序的大小和人员的来来去去，这可能从一个不便转移到一个严重的问题。因此，为了使事情更安全，我们遵循这样的规则:更新一个实时网站，它必须是一个完整的部署，而不是只是修补。

如果您还没有自动化您的部署(这使得遵循规则变得简单和快速)。新的部署通常是在现有版本的旁边进行的，然后您的网站只是指向您想要的版本的指针(使这一点更加复杂)。

1.0.0  // Old version you can roll back to   
2.0.0 <-- IIS points here

实际上，出于类似的原因，我认为所有的部署都应该是自动化的也包括非.NET部署。一旦您开始自动化部署，您就可以保证它们始终是快速可靠的。