持续集成读后感精选

《持续集成》是一本由(美)Paul M.Duvall;Steve Matyas;An著作，机械工业出版社出版的平装图书，本书定价：35.00元，页数：218，特精心收集的读后感，希望对大家能有帮助。

《持续集成》读后感(一)：CI初级指导书

这是一本关于CI的初级指导书。围绕着CI服务器的几个功能进行了介绍。 CI就是一种自动化组装生产线的理念。对代码库变更的持续轮询，然后执行构建脚本进行集成，其中包括编译、静态代码检查、自动化测试、部署等动作。 它里面提到了初级构建、全面构建等概念，值得我们关注。

《持续集成》读后感(二)：没有营养，不推荐读

没有营养，忘记是从哪里看到推荐来的，很失望。 持续集成，对实践敏捷开发具有重要的意义，持续集成，迭代发布，自动测试，随时有可用的版本，尽早接受用户的反馈，指导研发不偏离客户的实际期望。 但本书不讲这些东西，粗率看了一遍，没有弄明白本书主题到底是什么。 给2星，不推荐读。

《持续集成》读后感(三)：不错的书，对于做项目的人来说值得一读

一本不错的书，可操作性很强，全书列举了CI系统的优缺点，如何去使用CI系统，什么时候使用等等，相当的详细。最后在附录中还列举了很多的参考工具，所以对于想要用CI系统的人来说，有着很大的参考价值，推荐看看。

唯一的遗憾就是，在C++领域没有怎么发现CI系统的介绍，不过Java和DotNet方面的介绍很多，使用这两门语言的有福了。

《持续集成》读后感(四)：一般般

这市面上也没什么比较好的书讨论继续集成了，所以只好给个“还好”。

持续集成很多的公司都有做，虽然方法可能不一样，但大概的思想和这本书是差不多的。具体到不同的公司不同的业务肯定不一样，所以也没必要死按照这本书来做。

书上讨论的很多工具算不上过时，也不是最好的——凑合凑合还是不错的。

事实上确实和它的副标题一样，持续集成是软件质量改进和风险降低之道。

《持续集成》读后感(五)：有点老，但了解概念还是不错

http://kaverjody.com/continuous-integration-book-reading-1/

http://kaverjody.com/continuous-integration-book-reading-2/

第一部分 CI的背景知识：原则与实践

第一章 启程

一次构建：不止是一次编译（或是动态语言中的某种称谓）。一次构建可能包含编译、测试、审查和部署以及其他一些事情。一次构建是将源代码放在一起，并验证软件可以作为一个一致的单元运行的过程。

涉及到的工具和参与人员包括：开发人员、版本控制库（如subversion）、CI服务器（如CruiseControl）、构建脚本（如Ant）、反馈机制（如email）、集成构建计算机。

CI的特征：与版本控制器系统的连接；构建脚本；某种类型的反馈机制；集成源代码变更的过程。

其子过程包括：源代码编译；数据库集成；测试；审查（如静态和动态分析）；部署；文档与反馈。

第二章 引入持续集成

CI的价值在于：

减少风险

缺陷的检测和修复变得更快

软件的健康程度可以测量

减少假定

减少重复过程

减少重复过程的劳动，让人们有时间做更多的需要动脑筋的、更高价值的工作。

通过对一些重要过程（如测试盒数据库集成）自动化，克服项目中的某些成员对实现改进的抵制。

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

增强项目的可见性

有效地决策：CI系统可以对当前的构建状态和品质指标提供及时的信息。

注意到趋势：如构建成功或失败、总体品质以及其他相关的项目信息。

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

阻碍团队使用CI的原因：

增加了维护CI系统的开销

变化太大

失败的构建太多

额外的硬件/软件成本

开发者应该执行这些动作

对于在项目中实现CI的团队和个人很有好处的7项实践：

经常提交代码：进行小的变更；在每个任务之后进行提交。

不要提交无法构建的代码

立即修复无法集成的构建

编写自动化的开发者测试

必须通过所以测试和审查

执行私有构建

避免签出无法构建的代码

第三章 利用CI减少风险

CI能够缓解的一些关键风险：

没有可部署的软件：利用CI系统随时构建可部署的软件。创建一个可重复的构建过程，使用版本控制库中的所有软件资产。

很晚才发现缺陷：每次变更时都执行开发者测试，这样就能够在软件开发生命周期中尽早发现缺陷。

缺少项目可见性：经常运行构建，随时了解项目的健康状况。如果有效地应用CI实践，项目的状态就不再是一个问题。

低品质的软件：在每次变更时执行测试和审查，这样就能通过了解复杂程度、重复情况、设计、代码覆盖率和其他因素发现可能进入代码中的潜在缺陷。

第四章 针对每次变更构建软件

执行单命令构建 – Martin Fowler说：“把所有需要的东西都放到源代码版本控制库中，以便于您通过单个命令就能构建整个系统。”

将构建脚本从IDE中分离 – 因为：（1）每个开发者可能使用不同的IDE，找出每个IDE中配置文件的差别会很困难；（2）CI服务器必须在无人干预的情况执行自动化的构建，因此开发者执行的自动化构建脚本，同样也应该能够由CI服务器执行。

集中放置软件资产 – 一种方法是使用版本控制库来存放所有文件，除了代码，还包括：

组件，包括源文件和库文件；

第三方组件，如JAR文件、库、DLL等

配置文件

初始化应用程序的数据文件

构建脚本和构建环境设置

某些组件的安装脚本

让构建快速失败 – 好的构建知道如何快速地失败。在构建的许多部分都成功之后再失败，这让人很恼火，而且您在确定失败的目标时也会失去宝贵的时间。创建快速失败构建的主要步骤如下：集成组件；运行真正的单元测试；执行其他自动化的过程。

构建类型：

私有构建：开发者在向版本控制库提交代码之前，要先进行私有构建。

集成构建：集成构建集成项目团队向版本控制库中的主线提交的变更。

发布构建：准备好发布给用户的软件。

构建触发机制：

用户驱动：由某人手工发起构建

定期执行：由时间驱动，不论是否发生了变更。

轮训变更：一个进程以固定的时间间隔唤醒，从版本控制库中签出变更。如果检测到变更，它就执行集成构建。

事件驱动：与轮训变更类似，但是是由版本控制库出发的，基于实现定义好的变更事件。

使用CI服务器 – 如果您打算自己写一个CI服务器，可能需要包含下面的一些功能：

以特定的时间间隔轮训版本控制库中的变更

定期执行某种操作

标识出“安静期”，在这段时间内项目不进行集成构建

支持不同的构建脚本工具，包括命令行工具

向相应人员发送电子邮件

显示以前构建的历史

显示一个web信息面板，这样每个人都可以查看集成构建的信息

为不同的项目支持多个版本控制系统

执行快速构建 – 快速反馈对CI是很关键的。集成构建的时间越短，您就能越快收到反馈信息。可以按如下方式分析并减少构建时间：

收集构建测量数据

分析构建测量数据

选择并实现改进

重新评估，有必要则再次重复这个过程

集成构建测量的指标：

编译时间

源代码行数（SLOC）

审查的种类数

平均组装生成时间

测试执行时间（根据分类）

成功构建和失败构建的比例

审查时间

部署时间

重建数据库的时间

集成构建计算机系统资源和使用情况

版本控制系统的负载

可以采取的改进方法：

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

增强集成构建计算机的硬件能力

改进测试性能

安排集成构建的顺序

优化基础设施

优化构建过程

单独构建系统组件

改进软件审查的性能

执行分布式集成构建

第二部分 创建全功能的CI系统

第五章 持续数据库集成（Countinuous Database Integration, CDBI）

项目成员通常执行的数据库集成活动可以自动化：删除数据库；创建数据库；插入系统数据；插入测试数据；迁移数据库和数据；在多个环境下建立数据库实例；修改列属性和约束条件；修改测试数据；修改存储过程（包括函数和触发器）；取得对不同环境的访问权；备份/恢复大量数据。

共享数据库集成脚本是一项最佳实践，直接而简单。所有软件资产都要放到版本控制库中，这包括了所有数据库资产：

删除、创建表和视图的DDL，包括约束条件和触发器

存储过程和函数

实体关系图

针对不同环境的测试数据

具体的数据库配置

利用结合构建脚本使数据库集成自动化，持续执行，在对数据库或源代码进行修改后就执行。将数据库资产放入版本控制库，确保它们有单一来源。测试并审查你的数据库脚本和代码。确保所有数据库集成都由构建脚本管理，所有数据库资产都签入版本控制库，所有（与数据库打交道的）开发者都有一个数据库沙盒。

第六章 持续测试

系统工程有一项原则，线性系统的可靠性是每个系统组件的可靠性的乘积。对于包含100个组件的线性系统来说，如果每个组件的可靠性是99%，整个系统的可靠性就只有37%。所以作为底线，如果我们要构建真正可靠的软件系统，我们就必须确保对象层面的可靠性，这只能通过成功的单元测试来实现。

源代码的可靠性取决于测试覆盖率，测试的价值取决于它们执行的频率。通常将测试分为4个自动执行的分组：

单元测试：可利用NUnit或JUnit这样的单元测试框架。这些单元测试应该没有外部依赖关系，不会依赖于文件系统或数据库。

组件测试：利用NUnit或JUnit这样的单元测试框架，让您的组件测试自动化，如果用到数据库，就是用DbUnit或NDbUnit。这些测试涉及更多对象，通常比单元测试需要花更长的时间来执行。

系统测试：系统测试比组件测试执行的时间更长，通常涉及多个组件。

功能测试：利用Selenium（针对Web应用程序）和Abbot（针对GUI应用程序）这样的工具，可以让功能测试自动化。功能测试从用户的角度执行操作，通常是自动化测试套件中执行时间最长的。

将测试分为一些组，您可以按不同的时间间隔来执行那些较快（如单元测试）和较慢的测试（如组件测试）。根据新的缺陷编写测试，增加代码覆盖率，确保这个缺陷不会再次出现。利用数据库测试框架确保数据处于“已知状态”，这有助于使组件测试可重复。将测试用例限制为一个断言，您可以花较少的时间来追踪测试失败的原因。

第七章 持续审查

利用工具进行自动化的代码审查能够解决80%的问题，让人来处理另外20%的重要问题。审查基于一组预先定义的规则分析代码。审查者（或静态和动态的分析工具）是由确定的标准指导的，团队应该坚持这些标准（通常是一些编码或设计方面的测量指标）。

通过持续执行审查，可以减少发现缺陷和后续修复之间的时间。

复杂度被证实与缺陷有关。请利用您的审查工具来监控代码的复杂度，采取措施来监控复杂度的变化趋势，利用测试用例和重构来降低缺陷的风险。

通过定量地描述配件/包或对象之间的耦合，架构方面的耦合指标可以有效地定位代码的长期维护问题。这些测量指标可以揭示在面对改变时的相关风险。

传入耦合（Afferent Coupling），也称作Fan In

传出耦合（Efferent Coupling），也称作Fan Out

不稳定性 = 传出耦合/（传出耦合 + 传入耦合）。值为1表示不稳定，值为0表示稳定。

编码标准有利于不同团队的开发者对代码的共同理解。通过持续地监控和审查代码，您的团队可以保持遵守架构和编码指南。问题可以早发现、常发现，从而避免了长期的维护问题。

重复的代码可能导致下列问题：增加维护成本，因为需要多次发现、报告、分析和修复缺陷；不确定是否存在其他缺陷（重复的代码还没有找到）；对于额外编写的代码增加了测试成本。

判断代码覆盖率：利用像NCover、Cobertura或Clover等工具来确定测试代码实现的代码行覆盖率或分支覆盖率。利用这些信息来确定哪些地方需要更多的测试。

第八章 持续部署

持续部署能工作的软件，您的项目将从中受益。虽然每个应用程序、每个平台和每个目标领域都有独特的需求，但随时随地发布能工作的软件的过程主要有6大步骤。在版本控制库中打上标签，说明一组文件时相关的。提供干净的环境可以减少关于已有软件资产的假定，如果漏掉这些软件资产，最简单的构建版也会无法运行。为构建版打上标签，这为二进制文件提供了名称，报告可以基于这个标签。确保所有测试都执行成功，这让您确信软件能够像希望的那样工作。生成反馈报告有助于让大家了解构建版中包含的功能、缺陷和需求。最后，回滚构建版的能力意味着如果出现了什么问题，您仍然可以向用户提供最新的能工作的版本。

第九章 持续反馈

在正确的时间，以正确的方式，将正确的信息发送给正确的人 —— CI是让这种反馈信息自动化、目标化和实时化（持续化）的最好工具。

正确的信息：构建状态；审查报告；测试结果。

正确的人：项目经理；构建负责人；技术负责人；开发者；业务分析师。（注意信息的开销 – 向项目中的每一个人发送信息通常只会导致每个人都忽略该信息）

正确的时间：当问题发生时；每天；每周。（持续集成核心 – 持续集成的核心是减少缺陷引入、发现和修复之间的时间间隔）

正确的方式：电子邮件；Ambient Orb；SMS；声音；X10；Windows任务条；宽屏显示器；浏览器插件；即时消息；RSS；小应用程序。

附录A CI资源

持续集成Web站点/文章

Automation for the people : Continuous feedback

Automation for the people : Continuous Inspection

Automation for the people : Remove the smell from your build ｓｃｒｉｐｔs

Continuous Integration

Continuous Integration

Daily Build and Smoke Test

IntegrateBotton.com

Realizing continuous integration

CI工具/产品资源:AnthillPro; Apache Continuum; Bamboo; BuildForge; Continuous Integration Server Matrix; CruiseControl; CruiseControl.NET; Draco.NET; Gauntlet; Luntbuild; ParaBuild; PMEase QuickBuild; Sin.

构建脚本资源:Ant; Groovy; Maven; NAnt; Rake.

版本控制资源:ClearCase; CVS; MKS; Subversion.

数据库资源:Hypersonic DB; Mckoi; MySQL; Oracle; PostgreSQL.

测试资源:Agitator; DbUnit; Fit; FitNesse; Floyd; HtmlUnit; JUnit; JWebUnit; NDbUnit; NUnit; Selenium; SQLUnit; TestEarly.com; TestNG; utPLSQL; Watir; xUnit Test Patterns.

自动化审查资源:Checkstyle; Clover; Cobertura; EMMA; FindBugs; FxCop; JavaNCSS; JDepend; NCover;NDepend; PMD; Simian; SourceMonitor.

部署资源:Capistrano.

反馈资源:Ambient Devices; Google Talk; Jabber; X10; Lava Lamps.

文档资源:Doxygen; Javadox; NDoc.

附录B 评估CI工具

构建工具和构建计划安排工具的一些有价值的基本功能和扩展功能：

构建工具——基本功能：代码编译；组件打包；程序执行；文件操作。

构建工具——扩展功能：执行开发者测试；版本控制工具集成；文件集成；部署功能；代码品质分析；可扩展性；多平台构建；加速构建。

构建计划安排工具——基本功能：构建执行；版本控制集成；构建工具集成；反馈；为构建打上标签。

构建计划安排工具——扩展功能：项目间依赖关系；用户界面；制品发布；安全。

工具与软件开发过程的其他要素集成的程度：

该工具是否支持您目前的构建配置？

该工具是否需要安装其他软件才能运行？

该工具是否与您的项目使用同一种语言编写？

可靠性：工具的成熟度。

寿命：考虑工具的将来，要在健康的用户群和开发团队中寻找证据。

易用性：工具配置和使用起来越容易，它就越好。

==========

徐毅：独立敏捷顾问，经验丰富的国内知名敏捷及精益教练，专注于敏捷软件开发、Scrum、敏捷转型、敏捷测试、测试自动化、robotframework等。