Maven持续集成最佳实践

持续集成是你在开发过程中经常会用到的一个最佳实践，它是高效软件开发生命周期（SLDC）至关重要的一部分。如果还没使用这一实践，那么应该立刻就开始使用。持续集成最大的好处是，它能帮你立刻找出引入到系统中的错误，而不是在很多天之后看到测试失败，或者在QA阶段再发现重大错误。本文并不是要介绍CI的优点，本文是介绍如何建立一个最佳的使用Maven的CI环境。这里是一些关于如何在一个CI系统（如Hudson）中运行Maven构建的贴士。

 

#1 自动化Snapshot部署

按照我的经验，最好让CI系统部署你的snapshot。这是保证仓库内容和源码控制系统保持同步的最可靠的方法。要在实践中使用这种方法，你需要结合CI和仓库管理器，如 ，它能自动的清除snapshot。我管理过一个项目，它在不到一周的时间内生成了>300gb的snapshot。使用一个仓库管理器会让你保持稳健。

#2 隔离本地仓库

另一个CI设置至关重要的组成部分是本地仓库隔离。Maven中的本地仓库是放置所有Maven下载和生成的构件的地方，并且当前它不是多线程安全的。虽然产生冲突的可能性很小，但它还是会发生的。

让每个项目有一个本地仓库最主要的原因是，这是测试你的项目是否基于公司仓库可构建的唯一方法。如果你没有单独的本地仓库，那么一个构建的产品即使不在公司仓库中，也还会被CI上另一个构建看到。这里说的很重要，因为CI的一个功能是，它应该能够验证代码对于一个真实的开发者来说是可构建的。

提示：使用 -Dmaven.repo.local=xxx 来为每个构建定义唯一的本地仓库。

#3 周期性的清除本地仓库

为了进一步的验证仓库的内容，以及管理硬盘空间，我每晚都清除本地仓库。如果仓库有变化或者构件被移除了，CI系统会检测到。为了方便的清除所有本地仓库，我倾向于将所有本地仓库组织到同一个目录下，如 /opt/repos/*。

很显然拥有多个本地仓库比起一个仓库来说需要更多的硬盘空间，因为有很多依赖的重复，但即使在我们的 上，所有的仓库的总大小也不到10gb。当你不控制snapshot，也不每晚清除仓库，不保持对它的控制，本地仓库就会慢慢的变得巨大。

提示：使用你的CI系统本身来安排本地仓库清理。这样当Maven糊涂的时候，任何人都可以手动的从UI上清理仓库。

久而久之，我也发现了一些更简单的技巧：

#4 开启批处理模式

提示：在构建中开启 -B（batch，批处理）模式。这会让日志变短，因为这避免了依赖下载过程的日志。这也能确保构建不会因为等待用户输入而挂起。

#5 开启完全堆栈跟踪

提示：开启 -e 能让Maven在遇到构建异常的时候产生完全的堆栈跟踪信息。这让我们更容易根据构建失败结构的日志或者email中理解问题，而不用重新构建一次。

#6 打印测试失败至标准输出

提示：开启 -Dsurefire.useFile=false 。这是我最喜欢的选项之一，因为它能让surefire打印测试失败到标准输出，因此也就能被包含在构建失败日志或email中。这样就节省了你的时间，不用再为了一个简单的堆栈日志去机器上寻找surefire报告。

#7 总是检查Snapshot

提示：开启 -U 让Maven总是最检查新的snapshot。该选项同样也可以在CI系统的setting.xml中开启。（提示4和6同样也可以在settings.xml中声明）

小结

使用上述的设置和过程会让每次build都将构件推入仓库中。接下来下游的build会有其自己的干净的本地仓库，然后检测仓库管理器以获取最新的snapshot。然后每天至少一次，本地所有的东西都被清除，所有的依赖都从仓库管理器抓取。

自然的，所有这些更新的清除工作都会给CI和仓库管理器之间的网络带来一些负荷。如果它们共享一个高速的网络，那么没什么问题。但如果你的仓库管理器和CI系统并不靠近，那么你应该在CI系统旁放一个仓库管理器，它代理远处的仓库，并能消除网络对每日本地仓库清理的影响。

注意： 如果你想要遵循这些提示，那么很重要的一点是下载一个 。清除你本地仓库的内容，每天每个项目都从中央仓库下载所有依赖，会造成中央Maven仓库的网络拥堵。

 

注： 在settings.xml中开启4,6,7：

#4: false

#6: true —— 在actived profile中

#7: always —— 在repository定义中