这篇文章大体上是从COMPASS整个项目组的角度介绍CI实践的一些经验和成果，但有些部分偏重于从QA的视角看CI给我们的工作带来的变化。

一、为什么引入CI

客户需求的随时而变要求我们更快做出响应，开发完成并部署上线新的功能模块。这样的快速上线需要一种机制来保证每次所发布版本的可用性和质量。CI就是这样一种能为提交的每次代码修改提供可用性和质量保证的机制。

二、CI是什么

我理解CI的核心涉及两方面：项目数据共享和构建自动化。

所有人共享一个有版本控制的代码库，或者更准确地说是资料库，因为这里面既包括直接提供客户价值的业务代码，也包括用来验证业务代码是否符合预期设计目标的测试代码，除此之外，同时还包括项目文档、数据库变更脚本、部署脚本等，总之，目标就是将所有与项目相关的东西都纳入版本控制系统中，并且使之为项目组内所有的人共享。

因为CI涉及频繁的构建，我们需要通将构建过程自动化来减少构建带来的成本。通过一系列经过测试的构建脚本，实现每次代码提交都触发一次自动的构建，或者我们也可以选择在适当的时机手动触发一次构建。总之，要提供一套能够方便地实施构建、发布的基础设施，可以是一键触发的，甚至是由代码提交自动触发的。

三、COMPASS项目的CI实施情况及成果介绍

COMPASS项目从4月中旬开始实施CI，到现在为止大致完成了以下几项CI改造：

1. 搭建基于hudson的CI环境

搭建hudson基础环境。

我们使用一台Linux主机作为hudson运行的平台，使用Tomcat作为hudson运行的容器，安装了静态代码检查、build pipeline、覆盖率分析、副本归档、状态监视、svn版本控制、maven项目管理等插件。

建立构建任务并按视图分类管理。

按视图对各种构建任务进行分类管理。这些视图包括：当前开发模块所依赖的基础库模块的构建任务、当前开发模块的构建任务、部署测试环境的构建任务、产品发布的构建任务。这样的分类视图使各个构件任务的意义更清晰，更加便于管理。

当前基础库模块的构建任务和当前开发模块的构建任务都选择maven2类型的任务，通过使用模块的POM文件可以大大减少所需的构建配置。并且设置构建触发机制为每次代码提交都触发一次构建。这样的触发频率能及时反映出有问题的代码，确保集成到代码库的代码总保持是可工作的版本。另外，还通过pipeline机制建立依赖库模块与当前开发模块之间的上下游关系，即，一旦基础库模块完成一次成功的构建，将自动触发当前开发模块的一次构建，以此来确保基础库更新后当前开发模块仍能正常工作。

部署测试环境的构建任务和产品发布的构建任务都是自由风格的任务。其本质是通过调用经过测试的部署脚本来从从代码库检出特定版本的代码，经编译打包后部署到测试环境和发布产品库。这两类任务采用手动触发的方式，即，只在需要时手动触发一次构建。

2. 打通快速提测和快速上线的流程

通过编写部署测试环境和发布产品的相关脚本，并将其以构建任务的形式集成到hudson CI环境，极大简化了提测和上线流程，保证了快速提测和快速上线的实现。目前，完成一次提测只需不到2分钟时间，完成一次上线也不超过15分钟。这成为我们能够快速迭代、快速交付产品的重要基础。

3. 确定以半周为单位的持续发布模式

我们的项目已一周为一个迭代，每个迭代安排两次上线。这样的频繁迭代最大地满足了对用户需求的快速响应。一般从用户反馈一个需求到这个需求开发完成交付给用户，之间间隔的时间不会超过两周。这极大地改善了用户体验。

到目前为止，经过六个迭代，我们已经持续向用户发布了12个版本。项目基本保持着匀速、高效的生产力。

4. 测试多样化和自动化

测试已成为项目的共识。

目前单测已变为RD日常开发工作的一部分，项目Core模块的单元测试已经覆盖了80%的有效代码；在RD的配合下，项目也越来越多的关注于Service模块的数据库相关的测试。

集成测试。COMPASS系统二期启动后，做了很多的代码重构，而诸多的重构仅仅依靠单测已不能满足项目对质量的要求。所以团队在摸索后，引入了DDT（数据驱动测试）的测试理念，也就是由QA设计测试架构和测试数据，由RD负责代码实施，这样能够最大限度的发挥RD与QA的长处。以项目最重要的模块——任务生命周期管理模块为例，在QA设计了测试架构后，RD仅用3天时间就将架构实现，与此同时，QA为任务生命周期管理模块设计了60几个测试用例场景，几乎覆盖了90%的逻辑，这最大限度的保障了任务生命周期管理模块的正确性以及未来重构的回归需求。

除了代码级别的单元测试，和数据驱动的集成测试，项目采用Selenium进行功能测试，以保证QA以最接近真实用户体验的方式测试系统，经过QA三周的努力，目前Selenium的测试Case已经达到40多个，覆盖了任务信息维护、登录权限控制等系统主要功能模块，在快速交付的后期，为QA节省了很多的回归时间，是快速提测和快速上线的重要保证。

更重要的是，目前我们的单测、集成测试和功能测试已经集成到Hudson环境，形成了开发、提测和上线的Pipeline。

四、目前存在的问题及后续改进措施

1. 测试用例分级和分阶段运行的进一步细化

目前我们的测试体系已经比较完善，包括了单元测试、集成测试和功能测试等多种形式，能从各个层面保证产品的质量。

但随着系统功能的丰富，测试用例的数量也会继续增长，每次运行测试需要的时间也越来越长。这就需要我们对测试用例进行分级，在不同阶段只选择运行相应级别的case。在尽可能保证产品质量的前提下，保持持续集成的快速进行。

2. 完善性能测试

随着系统推广使用，大量并发操作和大数据量成为对系统的一大考验。下一步，我们将规划更完善的性能测试，找出系统瓶颈进行优化，确定系统性能极限，对系统的承载能力做到心中有数。

而性能测试一般需要较长的测试时间，并且占用大量系统资源。这就要求我们在持续集成环境中合理规划性能测试的频度和范围。做到既满足性能测试需求，又不影响持续集成的快速行进流程。

(作者：zhangguiying)