CI 的理念是「频繁地，快速地检测软件质量」，已经被证明是一种比较好的开发实践。本文沿着这一思路，试图总结出一点经验。
一种典型的开发人员流程如下：
CI中最重要的原则是两个：
- 频繁，频次尽可能高。如果一个自动化工具不能被频繁地使用，那么它的价值会被大打折扣。
- 快速。如果一个自动化工具，单次使用的时间太长，那么它的价值会被大打折扣。
根据上述原则，流程中每一阶段的对比：
综合上述表格，有如下经验：
- push 阶段的CI必做
- 合并merge request的CI建议做，也可以将其提前
- 本地commit阶段的CI，有精力就做，但大概率投产比不会高
因此可以用一幅图概括：
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。