dependencies - 管理不同组件版本之间依赖关系的最佳方法是什么？

Question

我在以前的工作中遇到了这个问题，现在又遇到了这个问题，这意味着我要么运气极差，要么不知道有什么工具或组织系统可以解决这个问题。

在这两种情况下，最终产品都由几个独立的组件组成，每个组件都通过一个商定的接口(interface)与其邻居进行通信。问题是随着时间的推移，界面会发生变化，然后相应的组件也必须更新，以便一切正常工作。

这本身不是问题。问题是当试图返回 SCM 历史时，这使得错误跟踪变得极其困难，因为在某些时候，您尝试调试的组件将不再与系统的其他部分兼容，并且无法针对它们进行测试也没有回滚它们。

举个例子:

假设我们有一个客户端/服务器产品，为了简单起见，两者都以完全工作的状态开始。我们将这些版本称为client-1.0 和server-1.0。

一段时间后，对两者都进行了错误修复和功能。现在我们在 client-1.7 和 server-1.2。

现在服务端的接口(interface)改变了，所以客户端也必须改变:server-2.0和client-1.8。

现在使用 1.9 版本的客户端，发现了一个错误，我们想测试以前的版本，看看它在哪里停止与服务器一起工作。但是，如果我们回到 1.8 之后，那么服务器也必须恢复。

我给出的示例场景非常简化，但问题归结为:强制执行哪些版本的客户端和服务器相互兼容的最佳方法是什么？

我曾考虑通过文档来做到这一点，但不可避免的是，人性会胜利，有人忘记为他们或其他组件更新它们。我也想过通过匹配版本来做到这一点(即，当服务器达到 2.0 时，客户端也被提升)，但问题是客户端可能有其他与服务器无关的组件依赖项，所以它没有意义全面更新他们的版本。

必须有一些解决方案来解决这个问题。有人对我的研究有任何建议或起点吗？

Answer 1

您必须设置一个历史元标签(引用其他标签的标签)

可以这样做:

通过 SCM 中的元数据(例如，SVN 确实保留了其元数据及其数据的历史记录)

或通过外部数据库将当前测试和验证的所有标签列表注册为“一起工作”(前提是该列表也已历史化)

该元标签的历史化特性确保您能够恢复到以前的一组连贯标签以调试系统。

无论您选择何种解决方案，一旦在生产环境中交付，请不要忘记:

您在该生产环境中没有您的 SCM

因此，您必须依靠一个文本文件来提醒您部署的确切标签。

该文本文件应在您构建交付包时自动生成(您将部署到生产中的文件集)