如何使用最新的服务器部署支持多个移动应用程序版本？

Question

我正试图找出一个方案，但我在网上找不到任何相关的信息。

假设我正在部署带有后端(v1.0.0)的Android应用程序(v1.0.0)。在某个时候，我将做一些修改，并将应用程序更新为v1.0.1，后端更新为v1.0.1，它们将完美地工作。但是，我如何也支持应用程序的前一个版本(也许新服务器版本为一个特定请求提供了另一种响应格式)？

我想对服务器的每个版本进行单独的部署，但是对于许多更新来说，这将意味着对资源产生很大的影响。而且，在我看来，强迫用户进行更新似乎不是一个好的选择。

Answer 1

从本质上说，你可以采取多种方法来做这件事。实际上取决于您的需求，但现实情况通常是以下内容的混合。

作为一个经验法则，考虑数据模型，将保持兼容。如果合同无法保留，或者您意识到需要进行重大更改，则引入一个新版本的API。如果不能支持旧客户端，则强制更新。您还可以就支持每个早期版本的时间长短达成一致，然后强制更新，这将使您的生活比维护几十个API版本更容易和更简单。

向后兼容数据模型

1. 您必须对每个版本进行反向思考： 考虑到每个发布周期的增量建模。这样你就可以保留东西了。
2. 当您忘记它并且需要根据数据切换行为时： 在我受训的那几年里发生在我身上。如果您忘记添加协议版本，您只需根据数据解码它可能是哪个版本。从一开始，您总是可以在数据上有一个version字段。此外，还可以添加一组兼容的解析器版本。

在数据中包括协议版本：

{
    "data": [ arbitrary data model],
    "protocolVersion": "v1"
}

根据协议版本，您可以决定如何处理服务器端的数据。您不需要只考虑协议的客户端版本，因为您可以发布: 1.0.0、1.0.1、1.1.0，并且只在1.2.0中更改协议。

但我认为问题在于，随着数据随后发生变化，服务器端处理的行为也会发生变化。

Versioned

1. 有时，对于主要版本，您会看到不同的路径：

- [/api/v1/query](http://api/v1/queryName) 
- [/api/v2/query](http://api/v2/queryName)

​

当向后兼容性中断或完全重新考虑后使用。因此，并不是每个版本都会有增量。

1. 在客户端版本中使用查询参数：

- [/api/query?v=1.0](https://api/query?v=1.0)
- [/api/query?v=1.1](https://api/query/v=1.1)

​

与前一个类似，只是写得不一样。虽然我觉得这不是你想要的方式。

跟踪客户端版本和使用的服务版本

实际上，每个客户端版本都有多个请求和多个版本的服务被使用。这使得事情更难以维持。

所有的时间，文件和跟踪。版本和版本管理是非常重要的。知道您从哪个版本构建的git哈希，很多时候它会变得令人困惑，发布后您只更改了一个参数，作为一个快速修复，并且在没有任何版本之后的第二天就不再兼容了。

在每个版本中将所有服务版本映射到客户端版本，了解真正构建的提交并使用标记和发布管理。

在每次发布之前测试所有内容

对向后兼容性有明确的要求。也许您只支持两个旧版本，然后对所有两个客户端进行测试，使用将要发布的服务器测试新客户端。把一切都记录下来。当你满足了释放的标准，就跟它走吧。

摘要

现实是各种解决方案的混合体。对向后兼容性有明确的要求。因此，您可以在每次发布之前进行测试。必要时，强制更新。跟踪发行版，并将每个客户端版本与其版本一起使用的所有服务记录在案。

Answer 2

在服务器上为每个不同版本的应用程序使用开关箱。