《持续交付-发布可靠软件的系统方法》全书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的设计思想。

小结：

总之，一个好的持续集成系统是基石，在此之上你可以构建更多的基础设施：

--一个巨大的可视化指示器，用于显示构建系统所搜集到的信息，以便提供高质量的反馈；

- 结果报告系统，以及针对自己测试团队的安装包。

- 为项目经理提供关于系统质量的数据报告

- 使用部署流水线，可以将其延展到生产环境，为测试人员和运维团队提供一键式部署系统。