豆瓣上有此书的介绍，《持续集成：软件质量改进和风险降低之道》。此书还有配套web站点，提供了此书更新、代码示例和其他材料。

第二部分 创建全功能的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资源

1. 持续集成Web站点/文章
• Automation for the people : Continuous feedback
• Automation for the people : Continuous Inspection
• Automation for the people : Remove the smell from your build scripts
• Continuous Integration
• Continuous Integration
• Daily Build and Smoke Test
• IntegrateBotton.com
• Realizing continuous integration
2. CI工具/产品资源:AnthillPro; Apache Continuum; Bamboo; BuildForge; Continuous Integration Server Matrix; CruiseControl; CruiseControl.NET; Draco.NET; Gauntlet; Luntbuild; ParaBuild; PMEase QuickBuild; Sin.
3. 构建脚本资源:Ant; Groovy; Maven; NAnt; Rake.
4. 版本控制资源:ClearCase; CVS; MKS; Subversion.
5. 数据库资源:Hypersonic DB; Mckoi; MySQL; Oracle; PostgreSQL.
6. 测试资源:Agitator; DbUnit; Fit; FitNesse; Floyd; HtmlUnit; JUnit; JWebUnit; NDbUnit; NUnit; Selenium; SQLUnit; TestEarly.com; TestNG; utPLSQL; Watir; xUnit Test Patterns.
7. 自动化审查资源:Checkstyle; Clover; Cobertura; EMMA; FindBugs; FxCop; JavaNCSS; JDepend; NCover;NDepend; PMD; Simian; SourceMonitor.
8. 部署资源:Capistrano.
9. 反馈资源:Ambient Devices; Google Talk; Jabber; X10; Lava Lamps.
10. 文档资源:Doxygen; Javadox; NDoc.

附录B 评估CI工具

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

• 构建工具——基本功能：代码编译；组件打包；程序执行；文件操作。
• 构建工具——扩展功能：执行开发者测试；版本控制工具集成；文件集成；部署功能；代码品质分析；可扩展性；多平台构建；加速构建。
• 构建计划安排工具——基本功能：构建执行；版本控制集成；构建工具集成；反馈；为构建打上标签。
• 构建计划安排工具——扩展功能：项目间依赖关系；用户界面；制品发布；安全。

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

• 该工具是否支持您目前的构建配置？
• 该工具是否需要安装其他软件才能运行？
• 该工具是否与您的项目使用同一种语言编写？

可靠性：工具的成熟度。

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

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