Asp.net 部署。如何推送到生产服务器
想象一下，我们有一个复杂的 ASP.NET 解决方案：MSSQL + ASP.NET MVC + ASP.NET Web Forms + 托管在 IIS 中的 WCF 服务。
必须每周一次将解决方案部署到对用户透明的单个生产服务器上。部署可以包括数据库方案的更改、较小的 IIS 重新配置、文件替换。部署会消耗时间并可能影响正常运行时间。
如何在不中断用户的情况下进行部署或最大限度地减少停机时间？有哪些技术和最佳实践？
（例如切换暂存/生产环境）
Imagine that we have a sophisticated asp.net solution: MSSQL + ASP.NET MVC + ASP.NET Web Forms + WCF Service hosted in IIS.
Once a week the solution must be deployed to a single production server transparently for the users. The deployment can include changes in database scheme, minor IIS reconfiguration, replacement of files. The deployment consumes time and may affect uptime.
How can I deploy without the interruption of users or minimize the downtime? What are the techniques and best practices?
(e.g. switch staging/production environments)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您最关心的是正常运行时间，您可以查看站点的负载平衡服务器 - 一台服务器可以被删除、更新，然后恢复，同时更新另一台服务器。您需要了解在这种情况下如何管理会话，例如使用 sql 服务器或状态服务器机制。
If your overriding concern is uptime, you could look at load balanced servers for the site - one can be taken down, updated and then brought back up while the other is then updated. You'd need to look at how you manage your sessions in this scenario, e.g. use sql server or state server mechanisms.
我无法提供完整的解决方案，但有几点“对我有用”：
将数据库升级分为 (a) 向后兼容的更改和 (b) 重大更改。这样，您就可以在旧版本软件仍在运行时运行第 (a) 部分（添加字段、添加表、添加索引...）。对于 (b) 部分（更改字段类型、转换数据……），我认为不可能避免停机。尝试使大多数数据库更改不会造成破坏。
宣布停机时间，以便您的用户能够适应。升级时，请使用app_offline.htm 功能 确保您的用户看到一条很好的错误消息来解释情况。它还确保您的应用程序被重新加载。对 Web 应用程序进行就地、无停机升级而不重新加载（即“仅替换文件”）可能会导致奇怪的错误。
测试升级：制作生产系统的副本（软件加数据库），这应该在系统运行时可行。在测试系统上执行升级。如果升级过程中出现问题：解决问题，改进升级过程并重复。
I cannot offer a complete solution but a few points that "worked for me":
Split your DB upgrades into (a) changes that are backwards compatible and (b) breaking changes. That way, you can run part (a) (add fields, add tables, add indexes, ...) while the old version of the software is still running. For part (b) (change field types, convert data, ...), I don't think it is possible to avoid downtime. Try to make most DB changes non-breaking.
Announce the downtime so that your users can adapt to it. While you are upgrading, use the app_offline.htm feature to make sure your users see a nice error message explaining the situation. It also ensures that your application is reloaded. An in-place, no-downtime upgrade of a web application without reloading (i.e. "just replace the files") can cause strange errors.
Test the upgrade: Make a copy of the production system (software plus database), which should be doable while the system is running. Perform the upgrade on a test system. If there are problems during the upgrade: fix the problems, improve your upgrade procedure and repeat.