持续集成

缘起

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

定义

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

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

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

系统构成

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

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

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

纪律!纪律!

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

要注意的重点

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

让人无法忽视结果

用下列来沟通构建状态:

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

参考阅读