CI 的理念是「频繁地，疾速地检测软件品质」，曾经被证实是一种比拟好的开发实际。本文沿着这一思路，试图总结出一点教训。
一种典型的开发人员流程如下：
CI 中最重要的准则是两个：
- 频繁，频次尽可能高。如果一个自动化工具不能被频繁地应用，那么它的价值会被大打折扣。
- 疾速。如果一个自动化工具，单次应用的工夫太长，那么它的价值会被大打折扣。
根据上述准则，流程中每一阶段的比照：
综合上述表格，有如下教训：
- push 阶段的 CI 必做
- 合并 merge request 的 CI 倡议做，也能够将其提前
- 本地 commit 阶段的 CI，有精力就做，但大概率投产比不会高
因而能够用一幅图概括：