什么是 CI 持续集成

现在做测试，经常听到一个概念 持续集成 CI Continuous Integration。

那什么是持续集成呢？相信大家看了不少文章之后依然是一脸懵逼。

这里呢，用我自己的理解谈一下，不正确的地方还请指正。

要说持续集成，首先要明白什么是集成。很多测试同学说到集成，就想到集成测试。

这里的集成主要是指代码的集成：

举例来说，比如当前迭代，开发时间为两周。项目开始后，开发人员会从代码管理工具（SVN 或 GIT）的主干代码上复制一份代码到自己本地电脑。然后在自己的本地电脑上进行开发，假设这个项目有三个开发人员，分别是 jim（狗蛋）、lily（翠花）、tom（大锤）。

好，现在三个开发分别在自己电脑上开发。开发任务完成后，一次性提交自己本地代码到代码管理工具的主干代码上。

这个过程就叫集成，也就是代码集成，将自己本地的代码集成到主干代码。此时发生了所谓的集成地狱。三位开发有可能会改到同一个代码文件、同一个方法，这样就会出现代码冲突。为了处理集成过程中的冲突，会花费非常多的时间、精力和成本，并且提高了发布风险。

为了降低这种风险和成本，于是持续集成就被提出了。强调的是不再一次性把代码集成到主干，而是高频率的持续集成。一天集成1次，甚至多次。同时在集成过程中，进行自动化测试，保证主干代码一直可用。

为保证主干代码可用，开发每次代码集成后都需要进行 BVTBuild Verification Test测试，也就是类似冒烟测试的过程，比冒烟更简单一些，主要保证系统可用。这种测试由于测试频率高，因此对自动化测试的需求非常大。

那么现在主流的持续集成工具，比如 Jenkins 做些什么事情呢？

先来说一下没有 Jenkins 的时候，我们怎么去更新测试环境的。

1. 首先从 SVN 上获取最新代码；
2. 在本地进行编译
3. 构建一个发布包，通过 FTP 上传到测试环境服务器
4. 将发布包中内容更新到相应的服务
5. 重启相关服务，以使更新生效
6. 如果部署了负载均衡，则在其他服务器上重复 4， 5

每次构建和更新测试环境都是很繁琐的任务，而且极易出现错误。那么 Jenkins 能干什么呢？

能让这一系列事情全部自动化：

1. 根据规则轮询代码管理工具，获取最新代码（也可以手动或设置其他规则）
2. 基于不同的语言进行构建（需要自行配置）
3. 通过 FTP 把构建后的内容自动上传到对应的服务器
4. 使用插件或者脚本，将发布包内容更新到各个环境
5. 通过命令行调用自动化测试脚本，搭配代码覆盖率工具执行自动化测试
6. 展示自动化测试报告，并邮件通知构建情况

也就是让集成过程中繁琐的事情都自动化了，那么进行持续集成也不会因为集成频率过高带来的环境部署和频繁测试而导致开发效率降低。