我在思考一个想法,想向开发者社区提出一个问题。当我在实践中使用 maven 进行大型 JAVA 项目时,它具有惊人的好处。然而,项目正在迅速增长,随着时间的流逝会出现更多的模块,从而导致巨大的构建时间,而这对持续集成没有影响。
问题 - 是否有一些开箱即用的功能可以允许智能项目构建,它可以首先检查模块目标 jar 是否与位于本地 maven 存储库中的不同。如果后者是真的,maven 可以继续到下一个模块而不重建和重新部署相同的模块吗?
问候
最好的办法是切换到支持并行构建的 Maven 3
mvn -T 3.0C clean package
还可以帮助构建可以通过 Maven 实现的更改:
mvn -pl module -am package
像 jenkins 这样的许多 CI 系统也支持增量构建。进一步检查正在运行哪种测试?你可以并行运行单元测试吗?(maven-surefire-plugin)。这些单元测试真的是单元测试还是其中一些可能是集成测试?
这个问题没有灵丹妙药。这是许多大型项目所面临的普遍问题。
CI 被触发的事实通常是由 SCM 提交引起的,所以我建议某些事情总是发生变化。
在不知道您使用的是什么 CI、如何配置模块等的情况下,除了一些基础知识之外,我无法提供太多建议。
1) 确保您在 CI 中配置的模块尽可能细化 - 即尽可能小的构建单元。这意味着单个提交不需要重建大量代码。
2) 开发者习惯:只提交一个完整的工作单元。这就是 Git 的意义所在。开发人员在本地提交,然后仅在工作单元完全完成时才推送到主服务器。这减少了下游 CI 构建。
3) 观察你在 Maven 中使用的报告和模块。有些需要永远运行。你真的需要它们吗?
问题 - 是否有一些开箱即用的功能允许智能项目构建可以首先检查模块目标 jar 是否与位于本地 maven 存储库中的不同?[...]
我所知道的唯一“聪明”是跳过您不需要的构建中的“清理”阶段——这样一些源将不会被编译,或者资源不必要地重新生成。尽管如此,项目将被重新打包。
您也可以考虑将一些模块排除在不同的开发周期中(除非您确实需要在每个版本中对所有模块进行更改)。然后可以将不经常更改的模块作为依赖项包含在存储库中——它们需要单独构建和部署。
(假设:团队内部存储库。)
离线(如果被插件认可)构建:
mvn -o ...
(假设:IDE 构建绕过 maven(在后台增量编译。)
跨模块依赖的限制。从其他模块导入非常容易,有时会出现纠缠不清的依赖关系。