持续集成CI（Continuous integration）

      持续集成作为敏捷开发的基石，被很多软件开发项目组所采用。

     持续集成定义：

     *什么是持续集成？* 持续集成一种软件开发实践。通过它，开发团队的成员频繁的整合他们之间的工作。它不是简单的组装软件而是软件开发过程的核心实践，通过时时运行测试，保证软件现有的功能不被破坏，自动分析现有代码的状态(有无重复逻辑，代码的复杂度，PC-lint，圈复杂度，UT覆盖率等)并发布相关的报告。这些功能根据开发团队所采用的持续集成服务器不同而 有所不同

   大师Martin Fowler对持续集成是这样定义的:持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

    持续集成的价值？ 

－ 减小风险 

   持续集成过程通常在开发人员提交代码后开始，服务器自动更新代码，编译，运行单元测试，功能测试，集成测试，进行部署。这个持续集成的过程可以帮助开发人 
员快速发现并解决问题(编译失败，测试失败等)。与开发人员的机器相比，持续集成服务器运行在相对稳定、干净的环境中(减小跟踪调试的难度)，持续集成过 
程的失败通常意味着最近一次更新破坏了软件现有功能或引入了新的缺陷。在持续集成过程结束后，除了构建结果(War, Jar等)，通常会生成代码分析报告(测试覆盖率等)，帮助项目管理人员更好的了解并改善项目。 

－ 减少手动过程 
   在开发过程中大量的采取手动过程不仅降低了团队的生产率，更严重的是它将许多不确定的因素引入到产品的构建过程中，这使得发现以及解决问题变得异常困难。 
QA在测试环境中所发现的问题可能是由于部署人员忘记拷贝某个配置文件，也可能是由于没有删除某些临时文件引起的。通过使用持续集成工具将构建过程自动 
化，便于分析并找出问题，大大提高了团队的效率。 

－ 生成构建结果 
    从客户和用户的角度看，一个可以部署或者执行的构建产物才是最重要的。在使用持续集成工具的环境中，开发人员对源文件进行修改，提交，持续集成服务器会将 
这部分修改与其他的代码进行整合，测试，并重新生成最终产品(War, Jar, exe等)。如果在其中任何一个环节出现了问题，相关人员可以很快的得到反馈。在没有使用持续集成工具的环境中，大量的问题只有在产品发布前进行最终集成 
的时候才会出现，开发团队往往在发布前承受着巨大的压力，并导致产品延迟发布或者在进行hot fix的过程中引入更多、更严重的缺陷。 

－ 安全感 

软件开发过程最终表现为人与人之间各种形式的合作。安全感与信心是合作最基础也是最重要的部分。通过使用持续集成工具，开发人员可以了解到新的代码是否引 
入了缺陷，管理人员可以通过使用各种形式的报告对项目进行评估。不断发布的构建结果，使测试人员得以自始至终的参与到整个开发过程中，而不是在软件开发的 
最后阶段才加入团队。 

如何进行持续集成？ 在进行持续集成实践前，应当正确的选择并配置持续集成服务器。其中比较成熟的持续集成服务器包括： 
CruiseControl <http://cruisecontrol.sourceforge.net/>, 
Anthill<http://www.anthillpro.com/html/products/anthillos/default.html>, 
Bamboo <http://www.atlassian.com/software/bamboo/>, 
TeamCity<http://www.jetbrains.com/teamcity/>, 
Continuum <http://maven.apache.org/continuum/> 
等。CruiseControl<http://cruisecontrol.sourceforge.net/> 
作为开源产品，以其对于各种SCM以及构建工具的广泛支持而被许多开发团队所接受。 

在一个典型的持续集成过程中： 
*－ 开发者每次将代码提交到SVN之前，必须运行本地测试： *尽量保证不会破坏持续集成服务器的构建过程。 

*－ 开发者每天进行多次提交*：小步前进会大大减少服务器构建失败的概率，并且使得修复失败构建的时间大大缩短。 

*－ 持续集成在一台服务器上不断运行*：保证在稳定的环境中进行测试。 

*－ 所有的测试必须全部通过*：保证软件现有的功能不被破坏并且没有引入新的缺陷 
* 
－ 生成构建结果(War, Jar，exe等) ：* 用以开展下一步的工作，譬如QA的探索测试等。 

*－ 生成报表 ：*帮助管理人员评估开发状态。 

*－ 修复失败的构建 *： 失败的构建意味着软件现有的功能已经被破坏或者有新的缺陷被引入，修复的速度越慢使修复难度越高，并带来更大的损失。 

持续集成坏味道：

 － 持续编译 
   ［现象］某些团队仅仅使用持续集成服务进行编译并生成最终的构建结果。 
   ［影响］持续集成无法给开发人员，管理人员带来有价值的快速反馈。 
   ［原因］开发团队可能缺乏编写易于测试的代码的能力，或者不了解现代软件开发中测试的流程和作用 
   ［解决方案］测试优先，单元测试，功能测试，验收测试 

－ 构建长时间失败 
   ［现象］ 没有开发者愿意修复失败的构建，持续集成工具上的构建已经持续失败很长时间。 
   ［影响］ 开发者忽视持续集成服务器发布的结果，修复构建的成本和难度升高，开发团队，管理团队无法得到快速反馈，丧失安全感 
     [原因]   长时间不进行代码更新并一次提交太多代码，构建时间太长导致开发者缺乏耐心运行本地构建、任务过于复杂 
     [解决方案] 简单设计，小步前进，缩短构建时间 

－ 过多失败构建 
   ［现象］持续集成服务器上有很多失败的构建、开发者常常在持续集成服务器上强制运行构建 
   ［影响］团队其它成员无法提交代码，开发效率下降。 
     [原因] 
通常这是项目中存在随机失败测试的信号，譬如，某些测试存在顺序依赖，时间敏感或者没有在测试结束时正确回收资源。这样，虽然开发者本地构建通过，却无法 
保证在持续集成服务器上成功构建，开发者会不断的尝试在服务器端重新运行构建试图得到一个成功的构建 
   ［解决方案］ 简单设计，编写正确的单元测试 

－ 构建时间过长 
   ［现象］本地构建时间超过10分钟 
   ［影响］生产率严重下降 
     [原因]  可能是由于重复测试引起，由于测试之间没有很好的隔离，导致同一逻辑在对不同对象进行测试时被重复测试、或者是软件规模大，测试多引起 
     [解决方案] 分布式构建 

－ 构建结果不醒目 
   ［现象］ 没有开发者意识到持续集成服务器上的构建已经失败了 
   ［影响］ 构建长时间失败，修复难度变大 
     [原因]  没有将构建结果明显的发布出来 
     [解决方案] 安装构建指示灯，或者在构建失败的时候播放音乐。 

拥抱持续集成：     为了享受持续集成带来的诸多好处，开发者需要做到： 
－ 小步前进，频繁提交 
－ 不要提交本地测试失败的代码 
－ 编写可以自动进行的测试 
－ 编写可以快速运行的测试 
－ 如果构建失败，第一时间进行修复 
－ 如果构建失败，拒绝更新代码 

不进行持续集成的理由： *－ 硬件花费* 
对于大多数的团队来说，持续集成服务器不需要运行在一台性能异常强大的机器上，使用一台开发机器加一个指示灯(在构建失败时变红)已经足够了，硬件的成本在不断 的下降，和开发团队不断修复回归测试发现的缺陷，编译失败，延迟发布比起来，这个投资应该是非常划算的。 

*－ 管理开销* ...