如何处理多方面项目中的版本控制？

Question

我知道这是个宽泛的问题，所以我会尽量具体。这个问题与其说是一个技术性问题，不如说是一个“组织性”问题。

我们有一个具有以下主要组成部分的多方面项目：

• 服务器，承载核心业务逻辑(数据模型)
• 使用核心业务逻辑的客户后台
• 也使用核心业务逻辑的应用程序API (REST)
• 有智能手机应用程序(iOS和android)使用应用程序API。
• 还有另一个不同于智能手机的平板应用程序(android) --使用相同的应用程序API。

很快，我就会和活跃的客户一起生产。作为任何项目，随着时间的推移，我需要维护所有不同的组件。这意味着可以升级以下所有内容：

• 服务器中核心业务逻辑的代码(由后台API使用，并由移动应用程序产生副作用)。
• API本身(智能手机和平板电脑应用程序都使用)
• 所有移动应用程序(通过appstore/googleplay)

当然，服务器端部分(核心业务逻辑代码和API代码)可以自己立即更改。然而，新的移动应用程序必须由应用商店/googleplay上的客户下载，我不能确定它们是否是最新的。

你能提供任何的指导，良好的做法提示，使这些升级顺利，为客户不冒险？

我需要哪个组件来“版本”？即使客户端没有升级其移动应用程序，如何确保一切正常工作？我应该强迫他升级使我的工作更容易吗？

总之，我应该如何组织使我的多方面的项目长期存在？

Answer 1

由于无法控制移动应用程序何时更新为新版本，因此至少需要对REST进行版本化。如果不这样做，就不可能对该接口进行向后兼容的更改。

除了REST之外，最好也对其他通过网络接口的通信接口进行版本化。这样，您也不会被迫在服务器的同时升级所有后台客户端，并且可以实现一个渐进式迁移到带有"beta测试“期的新版本。

除了对通信接口进行版本控制之外，您还应该尽可能地使更改向后兼容。理想情况下，您可以推出一个仍然完全支持旧客户端的新接口版本，这样他们就不会注意到任何变化。

Answer 2

这个帖子对你的问题提出了一个有趣的观点。

以更实际的方式，如果您有三个组件：

• 2消费者:前端和移动应用程序
• 1 API提供程序:后端

您可以对每个版本使用典型的M.m.p (Major.minor.patch)版本控制方案，但是，在后端url上，您可以将一些内容作为http://youhost/M.m/resourceURI。

随着您的发展和API中的更改不会影响您与消费者的合同，您将保留M.m，就像URL中的那样。从您在BackEnd中更改影响您的消费者(无论是行为上的变化还是对象不同)的那一刻起，您就使用了M.m+1、M+1.m+1或M+1.m。

保持运行的方法是与旧的同时部署新的后端，同时您的用户安装新的使用者，并且慢慢地停止旧的API。

你可以看到一个比我的更好的答案，这里：基于堆栈溢出的REST版本控制

Answer 3

对于相对较小的开发和部署团队，IBM Jazz所使用的客户端N-1兼容性模型可能工作得很好。

尝试将客户端和服务器保持在相同的版本号。而不是管理独立版本及其兼容性的矩阵。

制定一项策略，使客户端版本X.y.y应与X.y.y以上但低于X+2.0.0的所有服务器版本一起工作

对于服务器版本4.0，理想情况下，每个客户端类型都应该有一个客户端版本4.0。但是，应该保持兼容性，以便允许略有不同版本的客户端和服务器。

客户端版本4.x应兼容服务器4.x及以上但低于6.0；服务器4.x应兼容所有客户端3.0及以上版本，但小于或等于4.x

通过这种方式，您可以在服务器上更新一个版本，而不必担心客户端的新版本会立即发布，但只有一个定义良好的兼容性窗口可供维护。

参考: IBM模型[https://www.ibm.com/support/knowledgecenter/en/SSYMRC_6.0.0/com.ibm.jazz.install.doc/topics/c_n-1.html]