持续集成调研报告（1）

持续集成（CI）调研报告

一．       持续集成的价值

1.      持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量。

2.      持续集成保障了每个时间点上团队成员提交的代码是能成功集成的。换言之，任何时间点都能第一时间发现软件的集成问题，使任意时间发布可部署的软件成为了可能。

3.      持续集成还能利于软件本身的发展趋势，这点在需求不明确或是频繁性变更的情景中尤其重要，持续集成的质量能帮助团队进行有效决策，同时建立团队对开发产品的信心。

4.      在一天中进行多次集成，可以减少项目的风险，这样做有利于检查缺陷，了解软件的健康状况，减少假定。

5.      增强项目的可见性。

6.      使开发团队建立起更强大的产品信心。

二．       工作机制与工作过程

2.1  工作机制图表

2.2  工作步骤如下

1.      开发者向版本控制库提交代码，与此同时，集成构建计算机上的CI服务器正在轮询检查版本控制库中的变更（可以设置为实时轮询或定时监控）。

2.      在提交发生之后，CI服务器检测到版本控制库中发生了变更，所以CI服务器会从库中取得最新的代码副本，执行构建的脚本，该脚本将对软件进行集成。包括一系列的编译，数据库集成，测试，审查，打包，部署。

3.      CI服务器向项目组成员提供构建结果反馈信息（EMAIL，SMS等）

4.      CI服务器继续轮询版本控制库中的变更。

2.3  子过程描述

1.      源代码编译：持续的源代码编译是CI系统最基本、最常见的特征之一。

2.      数据库集成：在CI系统的构建过程中进行持续的数据库集成。当项目成员修改了数据库脚本并提交到SVN中时，集成源代码的构建脚本将重建数据库和数据，作为集成构建的一部分。

3.      测试：可以通过CI进行自动化的持续的测试。这些测试分类包括：单元测试，组件测试，系统测试，负载/性能测试，安全测试和其他测试。

4.      审查：自动化的代码审查（例如静态和动态分析），可以通过强制遵守规则来增加软件的品质。

5.      部署：CI可以将文件自动部署或安装到相应的环境中去。

6.      文档与反馈：定期生成文档，并及时向开发者和项目风险承担者提供反馈信息。

三．       持续集成遵循的原则

1.      经常提交代码：每天至少向版本控制库提交一次代码。

2.      不要提交无法构建的代码：不要提交无法编译或不能通过测试的代码。

3.      立即修复无法集成的构建：修复构建过程中的错误是优先级最高的工作。

4.      编写自动化的开发者测试：利用自动化的开发者测试来验证软件。

5.      必须通过所有的测试与审查。

6.      执行私有构建：为了防止集成失败，先从版本控制库中取出其他开发者提交的最新变更，然后在本地执行完整的集成构建，这被称为私有系统的构建。

7.      避免签出无法构建的代码：如果集成构建失败，等待新的变更，帮助开发者修复无法集成的构建，然后再取出最新的代码。

四．       搭建CI环境说明

4.1 CI环境基本结构图

4.2  所需环境与工具

l  操作系统

l  JDK

l  Web服务器版本管理工具

l  构建工具

l  CI服务器

l  构建管理仓库

环境的配置与搭建方式会进一步讨论与实践，在此不赘述。

初步决定具体采用的工具为：

Linux + JDK +Tomcat + Ant + Maven + Nexus + SVN + Jenkins。

 

五．       调研结果与下一步计划

已经初步对持续集成的概念，工作方式有了了解，如何利用持续集成提高软件开发的质量与效率是需要我们验证的，对于自动构建，持续的数据库集成，持续测试，持续审查，持续部署，持续反馈的具体实现方式也需进一步研究与实践，由测试和质量管控的角度来衡量，测试与审查是需要主要关注的部分。会在这一方面多加关注。

下一步会先搭建起CI的环境。

针对本项目利用CI想达到四个目的：

1.      集成组件（从版本控制库取得最新的变更并进行编译）

2.      完成自动化测试，执行所有单元测试集，并自动化执行回归测试，包括功能测试、集成测试、负载测试和性能测试。

3.      执行其他自动化的过程：重建数据库，审查和部署。

4.      利用CI降低本项目风险，并做到辅助项目管理的工作。

部分内容参考《持续集成软件质量改进和风险降低之道》《持续集成在软件项目管理中的作用》《基于jenkins的持续集成使用指南》等书籍或文章。