大型项目的依赖管理

Question

我正在从事一个相当大的项目。我们有很多项目，每个项目都有依赖关系。我们使用maven，一般不会有任何问题。因此，在不提供太多细节的情况下，想象一下对于给定的项目，例如 tps-reports，pom.xml 的依赖项部分如下所示：

  <name>TPS-Reports</name>
  <description>
   TPS Reports frontend.
  </description>
  <dependencies>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>gui-components</artifactId>
    <version>2.5</version>
   </dependency>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>multithreading</artifactId>
    <version>3.7</version>
   </dependency>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>utils</artifactId>
    <version>2.3.0.0</version>
   </dependency>
   <dependency>
    <!-- TODO: update to new version -->
    <groupId>com.initech</groupId>
    <artifactId>object-pooling</artifactId>
    <version>1.9.3.1</version>
   </dependency>
  </dependencies>

现在，Initech 有大量例如，依赖于对象池的项目，它还依赖于许多其他组件，例如utils和多线程）。

对于对象池开发人员来说，生活是美好的。这是一个非常稳定的模块，一切都很顺利。与任何其他模块一样，它也具有依赖性。 对象池开发人员都是绅士和淑女，每当他们发现严重错误时，他们都会更新所有依赖于对象池的项目。

现在，object-pooling 版本 1.9.3.1 已经稳定，没有已知的严重错误。开发人员非常努力地添加了大量新功能，一段时间后，他们发布了版本 2.0.0.0。当然，在 1.9.3.1 和 2.0.0.0 之间，还有中间版本（例如 1.9.3.1、1.9.3.2< /code>、1.9.4.0、1.9.5.3 等）。正如我所说，对象池开发人员的生活很美好。版本 2.0.0.0 具有新功能和大量修复。

然而，对于 tps-reports 开发人员来说，地狱即将来临。他们已经使用 1.9.3.1 有一段时间了，由于该版本中没有已知的错误，因此他们对旧版本感到满意。现在，他们想要使用修改后的对象池，因此他们更新了pom.xml以使用版本2.0.0.0，现在看起来就像这样：

  <name>TPS-Reports</name>
  <description>
   TPS Reports frontend.
  </description>
  <dependencies>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>gui-components</artifactId>
    <version>2.5</version>
   </dependency>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>multithreading</artifactId>
    <version>3.7</version>
   </dependency>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>utils</artifactId>
    <version>2.3.0.0</version>
   </dependency>
   <dependency>
    <!-- use object poooling's new features -->
    <groupId>com.initech</groupId>
    <artifactId>object-pooling</artifactId>
    <version>2.0.0.0</version>
   </dependency>
  </dependencies>

他们发现有新的错误。不用说，当这些错误依赖于 object-pooling 的 1.9.3.1 版本时，这些错误并不存在。他们深入研究代码存储库的日志，发现对象池人员不仅完成了数千次提交，而且还使用了最新版本的多线程技术和 utils，其中也有很多提交。

显然，问题可能存在于很多地方。它可以在object-pooling上，它可以在object-pooling和tps-reports之间的交互中，它可以在>多线程或utils或任何奇怪的组合。

问题是：你们如何解决此类问题？如何管理对大项目的依赖关系，而这些项目又依赖于其他项目？有一些工具可以帮助完成这项任务吗？

谢谢！

Answer 1

抱歉，这里没有灵丹妙药：单元测试就是答案。项目越大，自动测试就越重要。

在您的情况下，即使手动测试中出现错误，它最终也会归结为使用该库的特定情况，您也许可以将其减少为单元测试。该测试将在 1.9.3.1 中通过，在 2.0.0.0 中失败。

现在，您可以将测试用例发送给对象池开发人员，并告诉他们在他们通过此测试和其他测试之前您不会升级。这将使他们的生活有点像你的，并且给出足够的测试用例，你的生活最终将更像他们的:-)

如果错误在他们的依赖库中，他们将不得不对下游开发人员做同样的事情。

Answer 2

我会使用多个 pom 配置并将它们全部放入连续集成服务器中，以了解某些测试在哪些情况下会失败。