【测试入门序列】持续集成与Jenkins

什么是Jenkins

Jenkins 是一套持续集成软件，前身是 Hudson，Sun 被 Oracle 收购后为了开源分支的名字就从 Hudson 改成了 Jenkins 并继续发展。 Jenkins 的 Logo 是个小老头，比较好玩：

什么是持续集成 ?

持续集成，听上去高大上，实际实践很简单：无非就是搞一个独立的应用，负责定时拉源码，然后执行一些重复性工作，如编译打包、执行测试脚本等。执行结果会邮件给相关人员，并且提供了 WEB 界面查看执行日志，历史执行结果一目了然。当然了，持续集成背后还有很多理念，就不一一追究了。

Jenkins 就是这么一个工具，帮助开发测试人员做一些重复性劳动。其核心能力就是能够执行一段 Shell 脚本，脚本可由工程人员定制。

以上是我的理解。下面是专业解释：

大师 Martin Fowler 对持续集成是这样定义的：持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

为什么要做持续集成？

为什么要做持续集成呢？ 重复的活儿没人喜欢做，但很重要。重复的过程中我们能及时发现问题并整改。总是靠人来做重复性劳动，总会疲惫，最后流产。所以，持续集成工具，是持续集成中的重要一环。

但是，理解了持续集成的本质，就算没有工具，也是可以人肉做持续集成的，特别是初始阶段做不到面面俱到的时候。例如，每天晚上跑一次测试脚本，每周做一次备份，都是一种持续集成。只是“持续”间隔，触发时机差一点罢了。

做好持续集成的前提

可自动化执行的测试集。

有了测试集，才能知道集成是否成功，是否出现新问题。只是看编译是否成功，太 easy，不是持续集成要解决的核心问题。

参考文献：http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html

持续集成对我未来工作的启发

1. 代码必须有测试集
2. 作为代码和发布之间的桥梁，确保错误代码不会对外发布