《持续交付-发布可靠软件的系统方法》全书51.2万字，15章，384页。本次阅读第三章持续集成，大概42页。
持续集成最早出现在Kent Beck写的《解析极限编程》一书中，主要思想：既然经常对代码库进行集成对我们有好处，为什么不随时做集成呢？《持续交付》第三章主要讲述如何实现持续集成。
在本书中，对持续集成的定义如下：持续集成是一种软件开发实践。在持续集成中，团队成员频繁集成他们的工作成果，一般每人每天至少集成一次,也可以多次。每次集成会经过自动构建(包括自动测试)的检验，以尽快发现集成错误。自从在团队中引入这样的实践之后，Martin Fowler发现这种方法可以显著减少集成引起的问题，并可以加快团队合作软件开发的速度。
1、实现持续集成
1.1 准备工作
1.版本控制
使用SVN或者git免费工具可以进行版本控制。
2.自动化构建
有以下理由持续推进自动化构建：
- 能够在持续集成环境中以自动化的方式来执行整个构建过程，以便出现问题时能够审计。
- 应将构建脚本与代码库同等对待。应该对它测试，不断重构，以便使它保持整洁且容易理解。
- 使理解、维护和调试构建过程更容易，并有利于和运维人员更好的协作。
3.团队共识
团队认同：“修复破坏应用程序的任意修改是最高优先级的任务”。
2 持续集成的前提条件
2.1. 频繁提交
2.2 创建全面的自动化测试套件
三类测试在持续集成构建中使用：单元测试，组件测试和验收测试。
将验收测试按照功能模块分组通常是可取的。这样，当仅修改了系统中的个别模块功能时，就可以单独运行影响系统这部分功能的验证测试。很多单元测试框架都是提供这样的分组功能。
2.3 保持较短的构建和测试过程
2.4 管理开发工作区
三点：1）细心的配置管理 ；2）对第三方以来的配置管理 ；3）确保自动化测试在开发机可以运行。
3 使用持续交付软件
3.1 基本操作
两个部分：每隔一段时间周期运行一次工作流程；提供展示运行结果的视图。
3.2 铃声和口哨
失败可以用灯等设备提示，可以在流程加入圈复杂度，重复代码，静态检查等环节。
4 必不可少的实践
持续集成是一种实践，不是一个工具，他的有效性依赖于团队纪律。
4.1 构建失败后不要提交新代码。
4.2 提交前，在本地运行所有的提交测试。或者让持续集成服务器完成此事。
功能：预测试提交，个人构建。
4.3 等测试提交通过后再继续工作。
4.4 回家之前，构建必须处于成功状态。
4.5 时刻准备着回滚到前一个版本
4.6 在回滚之前要规定一个修复时间
4.7 不要将失败的测试注释掉
4.8 为自己导致的问题负责
4.9 测试驱动的开发
5 推荐的实践
5.1 极限编程开发实践
重构作为高效软件的开发基石。持续改进和测试驱动开发让TDD成为可能。
5.2 若违背架构原则，就让构建失败
5.3 若测试运行变慢，就让构建失败
5.4 若编译告警或代码风格问题，就让测试失败
6 分布式团队
6.1 对流程的影响
信任很重要，同时视频会议相互了解功能和进展。
6.2 集中式持续集成
集中式的持续集成是一种双赢的实践。
6.3 技术问题
推荐Git
6.4 替代方法
两个方式：分解系统为多个组件；使用分布式版本控制系统
7 分布式版本控制系统
介绍github的设计思想。
小结：
总之，一个好的持续集成系统是基石，在此之上你可以构建更多的基础设施：
--一个巨大的可视化指示器，用于显示构建系统所搜集到的信息，以便提供高质量的反馈；
- 结果报告系统，以及针对自己测试团队的安装包。
- 为项目经理提供关于系统质量的数据报告
- 使用部署流水线，可以将其延展到生产环境，为测试人员和运维团队提供一键式部署系统。
