4

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

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

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

举个例子：

  1. 假设我们有一个客户端/服务器产品，为了简单起见，两者都以完全工作的状态开始。我们将这些版本称为client-1.0 和server-1.0。
  2. 一段时间后，对两者都进行了错误修复和功能。现在我们在 client-1.7 和 server-1.2。
  3. 现在服务端的接口改变了，所以客户端也必须改变：server-2.0和client-1.8。
  4. 现在客户端版本为 1.9，发现了一个 bug，我们想测试以前的版本，看看它在哪里停止与服务器一起工作。但是，如果我们回到 1.8 之后，那么服务器也必须恢复。

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

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

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

4

4 回答 4

1

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

可以这样做：

  • 通过 SCM 中的元数据（例如，SVN 确实保留了其元数据及其数据的历史记录）
  • 或通过外部数据库注册当前测试和验证为“一起工作”的所有标签的列表（前提是该列表也被历史化）

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

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

  • 您在该生产环境中没有您的 SCM
  • 因此，您必须依靠一个文本文件来提醒您部署的确切标签。

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

于 2009-01-29T09:20:44.193 回答
1

您似乎在管理依赖项方面没有问题，但您在回归时遇到了问题。

接口负责依赖抽象，单元测试和夜间构建负责变更控制。

如果您需要测试一个历史版本，您需要能够从您的源存储库中获取该标记版本，并将其部署在一个复制但完全独立的环境中。因此，这是在 SCM 中定义发布标签元数据并拥有备用/专用硬件的问题。

于 2009-01-29T09:23:50.257 回答
1

我不知道您使用的是什么语言平台，即 Java、C 等。但这里有一些相关信息，让我在 java 中的生活变得轻松。

有一个名为 Maven 的构建工具用于我的 Java 应用程序。Maven有明确的依赖配置。例如

client-1.0 取决于 server-1.0 - 当您看到 client-1.0 配置时，您会注意到它需要 server-1.0 client-1.7 取决于 server-1.2 client-1.8 取决于 server-2.0 client-1.9 取决于 server-2.0

您发布的每个版本都将在您的 Maven 存储库中可用。如果我想测试 client-1.7，我将简单地从存储库和配置中获取它，我知道它需要 server-1.2，它也可以在存储库中使用。我将开始我的申请和测试。

于 2009-01-29T10:05:16.587 回答
1

使用 RESTful 接口。在真正的 REST 中，客户端学习如何通过服务器返回的响应中的元数据进行导航。通过保持元数据静态，旧客户端可以导航较新的服务器版本。

于 2012-02-02T07:05:46.830 回答