服务器保存逻辑，iOS / Android App保存UI。常见情况。
如何使用持续部署方法在这种情况下部署新功能？
我认为服务器端部署看起来像这样： 我正在触发新功能部署，负载均衡器开始使用新功能将1％的所有用户重定向到服务器实例。如果一切顺利，那么负载均衡器会开始将10％，30％等重定向到100％。
对于客户端应用程序也可以这样做，比如使用Codepush。
因此，如果我在没有应用程序的情况下部署服务器，那么就不会有新的功能使用，因此肯定没有新部署的问题。
所以，可能我必须首先部署应用程序并放置某种服务器版本检查程序，因此如果服务器具有此新功能的api，则会显示此功能的UI，如果应用程序连接到错误服务器，新UI被隐藏 这看起来很原始。我需要将套接字连接保持到同一服务器以避免命中错误的服务器，对吧？如果实例/区域/区域将关闭并且用户将突然重定向到另一个sone / region并且新服务器将不具有新功能api，该怎么办？可能，我的假设是错误的。
那么，我如何使用持续部署方法在这种情况下部署新功能？
答案 0 :(得分：1)
我想说你的问题更多的是服务器/客户端API的版本兼容性而不是CD。我们有一个类似的要求，服务器和客户端通信，并且两者都不断增强功能。我不知道您的生产软件架构可能会相应地改变需求，但我会尝试提出一些想法。
我将描述两个可能适合你的案例。
第一种情况：
当您不面对新客户端版本需要与旧服务器版本通信的情况时，事情会更容易。正如您已经指出的那样，首先部署新服务器版本，而旧客户端根本不使用新功能。在这种情况下，我建议首先部署服务器应用程序，然后开始推出新的客户端应用程序。如果可能的话我会这样做。仅当新功能不会强制您破坏API时，它才适用。
第二种情况：
如果新客户端应用程序版本需要与旧服务器应用程序通信，我会尽力避免这种情况，新客户端需要在内部进行一些切换以停用功能，例如： B当它与不支持此功能的旧服务器通话时。 API版本计数器可以是解决方案。但它要求客户端能够区分服务器版本。在REST中，您经常会在URL中看到.../v1/..，但也可以以不同方式解决。希望API提供一些机制来获取服务器所说的版本。
我们同时面对这两种情况，协议随着时间的推移而发生变化，包括重大变更，因此我们需要实现API版本协商机制。