持续集成介绍汇总

转自：http://blog.csdn.net/tony1130/article/details/1876819/

一、什么是持续集成（Continuous Integration）？

这个名词已经在软件开发领域持续了N年，一个比较简单的定义如下：
持续集成（CI）是一种实践，可以让团队在持续的基础 上收到反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。通俗一点儿说，就是指对于开发人员的每一次代码提交，都自动地把Repository中所有代码Check out到一个空目录，并且自动运行所有Test Case。如果成功则接受这次提交，否则告诉所有人，这是一个失败的Revision。更具体的解释可以参考Martin fowler的Continuous Integration  。

二、持续集成的价值与成本

有句时髦的话，叫做“存在即为合理”。既然持续集成已经存在了这么长的时间，而且没有消失的迹象，那就是有价值的东西。那么它的价值何在？有人概括如下：(1) 减小风险；(2) 减少手动过程；(3) 生成构建结果；(4) 安全感。
而持续集成的成本在于对持续集成代码的维护成本和集成的时间成本。因为随着项目进行，软硬件环境会越来越复杂，成品代码也会不断膨胀。此时，需要团队而修改或增加原有的测试代码，以适应这些变化，同时，每次集成所需时间也会变长，这就是持续集成的成本。某个blog中提道：“这种集成是如此的频繁，多少次的代码Commit就有多少次持续集成。前提是集成的成本很低，或者说是完全自动化的。”

三、持续集成应该自动化什么呢？

我们要以尽可能少的成本来获得尽可能多的价值。这就要考虑哪些自动化是必要的啦。Jez Humble提到至少有六点要做到自动化，它们分别是(1)自动化的运行测试；(2) 自动产生可部署的二进制成品；(3) 自动将成品自动部署到近似生产环境；(4) 自动为CodeBase打上标签；(5) 自动运行回归测试；(6)自动生成度量报告。

四、持续集成服务器的选择

在进行持续集成实践前，应当正确的选择并配置持续集成服务器。比较成熟的持续集成服务器包括：CruiseControl, Anthill, Bamboo, TeamCity, Continuum 等。CruiseControl作为开源产品，以其对于各种SCM以及构建工具的广泛支持而被许多开发团队所接受。而开发自动化专家 Duvall 采用一致的评估标准和很多说明性示例，介绍了一些开源 CI 服务器，包括 Continuum、CruiseControl 和 Luntbuild。并指出“要根据 自己的 具体技术和政策需求对工具进行分析”。并用以下五个指标来评估CI工具，它们分别是：(1)  特性；(2)  可靠性；(3)  寿命；(4) 目标环境；(5) 易用性。结果如下表：


而CruiseControl是我唯一真正用过的持续集成工具，它现在灵活而又强大功能也让我瞠目，而且配置与管理也较两年前容易得多啦。为什么说它强大呢？因为你只要想得到的问题，它也都会有所考虑。朋友的Blog上有些CruiseControl的最佳实践足以证明这一点，只要你肯去实践。

五、只有持续集成服务器是远远不够的

正如Jez Humble所说，CruiseControl和其它的CI工具本质上只不过是一个定时器，时间一到，做你让它做的事情。所以，必然要有其它工具与其结合，方显持续集成的本色。这些工具又是什么呢？想测试的话，你就要用一些测试工具，如JUnit，JWebUnit，Selenium等等；想检查代码标准的话，你就要用checkstyle等代码规范检查工具；想要了解测试覆盖率的话，你可能就要用到JCoverage啦。当然，想得到二进制文件，就要用到Ant，Make之类的工具啦。

六、最重要的事：实践与反思

也许这些东西大家都知道，而且有些人可能已经实践过啦。无论这些实践的结果是怎样的，一定不要忘记总结和反思。如果这些实践成功了，不要把它归功于这个工具，而是要总结一下为什么会成功，如果你愿意的话，还可以和大家分享一下。如果这些实践失败了，也不要把它归功于这个工具，而是要反思一下，是否正确地使用了这个工具，团队成员是否都喜欢这个工具，为什么？

 

------------------------------------------------------------------------------------------------------------------------------

 

转自：http://blog.csdn.net/hunterno4/article/details/22525667

一本好书使您改变。它将改变您的思想，您看待问题的角度和方式，最终，它将改改您的行为。然而，所有具有重要意义的改变都不会是在一夜之间发生的，如果您相信这种变革必会发生，不妨朝着这个方向去努力，经常改变，每次改变一点点。

                                                                                                                                           ——《持续集成：软件质量改进和风险降低之道》

 

CI的价值：

减少风险：缺陷的检测与修复变得更快；通过持续测试与持续审查，软件的健康程度可以测量；可以减少不实的假定。

减少重复过程

在任何时间、任何地点生成可部署的软件

增强项目的可见性

对开发团队的软件产品建立起更强大的产品信心

 

CI的阻碍：

增加了维护开销

团队变化太大

失败的构建太多

额外的软硬件成本

 

团队中7项好的CI实践：

经常提交代码

不要提交无法构建的代码

立即修复无法集成的构建

编写自动化的开发者测试

必须通过所有的测试和审查

执行私有构建

避免签出无法构建的代码

 

持续构建：

每次代码变更均进行自动化构建

将构建过程控制在单行命令下

将构建脚本从IDE中分离，避免与IDE产生耦合

集中放置软件资产

创建一致的目录结构

让构建快速失败

针对所有环境构建

使用专门的集成构建计算机

使用CI服务器

执行快速构建：分离较慢的构建，让集成构建少于10分钟

分阶段构建

 

持续数据库集成：

 

进行数据库自动化集成

使用本地数据库沙盒

将数据库资产放入版本控制库

让开发者能够修改数据库

让开发者成为开发团队的一员

 

持续测试：

 

线性系统的可靠性是每个系统组件的可靠性的乘积，因此特别需要保证底层组件的可靠性

进行自动化单元测试、组件测试、系统测试、功能测试，优先运行测试速度快的测试

为缺陷编写测试

让测试组件可以重复

尽量将测试限制为一个断言

进行代码持续审查，对代码的复杂度、耦合度、重复度等进行持续审查（sonarQube）

 

持续部署：

为每一个构建打上标签

执行测试

创建构建反馈报告

回滚构建的过程能力

 

持续反馈：

不要让您的团队习惯于忽略来自CI构建过程的消息

需要尽快反馈：持续集成的核心是减少缺陷引入、发现和修复之是的时间间隔

 

《持续交付：发布可靠软件的系统方法》

 

软件交付：

每次修改都应该触发反馈流程

必须尽快接收反馈

交互团队必须接收反馈并作出反应

无论部署到什么样的目标环境，都使用相同的部署方法

 

软件交付的原则：

为软件的发布创建一个可重复且可靠的过程

将几乎所有的事情自动化：配置管理自动化、验收测试自动化、数据库升降级自动化，对于硬件可采用虚拟化技术和像puppet这样的工具支撑自动化

将所有的东西都纳入版本控制

提前并频繁地做让你感到痛苦的事

内建质量：一旦发现缺陷，就要马上着手修复，交付团队中的每个人都应该对应用程序的质量负责

Done意味着已发布

交付过程是每个成员的责任

持续改进：团队应定期召开会议，反思过去的一段时间哪边做得好，哪边需要改进。

 

配置管理：

对所有内容进行版本控制，包括应用程序的软件、硬件及基础设施，与项目相关的所有东西都在版本控制库中（但是不推荐将源代码编译后的二进制文件也纳入版本控制中）

频繁提交代码到主干，尽量减少分支

使用意义明显的提交注释

以对待代码的方式来对待你的系统配置，使其受到正常的管理和测试

将特定于测试环境或生产环境的实际配置存放于与源代码分离的单独代码库中

应该严格控制生产环境，进行变更过程管理

高效配置管理策略：将二进制文件与配置信息分离；将所有的配置信息保存在一处。

基础设施应该具有自治特性，且非常容易重新搭建

保证配置管理是声明式且幂等的，即无论基础设施的初始状态是什么样，执行了配置操作后，基础设施或系统所处的状态就一定是你所期望的状态。

如果版本控制系统允许，尽量选择乐观锁（编辑本地工作副本的一个文件时不会阻止其它成员对其进行修改）

康威法则：设计系统的组织不可避免地要产生与其组织的沟通结构一样的设计，即由都坐在一起的小团队开发出来的产品更趋向于紧耦合、非模块化特点

 

持续集成：

 

一、良好的实践：

构建失败之后不要提交新代码

提交前在本地运行所有的提交测试，或者让持续集成服务器完成此事

等提交测试通过后再继续工作

回家之前，构建必须处于成功状态

时刻准备着回滚到前一个版本

回滚之前规定一个修复时间

不要将失败的测试注释掉

为自己导致的问题负责

测试驱动的开发

 

二、推荐的实践：

极限编程开发实践

若违背架构原则，就让构建失败

若测试运行变慢，就让构建失败

若有编译警告或代码风格问题，就让测试失败

 

测试策略：

 

一旦同一个测试重复做过多次手工操作，并确信不会花太多时间来维护时，就要把它自动化

单元测试不应该访问数据库、使用文件系统、与外部系统交互

尽可能频繁地向客户演示功能

建立一些基本的非功能测试，如容量测试、安全性测试。

提交测试应该避免复杂的数据准备，而是用尽量少的测试数据来断言被测试的单元正确地完成了所期望的功能

尽可能使用应用程序的公共API为测试创建正确的初始状态

 

部署流水线：

 

只生成一次二进制包，并将生成的二进制包存入于制品库中，之后的测试、部署均基于此二进制包

对不同环境采用同一种部署方式

对部署进行冒烟测试，这个冒烟测试还应该检查一下应用程序所依赖的服务是否都已启动

向生产环境的副本中部署，即先向类生产环境中部署

每次变更都要立即在流水线中传递

只要有环节失败，就停止整个流水线

为尽快加快反馈过程，增加提交阶段的测试

通常都应该使用增量的方法来实现部署流水线：构建、部署、单元测试、代码审查、验收测试、发布等步骤，部署流水线也应该不断变化，不断改善与重构

做整体优化，不断缩短周期时间，即修改一行代码到最终部署至线上并生效的时间

确保构建时尽量使用相对路径

应该尽量将需要管理的构建数量最少化

 

验收测试：

写应用程序验收条件时必须想着如何使其自动化，并遵循INVEST原则（independentnegotiable valuable estimable small testable）

尽量与GUI解耦

尽量使测试具有原子性，即与测试的执行顺序无关

单个测试范围内，应该避免所有异步情况，也要避免跨越测试边界情况

尽早修复失败的验收测试

当验收测试时间需要很长时，考虑使用虚拟化技术进行多环境并行测试

进行容量测试，但需要先进行度量，找到解决方案之前，必须先找出问题的根源，过早的优化是所有罪恶的根源

对于容量测试环境可以采用缩放后的类生产环境，而不是整个集群

把自动化容量测试作为部署流水线中的一个完成独立的阶段

 

部署与发布：

 

真正执行部署操作的人应该参与部署过程的创建

记录部署活动

不要删除旧文件，而是移动到别的位置

部署是整个团队的责任

服务器应用程序不应该有GUI

为新部署留预热期

快速失败

不要直接对生产环境进行修改