在交付管道中管理多个maven工件

时间:2016-07-06 17:40:11

标签: maven snapshot continuous-deployment devops delivery-pipeline

这不是一个编程问题,而是一个传递管道问题:

我们的产品由几个maven工件构成,每天发布SNAPSHOTS(2.0.1-SNAPSHOT)并每周发布版本(2.0.1)。 在开发过程中,我们的工件完全通过其他工件的快照进行测试,并且一切正常。在许多情况下,工件会同时开发,因此在没有向后兼容性的情况下依赖于彼此

管道的最后一个阶段使用其他工件的发布版本测试特定工件的候选版本,因此我尝试发布工件A的2.0.1,该工件已通过2.3.5-SNAPSHOT测试B件并通过了。如果它通过了工件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能够每周发布。

我正在寻找的是修复我的交付渠道中的这个漏洞。我是否需要另一个阶段?发布收集快照的另一个SNAPSHOT?

1 个答案:

答案 0 :(得分:0)

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

如果A依赖于B作为第三方库,则在测试期间不应使用B的SNAPSHOT。通过这种方式,您将永远不会被即将发布的B.阻止。

如果A依赖于B作为多模块项目中的模块,则应手动执行maven的工作。这意味着你需要先建立B的RELEASE,然后再建立A的RELEASE。