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

我知道这是一个广泛的问题，所以我将尽量具体。这个问题比技术性问题更像是一个“组织性”问题。

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

• 服务器，托管核心业务逻辑（数据模型）
• 使用核心业务逻辑的客户后台
• 也使用核心业务逻辑的应用程序API（REST）
• 有使用应用程序API的智能手机应用程序（iOS和android）
• 还有另一个平板电脑应用程序（android）与使用相同应用程序API的智能手机不同。

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

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

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

您能否提供任何指导和良好操作技巧，以使这些升级顺利进行，并且对客户没有风险？

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

简而言之，我应该如何组织才能使我的多面项目随着时间的推移而上线？

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

除了REST API，最好对通过网络接口传递的其他通信接口进行版本控制。这样，您也不必被迫与服务器同时升级所有后台办公室的客户端，并且可以在“测试版”期间逐步迁移到新版本。

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

这篇文章对您的问题提出了一个有趣的观点。

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

• 2个消费者：前端和移动应用
• 1个API提供者：一个后端

您可以为每一个使用典型的Mmp（Major.minor.patch）版本控制方案，但是，在您的后端url上您可以输入http://youhost/M.m/resourceURI。

随着您的发展，API的更改不会影响您与消费者的合同，因此请保持M.mURL 不变。从目前您在后端的变化会影响您的客户（无论是在行为或对象是不同的改变），你使用M.m+1，M+1.m+1或M+1.m。

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

您可以在这里看到比我更好的答案： 在Stackoverflow上对REST API进行版本控制

我建议您安装一个持续集成服务器，将其连接到代码存储库和快照/发布存储库，并自动进行构建。这将具有许多优点：

1. 每个组件在发布时都会进行版本控制。这包括低级库以及最终产品。
2. 每次提交代码都会触发快照构建。这有助于使开发人员保持诚实，尤其是如果您使用该工具通过电子邮件向破坏构建的罪魁祸首发送电子邮件时。
3. 每个构建都可以运行单元测试。这显着提高了代码质量。
4. 每个发行版都将被标记，因此，如果需要生产修复，则很容易从标签分支并进行修复。
5. 您将需要维护某种兼容性寄存器。（例如BackOffice 1.0.23与REST API 2.0.267等兼容）。我不知道在这个领域有帮助的工具。

我的经验是使用开放源代码工具：SVN，Maven 2，Jenkins和Nexus，但是所有这些都有其他选择。

不要低估学习时间，以使您的团队适应新的需求。但是，一旦他们加快了速度，他们将永不退缩。

对于一个相对较小的开发和部署团队，IBM Jazz使用的Client N-1兼容性模型可能会很好地工作

尝试使客户端和服务器使用相同的版本号。[代替管理独立版本及其兼容性的矩阵]

制定一个策略，使客户端版本Xyy应该与高于Xyy但低于X + 2.0.0的所有服务器版本一起使用

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

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

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

参考：IBM Jazz Model [ https://www.ibm.com/support/knowledgecenter/zh/SSYMRC_6.0.0/com.ibm.jazz.install.doc/topics/c_n-1.html]

首先，让我们从问题的框架入手。您已经问过需要“版本”化的软件。版本是CS中的重载术语，可能表示大约100种不同的事物。我要看的主要内容是：

1. 版本控制-版本控制是一种配置管理工具，可帮助您跟踪快照和开发历史记录。 所有代码都应在版本控制下。我不在乎仅仅是添加到bin文件夹中的便捷脚本，任何值得花时间编写的东西都值得花两秒钟来添加到版本控制软件中。
2. 配置管理-如何控制构建中的内容。所有软件都应具有一定程度的配置管理。我想向管理人员描述版本控制和配置管理之间的区别，因为版本控制只是跟踪开发历史的工具，而配置管理是我们如何创建历史以及如何执行诸如确定代码之类的指南很好。
3. 软件版本控制-为代码发布分配名称。这是很多人在初次看到问题时就迷上的东西，因为他们习惯于看到“ MineSweeper 7.1.29290149210”或所购东西上的任何东西，但是老实说，我发现这是更大问题中最次要的部分。老实说，仅使用1生成的哈希值，而不是太在乎它不是人类可读的含义就可以了。

因此，由于它对我来说是最模糊和最有趣的，因此我将仅关注＃2。对于配置管理，没有一种万能的，千篇一律的解决方案。对于2人或3人的团队而言，行之有效的规则可能过于宽松，以至于无法在需要数百名工人的项目中保持理智。适用于大型团队的规则可能需要小型团队过多的开销。您很可能必须拼凑一下自己的东西才能使某些东西融合在一起，但是我将使用以下列表作为开发配置管理系统规范的一种方式：

1. 如何跟踪我在市场上支持的版本（以及与之相关的问题）？
2. 我将如何决定准备将哪些开发路径发布到生产系统？（它也可以为流程中的任何其他步骤做好准备）
3. 谁应该控制/管理系统的配置？添加要分发给其他开发人员的代码的工作流程是什么？
4. 如何控制相互作用的零件之间的相互作用？我怎么知道更改零件是否会破坏系统的其余部分？
5. 随着时间的推移，我们将如何改善配置管理系统。

需要回答以上问题的帮助吗？您可能应该聘请顾问或软件工程经理...答案可能会填满教科书，并且超出了此类论坛的范围。