持续集成

缘起

根据破窗效应，软件中的bug越多，就越难将这些累积在一起的bug去除掉。
提高质量的关键是内建质量，根本不让bug产生，那么就需要将bug扼杀在摇篮里，趁着问题和思路还在你脑子里的时候就解决掉问题。

定义

持续集成（Continuous Integration，以下简称CI）是一种软件开发工程实践，可以让团队持续地收到反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。持续集成倡导团队开发成员必须频密地集成他们的工作，甚至每天都可能发生多次集成。而每次的集成都是通过自动化的构建来验证，包括自动编译、发布和测试，从而尽快地发现集成错误，让团队能够更快的开发出可工作的软件。

持续集成的核心价值在于：

1. 持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量；同时降低了后期才集成带来的质量和进度风险。
2. 持续集成保障了每个时间点上团队成员提交的代码是能可用的、满足质量要求的。换言之，任何时间点都能第一时间发现软件的集成问题，使任意时间发布可部署的软件成为了可能；
3. 持续集成还能利于软件本身的发展趋势，这点在需求不明确或是频繁性变更的情景中尤其重要，持续集成的质量能帮助团队进行有效决策，同时建立团队对开发产品的信心。

系统构成

持续集成系统会定时地扫描源代码仓库。开发人员每次提交代码，都应当可以自动触发一次持续集成。常见的持续集成步骤包括：

• 编译
• 代码静态检查
• 运行单元测试
• 生成单元测试覆盖率报告
• 打包
• 部署
• 运行自动化功能测试
• 发布执行报告和通知

这其中的任何一步出现错误，都会立即终止当前的持续集成构建任务，并发布执行报告和通知开发人员。

纪律！纪律！

需要强调的是，持续集成是一种开发实践，而常见的Jenkins、Hudson、RTC Build Forge等工具系统只是一种持续集成系统而已。没有良好的开发约定和开发纪律作为支持，仅有持续集成系统工具是无法达到效果的。

要注意的重点

• 构建所需的所有内容都在单一的源代码仓库中
  • 头号规则就是你能够在虚拟机中重建项目
  • 用命令行构建脚本代替IDE
  • 不同环境中的测试差异会带来风险
• 最低限度地使用分支，采用主干开发（分支仅用于修复生产缺陷和临时研究）
• 修复每个缺陷后增加一个新测试
• 速度至上
  • 人类的耐心极限为10分钟
  • 你节约的每一分钟都会加快其他人的每次提交
  • 缓慢或断续的环境需要采用测试替身
  • 平衡速度与寻找缺陷，考虑使用构建流水线（逐步增加信心）或平行构建
• 频繁提交、频繁集成，争取快速反馈
  • 将工作分解为几小时粒度的小部分，也有助于跟踪进度
• 构建失败时不能提交
  • 本地可能会漏掉一些，仅当CI成功时，自己的任务才算完成
  • 谁破坏了构建，谁需要立即修复
  • 如果构建经常失败，找到原因并修复它

让人无法忽视结果

用下列来沟通构建状态:

• 熔岩灯或CI监视器
• 物理墙上的绿色贴纸
• 构建令牌
• 铃或播放录音
• 邮件或微博

参考阅读

• Martin Fowler的博客
• 想要进一步了解敏捷工程实践，关注Certified Scrum Developer国际认证课程