持续集成（Continuous Integration）基本概念与实践

本文由Markdown语法编辑器编辑完成。

From https://blog.csdn.net/inter_peng/article/details/53131831

1. 持续集成的概念

持续集成（Continuous Integration）的概念有很多不同的版本，持续集成的出现是为了配合敏捷开发（相对于瀑布开发）的速度和效率而产生的一个用于编译、测试、发布、部署的工具。

为什么叫持续呢？因为编码人员每天都会向项目提交代码，因此项目源码每天都会发生改变，为了能够验证最新的代码是否能够被成功编译，是否会影响前面迭代已经通过的自动化测试case，是否能够打出完整的可执行包供测试人员进行测试……。通过每天，甚至是每次提交代码后的持续集成，可以很快地得到反馈，并且易于追溯，即使出了问题也很容易知道是由于哪一位开发人员的提交而导致的。

持续集成（CI）是一种实践，可以让团队在持续的基础上收到反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。

通俗一点儿说：
就是指对于开发人员的每一次代码提交，都自动地把Repository中所有代码Check out到一个空目录，并且自动运行所有Test Case。如果成功则接受这次提交，否则告诉所有人，这是一个失败的Revision。

持续集成一般通过编写好的python等脚本，自动完成一系列集成所需要的步骤。从代码的check out, 构建项目工程，编译源代码，生成可执行包或安装文件，压缩打包，上传到公司或项目组的FTP等位置……

如果不想每次提交都去集成的话，可以选择在一个固定的时间点去集成，比如每天晚上等项目组的所有成员都已经把当天的代码提交完毕后，启动集成。当第二天上班的时候，测试人员会去FTP下载最新的项目包，开始测试开发人员前一天提交的代码是否正确。这也是Daily Build的概念来源，即每日构建。

2. 持续集成的工具

有一篇文章介绍了持续集成的八大工具，分别是：

Hudson
CruiseControl
Continuum
QuickBuild
Bamboo
Jenkins
TeamCity
CI-Eye

关于这几个持续集成工具的详细介绍，可以参考这篇文章：
《八大持续集成工具》http://openskill.cn/article/218。

我在三年半的工作生涯中，接触过的两个持续集成工具分别是Bamboo和Jenkins，因此对这两个持续集成工具比较亲切，但是真正了解得很少。一时，这个工具一般都是自动运行，很少需要人的参与，除非前一天构建失败后，需要登录工具去下载失败的log；二来，这个也主要是项目经理和测试组会经常访问的工具，开发人员一般只负责提交代码到SVN即可。

但是，不管是哪一个持续集成工具，它本质上只不过是一个定时器，时间一到，做你脚本里让它去做的事。如果，想要扩展持续集成的作用，则需要将这个工具与其他的工具结合，才能显示出持续集成的本色。

比如，如果想增加测试工具，选择JUnit, JWebUnit, Selenium等；
想检查代码标准，需要用checkstyle, sonarqube等代码规范检查工具；
想了解测试覆盖率，可以用Istanbul, JCoverage等工具；
想打包生成二进制文件，要用Ant, Make之类的工具。