asp.net - 发布管理 - 发布给用户子集 - 它对于面向公众的网站将如何工作

Question

我在某处读到(抱歉不记得来源了)Facebook 周二发布了这一消息。他们首先向内部员工发布新功能，然后向一小部分外部用户发布，最后向全世界发布。我相信谷歌也做了类似的事情

我主要使用 Microsoft 堆栈(用于源代码控制的 TFS、IIS、asp.net、具有大量数据的 SQL Server)。当然是面向公众的网站，因此它们必须 24x7x365 全天候运行。虽然我可以设想仅在其中一台服务器(在网络场中)上发布我的 api/dll 并对其进行测试，但如果有数据库(存储的过程签名、表架构更改)，我将如何做到这一点？目前，我们正在对 SP 进行版本控制(新的将是 mySPNameV2，旧的将是 mySPNameV1 - 两者都采用不同的参数集，因此进行重命名)，新的 API 将使用 SP-V2，而旧的 API 将继续使用 SP -V1。

我看到了一些设计味道，但是有更好的方法吗？

编辑:我们仅将新代码发布到一台服务器并对其进行测试，困难的是您将如何抽象(可能抽象不是正确的词，但您明白了)数据库模式从多个并发版本的更改应用程序

Answer 1

在我的公司，我们几乎总是以交错的方式发布任何主要版本。我们通过为用户表中的每个新功能添加一个标志来实现这一点。默认情况下，该标志设置为 false；当我们向更多用户推出该功能时，我们只需切换数据库表中的标志即可。

这意味着在应用程序级别，我们必须确保在所有位置检查此标志。代码推送到所有服务器。进行数据库更改；但仍然只有部分用户看到这个新功能。

在数据库级别，我们确保对 SP 的任何更改都是“向后兼容”的。这是通过遵循一些简单的规则来完成的:

1. 添加到 SP 的任何新参数都必须位于参数列表的末尾。
2. 新参数应该有一个默认值。这样做是为了不会中断对 SP 的现有调用。
3. 如果必须更改 SP 的现有参数(或者必须更改参数的顺序)，那么显然对 SP 的所有调用都会更改。但 SP 的编码方式既支持启用该功能的用户，也支持未启用该功能的用户。
4. 大多数表更改都与添加新列有关。当我们必须修改现有列时，这种情况确实很少见。所有新列都添加了默认值或允许 NULL。

对于 API，我们的大多数参数都是作为自定义对象(结构)传递的。这样我们就可以向 API 方法添加新参数，并且仍然可以防止对 API 的现有调用中断。

此外，对于每个用户，我们都会存储他们正在使用的 API 版本。根据版本的不同，用户会访问不同的 API URL。因此，基本上，当用户第一次调用 API 进行身份验证时，我们会传递一个新的 API URL(基于用户的 API 版本)。对于所有后续调用，它们都应该调用新的 URL。 Salesforce.com 的 API 调用也遵循这一点。