持续集成实践的自查表

以下内容截选自我的新书《持续交付2.0》的第九章的内容，仅供参考。

“持续集成”一直是一个比较困难的技术实践，它来自于极限编程方法，其祖先是上个世纪八十年代的“每日构建（daily build）”实践。作为一个上古实践，最早记录于微软的软件开发管理的相关论文中。

如果读者想知道，自己的团队是否达到了持续集成的最佳状态，可以从下面六个方面进行自我检查。

一、主干开发，频繁提交

主干开发是指参与开发同一软件项目或服务的所有团队成员向该软件项目代码仓库的主干分支上提交代码，或者其它分支的生命周期不超过三天。频繁提交是指每人每天至少提交一次，最好每工作几小时后就进行提交。

二、每次提交应该是一个完整的任务

每次提交的内容应该是有意义的，而不只是为了达到提交频率的要求而随意提交代码。我们希望每次提交的代码都是围绕同一个工作任务，同时能够提交该任务对应的自动化测试代码。

三、让提交构建在10分钟以内完成

工程师通常是没有什么耐心等待的，所以每次构建验证的时间越短越好。尤其是当团队使用“同步模式”时，构建验证的运行时间尤其重要。如果运行时间过长，无疑会降低质量反馈速度。假如提交构建验证失败，那么开发人员需要更大的精力去回忆那次提交的工作上下文，去分析可能的问题所在。

四、提交构建失败后应禁止团队成员提交新代码，也不许其它人检出该代码

当某个团队成员提交代码引起提交构建验证失败，说明软件整体质量可能存在问题或风险。此时，整个团队不应该再继续提交新的代码变更。这正是应用了丰田式生产管理系统（ToyotaProduction System，简称TPS）中的“立即暂停原则（Stop the Line）”。其指导思想是：当生产线上已经发现了问题，就要马上停下来立即解决。在问题没有得到解决之前仍旧使生产线保持运行，只会提高生产残次品的比率。

同样，对于软件团队来说，如果提交构建验证已经失败，那么在未修复之前，其他人就再次提交新的代码，那么一定会引起提交构建验证失败。那么，这次失败是由上次失败的原因导致的呢，还是新的代码本身就有问题呢？这会使问题的解决变得更加复杂。

五、立即在10分钟内修复已失败的提交构建，否则回滚代码

根据之前的讨论，提交构建失败后，在问题被修复之前，团队成员不能提交代码。这会打破团队其他人的开发节奏，甚至令整个项目进度受阻，所以应该立即着手修复。现实中，常见的现象是：正在修复问题的开发者通常声称可以在很短的时间内修复问题，但实际上花费的时间往往比实际预期的时间要长。因此，团队需要制定类似的工作原则：如果x分钟之内无法修复，就应该回滚代码。这样既让修复问题的开发人员有足够的时间思考并解决问题，以免忙中出错，也能让团队可以继续前进。如果修复时间过长，会令整个团队未提交代码的数量积累过多，那么潜在的集成问题可能会更多。问题修复后，积攒的大量代码提交引起提交构建失败的机率更大，修复时间更长，如图9-3所示。

图9-3修复时间的系统思考图

六、自动化构建验证通过后，对软件质量有比较大的信心

持续集成的真正目的是快速有效的质量反馈，即：只要自动化构建成功，对软件质量就有信心。我曾经遇到过一个实施持续集成实践的团队，它完全做到了前面的五项要求。在听到团队负责人的描述时，觉得这个团队的持续集成实践做的不错。然而，真实的情况却恰恰相反。团队并不觉得他们的持续集成有什么用处。经过详细情况了解后才知道，他们虽然有很多自动化测试用测，但新增的自动化测试用例很少。当原有的自动化测试用例失败时，如果修复比较困难，他们就会删除它。