引子

　　记得刚加入趋势开始开发工作的时候曾被告知，趋势有一套auto build的系统，会每天夜里自动把当天check in的代码进行构建，生成QA可测试的build。每个RD都得小心提交code，因为项目结束的时候会看auto build的失败率。可是构建失败总是在所难免，尤其是每次要提交candidate build给QA做full cycle测试时，总是在最不该发生的时候发生最不可能发生的事情，至今我还记得为了按时出一个合格的candidate build，熬夜等build的经历。

　　Martin Fowler大师在2000的一篇文章中，最早提出了Continuous Integration（CI，持续集成）的概念。此后，CI作为软件开发的最佳实践已经被很多的团队所采纳。从今年年初开始，我们开始了一个项目新版本的开发，由于项目具有的不确定性，以及开发周期不是特别紧，我们团队决定在开发流程和质量控制上尝试着做些改变，在趋势，Change是深植入企业文化的一个特质，这里的Change不单单只包括老板和管理团队自上而下的Change，还包括开发团队和个体，只要你有想法，你都可以尝试着去改变。（之前看过一篇《测试驱动开发的半年实战心得》，也来自我们团队另一个成员在该项目中对于TDD的新尝试）

　　简介

　　正如Martin Fowler所说，CI要求开发团队能够频繁地集成开发和测试工作，以便尽早发现问题，减少项目风险。这里的关键是“频繁”，如果CI也只能每天在夜里做一次集成，那和原来的daily build又有什么大的差异呢？

　　CI其实是由一系列的最佳实践所构成：

　　·        源代码的版本控制和管理

　　·        自动化构建

　　·        自动化测试

　　·        代码审查

　　·        自动发行和部署

　　·        持续反馈

　　·        等等

　　通过持续地对代码和测试进行尽早频繁地集成以尽早发现问题，而为了能够频繁地集成，又对自动化提出了很高的要求，毕竟只有机器自动完成才有可能在一天里集成若干次（如果需要专人来负责这件事情，第一老板不会同意，成本太高了，其二人总是难免有出错的时候，结果可能集成本身花费的时间超出了开发的时间，这就得不偿失了，其三，由于人的适应性和“包容性”，也会让规范很难形成并遵守）

　　实践

　　既然CI包含了这么多实践，我们决定采用渐进的方式来开展，罗马不是一日建成的，在这个项目中，我们依次展开了：自动构建、持续反馈、自动测试和自动部署等实践，其中没有包含代码审查的部分。由于趋势已经有一套成熟的版本控制和构建系统（采用Perforce进行版本控制），这使得我们的自动构建变得相对容易，所以我们以自动构建为基础，展开如下的一些实践：

　　- 增量编译（Incremental Build）：CI系统会定期监视Perforce（每5分钟），一旦发现有新的代码check in，就会触发增量编译，取出最新check in的代码进行编译，完成后给check in代码的人发出邮件通知（成功或者失败），如果编译失败，对应的owner必须优先解决，否则CI会每隔一段时间（5分钟）再次尝试，一直到成功为止。由于增量编译很快，Developer一般在check in代码几分钟后就能收到通知，如果失败可以立刻予以修复。

　　- 单元测试（Unit Test）：CI系统在增量编译通过的基础上，会通过我们的测试框架自动调用每个模块的单元测试，同样也会发出测试报告，如果测试失败也要优先解决。这里由于我们项目目前还没有太多单元测试的case，因此我们第一步先把测试框架搭建好，然后对项目中新的代码推行单元测试，而对于legacy代码，则视情况补充case。

　　- 自动发行和部署（Full Build & Deployment）：CI系统会定期（3小时）执行Full编译和打包，最后生成可安装的发行包，然后通过虚拟机自动部署并安装到远端的虚拟机上。由于完整的编译和打包操作很费时间（半小时以上），因此没有必要对每次check in代码都执行。通过自动发行和部署，CI系统可以尽早发现打包和安装过程中的问题，并尽早予以解决。

　　- 组件测试（Component Test）：相对于单元测试，组件测试更关注于各个组件间接口部分的测试，此外，单元测试一般要求没有外部环境的依赖，比如数据库，DNS等，如果必须有这些依赖必须通过mock的方式解决，而组件测试则运行在真实的产品环境里，因此数据库、DNS等外部依赖都可以作为测试的输入输出。这部分和单元测试一样，由于没有现有的基础，因此我们优先搭建好测试框架，然后对新代码进行测试，对于legacy代码则视情况补充。

　　- 自动化功能测试（Feature Test）：这是我们现有做的做多一部分，趋势QA会对很多的功能测试case进行自动化，自然在CI系统中也会把这部分纳入。我们采用每天一次的周期来运行这部分测试。

　　- 覆盖率（Coverage）：既然在CI里包含了这么多的测试的内容，那如何衡量测试的效果和标准？覆盖率便是一个可行的量化标准。因此我们在CI中也加入了覆盖率的统计，通过代码覆盖工具，我们可以得到测试运行的代码行覆盖率和条件覆盖率。这些结果也会被汇总到CI报表里，这样我们随时看到测试的效果和历史数据的改进。

　　- 反馈及可视化：在CI里还有一个很重要的部分就是反馈和可视化。有效的反馈机制可以让产品的问题尽早暴露并通知到合适的人。而同时通过CI中的可视化可以展示很多信息，比如测试用例的数量，覆盖率，成功和失败构建的次数，代码check in次数等等。通过可视化，可以达到：1、让团队成员了解项目现状，增加成就感（想想如果你每天可以随时在报表里看到由于自己的工作而增加的部分，是不是很酷？）2、让manager随时了解团队现状，减少项目风险。