持续集成

持续集成——敏捷开发之最佳实践

摘要：可回归性和敏捷性相辅相成，可回归性是基础，没有可回归性就没有敏捷性；敏捷性是提升可回归能力的重要法宝。为了使得团队和软件研发项目的可回归性、敏捷性达到

最优，必须实施持续集成。借助于持续集成（Continuous Integration，CI），重复任务的执行能够变得更加敏捷。
关键词：持续集成；敏捷；

Continuous Integration - Agile development best practices
Abstract: Return and agility can be complementary, may return to nature is the basis of no return no agility; agility is important to enhance the abilit  y

to return to magic. In order to make the team and the software can return to R & D projects, agility optimal, we must implement continuous integration. With

continuous integration (Continuous Integration, CI), perform repetitive tasks can become more agile
Key words: Continuous Integration; Agile.

1 引言
持续集成这个术语来自XP（极限编程）的一个最佳实践，随着XP社区近几年的壮大，XP的很多实践也得到推广，持续集成就是其中之一,然而持续集成也不是一个新的概念，之前的

日构建也提供类似的功能，它们的主要区别体现在构建的频率上。
本文将重点介绍敏捷开发和持续集成，阐述为什么要在项目中提倡敏捷和使用持续集成，持续集成的关键点在什么地方，它是怎么具体实践的。
2 敏捷开发
敏捷开发于2001年《敏捷宣言》中诞生，宣言的内容为：
 个体和互动 高于 过程和文档
 工作的软件 高于 详尽的文档
 客户合作 高于 合同谈判
 响应变化 高于 遵循变化
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件的开发是一个迭代增量的过程，实践方法集中于面对面的交流和快速的发布周期，它们的目标是在

短时间内交付一个可工作的软件部分。
2.1 敏捷开发之最佳实践
在软件开发的领域里有各种各样的“最佳实践”，它们经常被人们谈起，但似乎很少有真正得到实现的。在这样的项目中我们通常有遇到这些困难：
1、DBA:需要经常重建数据库，并初始化数据库。
2、开发人员：他们需要手工运行自身写好的单元和集成测试代码。
3、对于架构设计师：他们要经常检查开发人员完成的开发工作是否符合设计初衷。
4、部署工程师：完成目标应用的打包和发布工作往往是他们的重要工作内容之一。
5、功能及负载测试工程：他们借助于penQA Selenium、pache Jakarta JMeter等自动化工具完成功能及负载测试工作。
最头疼的问题是如何快速地将上述各种重复工作的执行结果反馈到项目涉及人员手里。
可以看出上面的这些难题大多数属于可回归性工作，那我们为什么不让电脑去做这些呢？
敏捷开发强调的是在保证目标任务完成质量的前提下，以最快的速度交付出工作成果。这实际上体现了效率与质量的并重。借用现有成熟的技术或工具提炼重复任务，这就是一种

敏捷性的体现。
在项目中可回归性和敏捷性是相辅相成的，可回归性是基础，没有可回归性就没有敏捷性；敏捷性是提升可回归能力的重要法宝。为了使得团队和软件研发项目的可回归性、敏捷

性达到最优，必须实施持续集成。借助于持续集成（Continuous Integration，CI），重复任务的执行能够变得更加敏捷。
3持续集成
3.1敏捷开发之持续集成
现如今持续集成可以说是软件开发领域使用最广泛的敏捷开发之一。有了它能让项目原来少而繁杂的集成变的相当容易，还能提高代码质量，监视项目进度，检测已完成功能。从

各个方面维护项目的健康度。
在任何软件开发过程中都有一个重要的部分：得到可靠的软件创建（build）版本。尽管知道创建的重要性，但是我们仍然会在项目中或多或少碰到构建失败的情况。在持续集成中

我们将通过完全自动化的、可重复的创建过程，其中包括每天运行多次的自动化测试，来对项目每天进行系统集成，及时的反应集成中的问题，进而维持软件一直在可工作的状态

。

3.2持续集成的好处
引入的CI服务器将持续完成各种重复任务，比如持续数据库集成、持续单元及集成测试、持续评审、持续部署、持续功能及负载测试、持续反馈
一旦项目实施持续集成后，被研发产品的集成工作便经常发生，而且随时都能够构建出最新的可供部署和测试的产出物（或JAR或WAR或EAR包，甚至是单独的可执行文件）。由于上

述各项工作都将持续发生，各种潜在的问题将被持续地暴露和跟进，进而能够逐渐改善软件产品的质量，并有效地降低项目风险
2.2 一次成功的构建应该是什么样的?
什么是成功的构建？成功的构建必须满足下面这几个要求：
1、所有最新的源代码都被配置管理系统验证合格
2、所有文件都通过编译
3、系统开始运行，针对系统的测试套件全部运行
4、如果所有的步骤都没有错误、没有人为干涉，所有的测试也都通过了，这就是说我们就得到了一个成功的创建。
必须注意的是绝大多数人都认为“编译成功=创建”。应该说创建还包括启动应用程序、针对应用程序运行简单测试。运行更详尽的测试集可以大大提高持续集成的价值，所以应该

首选更详尽的测试。
2.3 自动化脚本
构建流程图：

图1
我们可以将这个流程分成6个部分：
1、持续数据库集成：定期基于SCM中的最新SQL脚本（包括DDL和DML语句）完成数据库的重建和数据初始化工作。比如，借助Apache Ant内置的sql的支持
2、持续单元及集成测试：从SCM中检出最新的Java代码，并自动执行其中的单元及集成测试代码，最后给出相应的测试结果。如有需要，还可以自动给出代码覆盖度分析结果，
比如Clover、Cobertura、EclEmma、TPTP、Coverlipse
3、持续评审：基于SCM中的最新代码进行各方面的自动评审工作，比如代码风格和规范评审、架构设计评审、详细设计（JavaDoc）评审。比如，基于Checkstyle、PMD、
JDepend、JavaNCSS、Fortify、javadoc.exe等自动进行
4、持续部署：将构建工作的产出物持续部署到目标测试环境，比如借助Apache Ant、SmartFrog。
5、持续功能及负载测试：比如，对刚部署到测试环境的目标应用进行自动化功能测试及负载测试。借助Selenium RC、Apache JMeter等技术可以自动完成这类工作
6、持续反馈：通过各种渠道将上述各种持续性工作的具体结果分发出去。比如，邮件服务器、RSS、FTP服务器、HTTP服务器、Socket、等等

2.4 自动化测试
必须再次强调自动化测试的部分，集成中只让程序通过编译是远远不够的。因为即使成功通过了编译，程序中仍然可能留下很多错误。为了帮助跟踪这些错误，应该非常强调自动

化测试——这也是XP提倡的另一个实践。
XP将测试分为两类：单元测试和容纳测试（功能测试）。单元测试是由开发者自己编写的，通常只测试一个类或一小组类。容纳测试通常是由客户或外部的测试组在开发者的帮助

下编写的，对整个系统进行端到端的测试。这两种测试我们都会用到，并且尽量提高测试的自动化程度。
有一条基本的原则：在编写代码的同时，开发者也应该编写相应的测试。完成任务之后，他们不但要checkin代码，而且还要checkin这些代码的测试。这也跟XP的“测试第一”的

编程风格很相似：在编写完相应的测试、并看到测试失败之前，不应该编写任何代码。所以，如果想给系统添加新特性，首先应该编写一个测试。只有当新的特性已经实现了以后

，这个测试才可能通过。然后，你的工作就是让这个测试能够通过。
在编写软件的过程中，在每一次的编译之后，开发者通常都会运行一部分单元测试。这实际上提高了开发者的工作效率，因为这些单元测试可以帮助你发现代码中的逻辑错误。然

后，你就没必要去调试查错，只需要注意最后一次运行测试之后修改的代码就行了。这个修改的范围应该很小，所以寻找bug也就容易多了。
3 总结
一个制度严密的自动化创建过程对于项目的控制是很重要的。在集成过程中关键是要让所有的事情都完全自动化，并且要经常进行集成，这样才能尽快发现错误。然后，程序员可

以随时修改需要修改的东西，因为他们知道：如果他们做的修改引起了集成错误，那也是很容易发现和修补的。

参考文献
[01] Robert C.Marth，《敏捷软件开发：原则、模式与实践》，清华大学出版社，2003年9月
[02] 罗时飞，《敏捷持续集成：高校研发之道》，电子工业出版社，2008年6月
[03] 杜瓦尔，《持续集成软件质量改进和风险降低之道》，机械工业出版社，2008年1月
[04] David Farley，《持续交付：发布可靠软件的系统方法》，人民邮电出版社，2011年10月