持续集成只是信息源。持续集成的检验是在代码提交之后而非之前进行的，因此持续集成的作用只是使项目健康情况可视化。并且这种可视化必须建立在构建经常成功的前提下。因为软件本身的复杂性决定了只有“是否达到质量要求”能够被简单度量，而“达到（或不达到）质量要求的程度”无法被简单度量。所以，如果构建经常失败，持续集成所能提供的信息就只剩“项目一直不健康”──这个信息的价值很小，如果不是完全没有价值的话。

让持续集成保持经常成功，必须规范三件事：

1. 提交代码之前必须更新
2. 提交代码之前必须进行本地验证
3. 线上构建失败时不得进行任何提交（或更新）

如果做不到这三件事，持续集成就可能降格化为持续不能集成：你知道项目有问题，但不知道问题出在哪儿，也不知道该如何解决这些问题。

为了避免这种降格化，在持续集成到位之后，需要用更多的手段确保三点规范得以落实：

• 代码库和持续集成分级
• 责任逐级下压
• 建立提交前本地构建基础设施

要言之：持续不能集成会使持续集成的价值降低到约等于0（甚至低于0）。要避免持续不能集成的发生，第一要严格规范，第二要提供技术手段使规范能够被落实。