缘起
根据破窗效应，软件中的bug越多，就越难将这些累积在一起的bug去除掉。
提高质量的关键是内建质量，根本不让bug产生，那么就需要将bug扼杀在摇篮里，趁着问题和思路还在你脑子里的时候就解决掉问题。
定义
持续集成（Continuous Integration，以下简称CI）是一种软件开发工程实践，可以让团队持续地收到反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。持续集成倡导团队开发成员必须频密地集成他们的工作，甚至每天都可能发生多次集成。而每次的集成都是通过自动化的构建来验证，包括自动编译、发布和测试，从而尽快地发现集成错误，让团队能够更快的开发出可工作的软件。
持续集成的核心价值在于：
- 持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量；同时降低了后期才集成带来的质量和进度风险。
- 持续集成保障了每个时间点上团队成员提交的代码是能可用的、满足质量要求的。换言之，任何时间点都能第一时间发现软件的集成问题，使任意时间发布可部署的软件成为了可能；
- 持续集成还能利于软件本身的发展趋势，这点在需求不明确或是频繁性变更的情景中尤其重要，持续集成的质量能帮助团队进行有效决策，同时建立团队对开发产品的信心。
系统构成
持续集成系统会定时地扫描源代码仓库。开发人员每次提交代码，都应当可以自动触发一次持续集成。常见的持续集成步骤包括：
- 编译
- 代码静态检查
- 运行单元测试
- 生成单元测试覆盖率报告
- 打包
- 部署
- 运行自动化功能测试
- 发布执行报告和通知
这其中的任何一步出现错误，都会立即终止当前的持续集成构建任务，并发布执行报告和通知开发人员。
纪律！纪律！
需要强调的是，持续集成是一种开发实践，而常见的Jenkins、Hudson、RTC Build Forge等工具系统只是一种持续集成系统而已。没有良好的开发约定和开发纪律作为支持，仅有持续集成系统工具是无法达到效果的。
要注意的重点
- 构建所需的所有内容都在单一的源代码仓库中
- 头号规则就是你能够在虚拟机中重建项目
- 用命令行构建脚本代替IDE
- 不同环境中的测试差异会带来风险
- 最低限度地使用分支，采用主干开发（分支仅用于修复生产缺陷和临时研究）
- 修复每个缺陷后增加一个新测试
- 速度至上
- 人类的耐心极限为10分钟
- 你节约的每一分钟都会加快其他人的每次提交
- 缓慢或断续的环境需要采用测试替身
- 平衡速度与寻找缺陷，考虑使用构建流水线（逐步增加信心）或平行构建
- 频繁提交、频繁集成，争取快速反馈
- 将工作分解为几小时粒度的小部分，也有助于跟踪进度
- 构建失败时不能提交
- 本地可能会漏掉一些，仅当CI成功时，自己的任务才算完成
- 谁破坏了构建，谁需要立即修复
- 如果构建经常失败，找到原因并修复它
让人无法忽视结果
用下列来沟通构建状态:
- 熔岩灯或CI监视器
- 物理墙上的绿色贴纸
- 构建令牌
- 铃或播放录音
- 邮件或微博
参考阅读
- Martin Fowler的博客
- 想要进一步了解敏捷工程实践，关注Certified Scrum Developer国际认证课程