处理桌面产品和云产品之间的版本控制的最佳方法，而其中一个依赖于另一个
假设有两个产品，产品A和产品B。
- 产品A是一种桌面产品，客户可以在他们的机器上下载并在本地安装。该产品遵循一个典型的版本控制过程，季度发布将发送给客户，由他们自行决定安装。例如，2023.05将是2023年5月发给客户的版本。客户可以选择下载并安装此新版本，也可以保留当前版本。
- 产品B是作为一个简单的云API完成的云产品。该产品的版本控制生活在两个环境中:开发和生产。如果开发人员需要添加功能，他们将在其机器上进行本地更改，并向表示开发环境的git分支发出拉请求。在测试完成了开发环境的更改之后，就会向代表生产环境的主分支发出拉请求。
现在是扳手。产品A取决于产品B。当内部测试人员正在测试产品A的开发版本时，产品A将检查产品B的开发版本。
我的问题是:这是产品B中版本控制的最佳方法吗？这方面的行业标准是什么？如何才能改善这种情况？
对于我们来说，产品B的版本控制在很大程度上是可以的。我们只需要确保在对产品B进行更新时，我们不会对它做任何破坏性的更改。至于更好的版本控制系统，我有一些想法。
- 在产品B中实现与产品A相同的版本控制系统。每个季度发布的产品A将使用与产品B的相同季度发布对应的URL。我认为这种方法的唯一问题是，每个季度发布的产品B都需要一组新的云资源来托管所述发布。本质上，我们会膨胀我们的云资源。请记住，根据我们的客户是否使用某一版本的产品A来执行云资源的例行清理是微不足道的。
- 使用上面提到的相同版本，但不是为每个季度发行版创建新的云资源，而是要求产品A将自己的版本发送给产品B。然后，产品B将根据它收到的该版本更改其行为。这种方法避免了云资源的膨胀。相反，它会使代码膨胀，因为对产品B所做的每一项更改都需要在代码中显示为新的文件/函数，以避免更改产品A的以前版本已经使用的任何代码。
- 迫使我们的客户升级他们的产品A版本，一旦一个新的版本是可用的。
你们都怎么想？
回答 1
Software Engineering用户
发布于 2023-01-19 08:14:23
最“用户友好”的解决方案是在A和B之间建立一个最稳定的接口，并在较长的时间内保持B与部署到web的任何新版本尽可能向后兼容。
这通常不会妨碍您在B中实现新特性，即使只有较新版本的A可以使用它们。您可以实现一个机制，其中A可以询问B是否有某个特性可用，并且只在这种情况下在A的UI中提供相关功能。
向后兼容性使A的用户有机会尽可能地使用他们满意的版本。它还让他们有机会切换回一个旧版本的A，当它的新版本有一些恼人的错误，你的团队将只修复下一个版本，将于下个季度发布。
当然，这是有缺点的。随着时间的推移，您将在B中生成一些遗留代码，您希望早晚摆脱这些遗留代码，但您必须牺牲向后兼容性。当然，当只有5%的用户仍然使用旧版本时，您可能倾向于不支持A和B的五年前版本。因此，您应该跟踪A的哪个版本确实在使用，是的，A应该始终将其版本号发送到B。这使您有机会检查是否真的需要支持B中的不推荐功能，以及有多少用户可能因为强迫他们升级而受到干扰。
它还将使您有机会实现到更新版本的平稳过渡过程。例如，当A将其版本号发送给B时，B可能会发送一条答复消息，例如：“您仍在使用1.0版本，服务B下个季度将不再支持该版本。请要求管理员安装5.0或更高版本。”--这样A就可以向用户显示此消息。
然而，我只会强迫用户升级到一个更新的版本，当他们真的必须，你肯定负担不起保持向后兼容了。我不能告诉您这种强制升级的合理时间间隔在您的情况下，但是当安装升级涉及用户公司外部IT部门的一些手工工作时，更好地计划几年，而不是季度。
https://softwareengineering.stackexchange.com/questions/443479
复制
相似问题
处理长期项目的产品版本控制和分支的最佳方法是什么？
产品版本控制与语义版本控制
计划项目和计划产品之间的区别
一个小团队的产品开发和维护的最佳过程？
什么是处理编辑产品图像的好方法？
领取专属 10元无门槛券
AI混元助手 在线答疑
洞察 腾讯核心技术
剖析业界实践案例
腾讯云开发者
