Maven 多模块项目持续集成的标准实践

Posted

技术标签:

【中文标题】Maven 多模块项目持续集成的标准实践【英文标题】:Standard Practice for Continuous Integration of Maven Multi-module projects 【发布时间】:2010-05-14 21:37:23 【问题描述】:

我查了一下,找不到一个好的答案:

我们有一个多模块的 Maven 项目,我们想要持续集成。我们想到了两种策略来处理这个问题:

让我们的持续集成服务器(在本例中为 TeamCity,但我之前使用过其他服务器,他们似乎也有同样的问题)指向聚合器 POM 文件,然后一次构建所有内容 让我们的持续集成服务器指向每个单独的模块

对此有标准的首选做法吗?我检查了 Stack Overflow、Google、Continuous Integration book,并没有找到任何东西,但也许我错过了。

【问题讨论】:

【参考方案1】:

至少,Hudson 的标准练习是您的首选。一方面,在 Maven 中,如果所有项目不在反应堆中,您的构建可能无法很好地工作。另一方面,试图让它们分开构建会让你陷入快照管理的困境。如果中间的一个发生了变化,而你试图只构建它,maven 会去寻找它的依赖作为快照。它得到什么取决于其他项目的构建顺序,以及您是否发布快照。

如果你有这么多项目,或者这样不相关的项目,构建它们都是一个问题,那么我建议你需要考虑分解。使父级成为一个单独的、已发布的项目,为它们中的每一个(或它们的每个子组)赋予一个 Trunk/Tags/Branches 结构,并使它们依赖于发布,而不是快照。

【讨论】:

【参考方案2】:

理想的做法是运行反应器构建以仅构建包含更改的模块(使用--projects 选项)依赖于它们的模块(使用--also-make-dependents 选项)。

但 TC 目前不支持等效功能(请查看 TC 5 EA: Maven 2 dependency triggers not working...),因此良好的做法是运行完整的反应堆构建(您不希望单个模块在没有被警告的情况下破坏依赖它的模块,您希望保持连贯的 SNAPSHOTS 集同步)。

【讨论】:

谢谢! Hudson 是否支持您链接到的高级反应堆选项? @JamesKingsbery 没有。但它确实提供了类似的配置选项(“在构建 SNAPSHOT 依赖项时构建”)。

以上是关于Maven 多模块项目持续集成的标准实践的主要内容,如果未能解决你的问题,请参考以下文章

Centos7实现基于Jenkins和GitLab的持续集成与部署maven项目

centos+Jenkins+maven搭建持续集成

持续集成中MAVEN的那些事儿

什么是持续集成

占坑!利用 JenKins 持续集成 iOS 项目时遇到的问题

jenkins+maven+git持续集成部署问题总结