持续部署：如何部署同时影响客户端和服务器的新功能？

Question

服务器持有逻辑，iOS/Android App 持有 UI。常见情况。

在这种情况下，我应该如何使用持续部署方法部署新功能？

我假设服务器端部署如下所示： 我正在触发新功能部署，负载均衡器开始将所有用户的 1% 重定向到具有新功能的服务器实例。如果一切顺利，负载均衡器将开始重定向 10%、30% 等，直至 100%。

对于客户端应用程序也可以这样做，例如使用 Codepush。

所以，如果我在没有应用的情况下部署服务器，那么不会有新功能的使用，因此新部署肯定没有问题。

所以，可能我必须先部署应用程序并放置某种服务器版本检查器，所以如果服务器有此新功能的 api，则显示此功能的 UI，如果应用程序连接到错误服务器，新的 UI 被隐藏了。
这似乎很原始。我需要保持与同一服务器的套接字连接以避免访问错误的服务器，对吗？如果实例/区域/区域将关闭并且用户将突然被重定向到另一个sone/区域并且新服务器将没有新功能api怎么办？可能，我的假设是错误的。

那么，在这种情况下，我应该如何使用持续部署方法部署新功能？

Answer 1

我想说您的问题更多的是服务器/客户端 API 的版本兼容性，而不是 CD。我们有一个类似的要求，即服务器和客户端进行通信，并且两者都不断增强功能。我不知道您的生产软件架构可能会相应地改变需求，但我会尝试提出一些想法。

我将描述两个可能适用于你的案例。

第一种情况：

当您不必面对新客户端版本需要与旧服务器版本通信的情况时，事情会变得更容易。正如您已经指出的那样，首先部署新服务器版本，旧客户端根本不使用新功能。在这种情况下，我的建议是先部署服务器应用程序，然后再开始推出新的客户端应用程序。如果可能的话，我会这样做。它仅适用于新功能不会强制您破坏 API 的情况。

第二种情况：

如果新的客户端应用程序版本需要与旧的服务器应用程序通信，我会不惜一切代价避免这种情况，新客户端需要在内部进行一些切换以停用功能，例如B 当它与不支持此功能的旧服务器通信时。 API 版本计数器可能是解决方案。但它要求客户端能够区分服务器版本。在 REST 中，您经常会在 URL 中看到 .../v1/..，但也可以通过不同的方式解决。希望 API 提供一些机制来获取服务器使用的版本。

我们同时面临这两种情况，协议随着时间的推移发生变化，包括重大变化，因此我们需要实现 API 版本协商机制。