1

这不是一个编程问题，而是一个交付管道问题：

我们的产品由几个 maven 工件构建而成，它们每天发布 SNAPSHOTS (2.0.1-SNAPSHOT)，每周发布版本 (2.0.1)。在开发过程中，我们的工件使用其他工件的快照进行了全面测试，并且一切正常。在许多情况下，工件是同时开发的，因此相互依赖而没有向后兼容性

管道的最后阶段使用其他工件的发布版本测试特定工件的发布候选，所以我正在尝试发布工件 A 的 2.0.1，它使用工件 B 的 2.3.5-SNAPSHOT 测试并通过. 如果通过，工件 A 被释放（2.0.1-SNAPSHOT 变为 2.0.1）

这是死胡同，因为工件 B 还没有发布 2.3.5（它会在几个小时内发布）。所以很明显，工件 A 在这个阶段会失败，因为它正在针对工件 B 的 2.3.4（这是 B 的最新版本）进行测试。

让我们假设所有工件都有相同的管道。

简单总结一下： Artifact A is at 2.0.1-SNAPSHOT attempting to release 2.0.1, its latest release is 2.0.0 Artifact B is at 2.5.2-SNAPSHOT attempting to release 2.5.2, its latest release is 2.5.1

stage 0 test -> A 2.0.0 with B 2.5.1 - PASSED

stage 1 test -> A 2.0.1-SNAPSHOT with B 2.5.2-SNAPSHOT - PASSED

stage 2 test -> A 2.0.1-SNAPSHOT with B 2.5.1- FAILED

我知道在 B 版本 2.5.2 之前它将继续失败，但我如何在我的交付管道中考虑到这一点。我希望工件 A 能够每周发布。

我正在寻找的是修复我的交付管道中的这个漏洞。我需要在管道中进行另一个阶段吗？释放收集的快照的另一个快照？

4

1 回答 1

0

我认为您需要确定 A 和 B 之间的依赖类型。

如果 A 依赖于 B 作为 3rd 方库，则您不应该在测试期间使用 B 的 SNAPSHOT。这样，您将永远不会被即将发布的 B.

如果 A 依赖于 B 作为多模块项目中的一个模块，您应该手动执行 maven 的工作。这意味着您需要先构建 B 的 RELEASE，然后再构建 A 的 RELEASE。

于 2016-07-06T22:32:57.827 回答