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

服务器拥有逻辑，iOS/Android应用拥有UI。常见情况

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

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

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

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

因此，可能我必须首先部署应用程序并放置某种服务器版本检查器，这样，如果服务器具有此新功能的api，则会显示此功能的UI，如果应用程序连接到错误的服务器，则会隐藏新UI。
这看起来很原始。我需要保持到同一服务器的套接字连接，以避免命中错误的服务器，对吗？如果instance/zone/region宕机，用户会突然被重定向到另一个sone/region，而新服务器将没有新的特性api，该怎么办？也许，我的假设是错误的

---

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

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

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

第一种情况：

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

第二种情况：

如果新的客户端应用程序版本需要与旧的服务器应用程序对话（我会不惜一切代价避免），那么新客户端需要一些内部开关来停用功能，例如，当它与不支持此功能的旧服务器对话时，B。API版本计数器可能是解决方案。但它要求客户机能够区分不同的服务器版本。在REST中，您经常会在URL中看到

../v1/.

，但也可以采用不同的解决方法。希望API提供一些机制来获取服务器所说的版本

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