有一个使用测试数据库的测试服务器。我们在测试服务器上测试网站。如果没问题，我们将网站和数据库模式从测试服务器更新到生产服务器。但是这种方法是非常痛苦和危险的。
首先，我们必须将用户重定向到维护页面，因此网站会暂停一段时间。
其次，如果更新时出现问题，我们必须回到旧网站，因为我们不能让网站长时间处于维护模式。
因此，我正在寻找一个可靠的解决方案来更新 IIS 网站和 Sql Server 数据库，而不会丢失数据并使用维护模式。有没有办法做到这一点？大型网站如何在不丢失数据和暂停的情况下做到这一点。
我们考虑过使用发布候选网站。我们计划暂时使用这个 RC 网站。首先，我们更新 RC 站点，然后交换 RC 和生产站点之间的绑定。但是这次数据库有问题。因为我们可以更改数据库架构，而旧的架构不能与新数据库一起使用。因此，如果我们使用带有 temp db 的临时站点，就会有数据丢失。此外，如果临时站点使用旧的生产数据库，则更新后的网站将无法使用旧数据库。所以我需要一个可靠而实用的解决方案来解决这个问题。
这比你想象的要复杂几个数量级。这与HA 和连续集成无关。这些都不会提供您需要的东西，它们只是更复杂的难题的一部分。
根本不可能以对模式更改发生时透明/无视的方式编写代码更改。充其量您可以以支持 v. N 和 v. N+1 的模式的方式编写代码，这本身就是一个很大的挑战。但是，当它从 v. N 转换到 v. N+1时，不可能以支持模式的方式编写代码。对于在模式上运行的代码，部署引起的模式更改必须是原子的。由于架构更改本身不能是原子的，因此升级有两种可能的途径：
在架构更改期间使代码脱机。这就是您现在正在做的事情，也是最安全的方法。当然，这意味着服务可用性停机时间并运行您已经经历过的风险（升级失败的回滚、冗长的升级等）。这种方法的一个变体是将服务重定向到数据的只读副本，并提供降级的服务体验（在停机期间不可能进行任何更改），这可能会或可能不会接受，具体取决于业务细节。
待机升级。这意味着您拍摄服务数据的快照（各种 HA 解决方案可能会提供开箱即用的备用快照，例如日志传送）。升级快照，然后将真实服务数据上发生的所有事务应用到升级的快照。这总是很棘手，因为它需要一种技术来检测、捕获和应用更改（例如更改跟踪、复制、自定义解决方案等），并且需要将每个更改转换为新的、升级的模式。一旦升级的模式与主服务的更改保持同步，服务就可以重定向到升级的模式。这种重定向也比听起来要复杂得多。对于一个选择何时切断旧模式并停止接受新更改的时刻，同时确保所有将更改应用于新升级的模式数据库本身就是一个挑战。另一个挑战是解决代码理解升级前和升级后模式版本的冲突。正如我所说，开发同时处理这两种情况的代码是有问题且容易出错的，因此一种解决方案是再次让服务在短时间内离线并替换代码。另一种解决方案是拥有一个备用服务，运行处理升级后数据库模式并连接到升级后数据库的代码，并将实时请求重定向到您的备用、升级服务。
当一个更大的部署解决方案的特定服务必须升级时，我什至没有触及服务交互这个棘手的话题。这是服务 API 协议向后兼容性发挥主要作用的时候，它允许升级后的服务与其对等服务一起发挥作用。
最终没有任何灵丹妙药。我目睹了单机大型数据库部署需要数周时间才能推出版本 N+1，转录复制连续地为升级后数据库模式提供升级前数据库的更改。我目睹了数千台机器分阶段部署版本 N+1，这是一场复杂的舞蹈，需要在几天内更改代码和数据以实现升级后的全部功能。这个问题很简单。
这就是 Azure 的绝妙之处。Azure 云平台允许登台服务器和生产服务器。您可以对其进行设置，以便在将更改提交到 Git 或 TFS 后，它会自动推送到登台或生产服务器。您还可以设置为手动推送更改。大多数 ORM 库（如 Entity Framework）都支持迁移。
有关此主题的更多信息，例如： 当数据库架构更改 暂存或生产实例时 Azure 无缝升级？
您正在描述一个高可用性解决方案 (HA)。HA 解决方案很昂贵，而且很快就会过大。您需要为您的应用程序和数据库服务器提供冗余，这意味着设置一个数据库集群。所有这些都会增加您部署更改所花费的时间，但代价是您的应用程序始终可用。
部署的主要内容是有一个可重复的过程。所以我最好的建议是尽可能地编写脚本或自动化。