我在我以前的工作中遇到了这个问题，现在再次出现在我现在的问题上，这意味着我要么运气极差，要么不知道某些工具或组织系统可以解决这个问题。
在这两种情况下，最终产品由几个独立的组件组成，每个组件都通过与其邻居商定的接口进行通信。问题是，随着时间的推移，接口将发生变化，然后必须更新相应的组件，以便一切都能继续工作。
这本身不是问题。问题是，当尝试返回SCM历史记录时，这会使错误跟踪变得非常困难，因为在某些时候，您尝试调试的组件将不再与系统的其他部分兼容，并且无法针对它们进行测试没有回滚它们。
采用以下示例：
我给出的示例场景非常简化，但问题归结为：强制哪些版本的客户端和服务器彼此兼容的最佳方法是什么？
我已经考虑过通过文档来做到这一点，但不可避免地，人性会取得胜利，并且有人忘记为他们或其他组件更新它们。我还考虑过通过匹配版本来实现它（即，当服务器命中2.0时，客户端也得到提升），但问题是客户端可能有其他与服务器无关的组件依赖关系，所以它没有意义全面更新他们的版本。
必须有一些解决方案来解决这个问题。有没有人对我的研究有任何建议或起点？
答案 0 :(得分：1)
您必须设置历史记录元标签（引用其他标签的标签）
可以这样做：
该元标签的历史性质确保您能够恢复到先前的一组标签以调试系统。
无论您选择哪种解决方案，都不要忘记，一旦在生产环境中交付：
构建交付包时，应自动生成该文本文件（将部署到生产中的文件集）
答案 1 :(得分：1)
您似乎没有管理依赖关系的问题，您有一个回归的问题。
接口负责依赖抽象，单元测试和夜间构建负责变更控制。
如果您需要测试历史版本，则需要能够从源存储库中获取该标记版本，并将其部署在复制但非常独立的环境中。因此，这是在SCM中定义发布标签元数据并具有备用/专用硬件的问题。
答案 2 :(得分：1)
我不知道你使用了什么语言平台，即Java，C等。但这里有一些相关的信息让我的生活变得简单。
有一个名为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，它也可以在存储库中使用。我将开始我的申请和测试。
答案 3 :(得分：1)
使用RESTful界面。在真正的REST中，客户端将学习如何通过服务器返回的响应中的元数据进行导航。通过保持元数据静态，较旧的客户端可以导航较新的服务器版本。